If a form component has no way to tell me that a user has changed a value/state/choices (in option group for example) then I have not way to mange those changes with for example server updates, automatic validatioin etc.
An object where keys are expressions to watch and values are the corresponding callbacks. The value can also be a string of a method name, or an Object that contains additional options. The Vue instance will call $watch() for each entry in the object at instantiation.
Note that you should not use an arrow function to define a watcher (e.g. searchQuery: newValue => this.updateAutocomplete(newValue)). The reason is arrow functions bind the parent context, so this will not be the Vue instance as you expect and this.updateAutocomplete will be undefined.
I’m only a month new to both quasar and vue so didn’t occur to me to use them.
BUT as I look at my use case I am wondering if they apply because I am binding a prop in my child compoenet (above) and not local data. My understanding is that if you pass a prop then for the prop to change you must emit an event that the parent can listen for that has the changes made in child, then you set those in the parent and they get sent back to child via the prop. You can’t change a prop directly within the same component and and thus you can’t watch a prop as a way of ddeterming a change that can be emitted to the parent. Is that so?
Use @change event (applies to almost all form components). This is triggered whenever the model changes, whatever the model is (String, Array, Object, etc).
Just added this event to the Option Group docs page (will get live in a few days) – missing this prop was a docs glitch.
One thing that is driving me a little crazy with Quasar is the @change is triggered differently than traditional Vue.
if you replace the input with an q-input, the input AND change will be triggered as you type.
@daveline A general rule of thumb when dealing with Quasar: @input is used solely for managing state with Vue in order to generate as few re-renders as possible, while @change ensures it is triggered each time the model changes, as soon as it changes.