For anyone that happens to stumble upon this…I was able to get CKEditor working in Quasar by building their editor from source according to their documentation and then exporting it as my own NPM package. This article is a pretty good starting point. (It doesn’t tell you anything you can’t eventually find in their documentation, but it will definitely save you time because of how convoluted things are).
Repo/docs for vue component

You can then npm install the package you created, as well as the @ckeditor/ckeditor5-vue package, and then import both modules into your component and configure it from there.

Basically the mistake I was making was attempting to combine their source into the code of my own project - this is technically be possible (but dumb) for someone who understands how quasar.conf is exposing webpack’s config.

import CustomEditor from '@my_npm_user/my_package_name/build/ckeditor.js'
import CKEditor from '@ckeditor/ckeditor5-vue';

export default {
    data() {
        return {
            editor: CustomEditor, //The editor built from source: ckeditor5-vue is just a superficial wrapper of this element.
            editorData: '<p>Content of the editor.</p>',
            editorConfig: {
                // The configuration of the editor.
            }
        }
    }
}

And in defence of CKEditor: I believe it is in fact mostly open-source, (not to get into the nitty-gritty about open source, but they do employ the term pretty often on their site) and I believe the licensing is only limited when using some of their “premium” features, such as collaboration. The licensing is fairly permissive for small companies or individuals using the standard features.

You will find that this is the case pretty much across the board for editors with quality collaboration software, which I can’t fault anyone for: I know from my own failures just how much hard work and skill must go in to these features.

Oh and thanks @dobbel for trying to enlist some help in this, you’ve been an awesome forum-citizen here and elsewhere I’ve seen.

(val) => flags.flag1 || ‘The flag1 must be activated’

Pretty sure this is what you are going for right? You misspelled flags (and “activated”, btw), and putting !flags means that you satisfy the validation condition when flag1 is false.

@yk-davdomin :rules contains functions which are called when the input is validated, meaning that the value of counter inside of rules = whatever the value was when the function was called. To achieve what you are trying to do here, you could change the button to call a method:

btnClick() {
   this.counter++
   this.$refs.input.validate() //Calling validate at this point will update the error message in the rule.
}

To achieve rules that are truly reactive to data/computed props, you would need to code your own validation logic and not rely on input.validate()

@cloudm I recently attempted something similar. The issue is basically that the input value in use-input does not have a v-model, at least not one that quasar exposes. Unless we missed something. So the value is lost on blur. I don’t exactly know the answer for how to do what you are attempting.

However, I found that you can achieve a suitable imitation by using a combination of q-input and q-menu.
Code example: https://jsfiddle.net/6myp4hn9/6/
The example is missing some of the finer details like keyboard events for selecting options (pretty straightforward though, you can use the array index of the option for this), or the ability to select multiples (in my app I .split(’ ') the input value and replace the last index with the selection).

I know that using q-select has its advantages, and if there’s a way to do what you’re asking about I’d love to find that out.

@metalsadman Thanks for the reference - that makes sense. Quasar docs never fail!

Also, unrelated to Quasar but I found that what was crashing my Vue devtools was the firing of 2k+ mutations through Firebase’s child_added listener. Calling ref.once(‘value’) on load and then setting the full list through a single mutation fixes this issue.

Forked your codepen and fixed:
https://codepen.io/dylanmoylan1/pen/poEbrvM

Notes:

• Recommend using q-option-group in this situation.
• All checkboxes in a group like you were doing need to use the same v-model, an array.
• Avoid using v-model and @input on the same component.

@dobbel

Wow, I don’t know how/why this works, but I tried it and my console no longer freezes up. Thanks! Do you happen to remember your source for this? Or is this just something I should know about as a dev? I’ve never used Object.freeze before.

Also, don’t know if this makes a difference but since the data is received from firebase inside a “child_added” listener, I am freezing each individual object rather than the entire list. I wonder if, despite the positive outcome, this is in fact achieving the desired effect.

Hi,

I recently had to import a pretty large list of options into my app (~2500 items) that are used by a single component containing several q-selects with user-input/filtering. The data is pulled down from Firebase realtime DB on load and set into Vuex, and the q-select options are generated from a vuex getter that maps over objects in state and returns an array of name strings.

The app is still performant from a user perspective, but the Vue devtools now crash consistently before opening on pages containing these q-selects. I didn’t have this issue until the import, so I assume this is due to the size of the data.

I don’t have much experience debugging perf issues, so I have questions:

• Is there an aspect of this flow that is problematic?
• Does Q-select start to have issues as the size of the data set grows - ie. is q-select’s parsing of the data the likely culprit, or is it how I am handling the data in general?
• Are performance issues multiplied by having multiple q-selects in the same component, even if they pull from the same data?
• Would lazy-loading (from state) be a solution to this problem, and are there any examples of this I could look at? (I prefer longer, larger initial loading times to repeated queries to the backend). In general, I’m not sure if I need to be limiting the data received by my component, or limiting the values available/displayed at a given time by each select.

Some of the questions are redundant - just curious to hear strategies about lazy-loading/handling large data sets with q-selects/debugging perf issues.

If I understand your problem, I believe you want to use a recursive function here. Iterate over an object, and for each property, if it’s a string, return it, otherwise call the function again.

Here’s a function using lodash to generate a node list:

const convert = function(object){
 return _.transform(object, function(result, value, key){
    if(_.isObject(value)){
    	result.push({
      	label: key,
        children: convert(value)
      })
    }else{
    	result.push({
      	label: key
      })
    }
   return result
  }, [])
}

Here’s a JSFiddle example with a working q-tree.

@cloudm Thanks for posting your solution - it still isn’t quite preferable in my case because the input value is sharing a binding with the model used for the selection. Ideally the input would have a separate v-model so that you could use-chips and use multiple (sounds like a potential Vue 3 feature?). For the time being I think the input/menu is still a pretty good workaround (I am using it for an @mentions type feature).

@cloudm I recently attempted something similar. The issue is basically that the input value in use-input does not have a v-model, at least not one that quasar exposes. Unless we missed something. So the value is lost on blur. I don’t exactly know the answer for how to do what you are attempting.

However, I found that you can achieve a suitable imitation by using a combination of q-input and q-menu.
Code example: https://jsfiddle.net/6myp4hn9/6/
The example is missing some of the finer details like keyboard events for selecting options (pretty straightforward though, you can use the array index of the option for this), or the ability to select multiples (in my app I .split(’ ') the input value and replace the last index with the selection).

I know that using q-select has its advantages, and if there’s a way to do what you’re asking about I’d love to find that out.

@yk-davdomin :rules contains functions which are called when the input is validated, meaning that the value of counter inside of rules = whatever the value was when the function was called. To achieve what you are trying to do here, you could change the button to call a method:

btnClick() {
   this.counter++
   this.$refs.input.validate() //Calling validate at this point will update the error message in the rule.
}

To achieve rules that are truly reactive to data/computed props, you would need to code your own validation logic and not rely on input.validate()

(val) => flags.flag1 || ‘The flag1 must be activated’

Pretty sure this is what you are going for right? You misspelled flags (and “activated”, btw), and putting !flags means that you satisfy the validation condition when flag1 is false.

For anyone that happens to stumble upon this…I was able to get CKEditor working in Quasar by building their editor from source according to their documentation and then exporting it as my own NPM package. This article is a pretty good starting point. (It doesn’t tell you anything you can’t eventually find in their documentation, but it will definitely save you time because of how convoluted things are).
Repo/docs for vue component

You can then npm install the package you created, as well as the @ckeditor/ckeditor5-vue package, and then import both modules into your component and configure it from there.

Basically the mistake I was making was attempting to combine their source into the code of my own project - this is technically be possible (but dumb) for someone who understands how quasar.conf is exposing webpack’s config.

import CustomEditor from '@my_npm_user/my_package_name/build/ckeditor.js'
import CKEditor from '@ckeditor/ckeditor5-vue';

export default {
    data() {
        return {
            editor: CustomEditor, //The editor built from source: ckeditor5-vue is just a superficial wrapper of this element.
            editorData: '<p>Content of the editor.</p>',
            editorConfig: {
                // The configuration of the editor.
            }
        }
    }
}

And in defence of CKEditor: I believe it is in fact mostly open-source, (not to get into the nitty-gritty about open source, but they do employ the term pretty often on their site) and I believe the licensing is only limited when using some of their “premium” features, such as collaboration. The licensing is fairly permissive for small companies or individuals using the standard features.

You will find that this is the case pretty much across the board for editors with quality collaboration software, which I can’t fault anyone for: I know from my own failures just how much hard work and skill must go in to these features.

Oh and thanks @dobbel for trying to enlist some help in this, you’ve been an awesome forum-citizen here and elsewhere I’ve seen.