I’m not a professional programmer, I wear lots of hats. I’ll spend a few weeks or months making a site as a tool, then get pulled onto something else for a long time, then be asked to come back and make a new site or add something.
I got a site working in React first. And an app with React Native. In both cases, coming back to the code cold was really hard for me - I couldn’t remember how anything worked, had to re-watch Udemy courses and retrace my steps.
Vue has been a lot better for coming back cold, it just seems easier to reason about without restarting the learning curve.
Recently I moved from Vue + Bootstrap to Quasar. Couldn’t be happier! Quasar is a really great platform for getting tools made quickly. Solving our offline issues with PWA mode and IndexedDB was surprisingly easy.

@ssuess Did you ever find a solution? I’m running into the same thing. Interestingly, I don’t see the workbox items in the console on Chrome or Edge. But in Firefox, I see them even though I’m running dev in SPA mode (as another console log confirms).

@s-molinari Perfect! Thank you!

Using QInputs on both iPads and desktop.
Setting type=“number” fixes my iPad annoyance - it brings the keyboard up in number mode, yay!
Looks great, too.
But on desktop, there are these arrow icons. I can live with it on Chrome, as they only show up when the cell is active.
But on Firefox they’re always visible and pretty rough:

Anyone know a trick to disable/hide them?

(just to be clear: I’m not saying it’s a bug, or Quasar’s fault - I’m a novice… Is there a CSS trick or something that’s super obvious to everyone else?)

@sontis You can avoid the vuex error by calling a mutation instead of modifying the props inline.
Mine looks like this:
@input="v => { setPendingRowState( {myVar: v, handle: props.row.handle} ); }

Where “setPendingRowState” commits a mutation:
setPendingRowState: function(payload) {
this.$store.commit(“progressReview/updatePendingProgress”, payload);
}

Obviously it doesn’t fix your concerns about being out of sync with the db, but hopefully it helps with the error anyway

@metalsadman Thank you for the codepen!!
I didn’t get that @save only fires if the value has changed. Makes sense now.
Before writing my actions and mutations, I was trying to test with console logs, but since I wasn’t modifying my state (yet), the saves weren’t firing at all.
@sontis: I’m grabbing the @save event on the q-popup-edit and calling an action to write to my API. On the q-input inside the popup, I’m grabbing @input and calling a mutation to set the vuex store.
Now that the state is actually changing, q-popup-edit fires the @save event when I click the “set” button, and the API only gets hit then, not on every keystroke.

I just ran into the same issue. I agree with @sontis - the recommendations for workarounds are great, but are definitely workarounds. If QPopupEdit emits a “save” event with v-model, it should also emit a “save” event when binding value instead. At the very least, when buttons are turned on and the save button is clicked… @sontis have you tried using a computed setter? https://itnext.io/anyway-this-is-how-to-use-v-model-with-vuex-computed-setter-in-action-320eb682c976 I haven’t tried it yet, but will as soon as I have time. It allows using v-model with Vuex, without adding an ORM package. Might trick the save event into happening