@9223000 use it inside the content of your q-dialog https://codepen.io/metalsadman/pen/yWKQEo, styled the width and height of the q-card inside it.

@Julia you will have to make use of the body or other body related slots to customize how your table’s rows/columns are displayed. take a look in my samples https://codesandbox.io/s/q306jwnjx6 click “home” -> “Table”.

@supercat disabled is native attribute, use disable props.

@Julia try putting it in your quasar.conf.js file

builder: {
    // https://www.electron.build/configuration/configuration
    //   appId: 'com.cloudbase.aldrin.primuscard',
   win: {
     icon: 'src-electron/icons/icon.ico' // your icon file here
   }
}

@sontis well that’s the way to do it, beside this is normal behavior for vuex in strict mode coz you cannot simply mutate an array it’s entirety. what you can do is normalize your data in your vuex state, and then make a local copy map it to be an array (coz QTable data prop only accept an array), and in your mutation function you will have to filter it like an id to target that specific element in your state. keep on reading and you’ll get same answers :). you keep repeating it’s a quasar issue when it’s not :(.

anyway updated the sandbox using lodash https://codesandbox.io/s/q306jwnjx6.

@sontis yep that’s why do my suggestion to copy it in local and do the mutation in the events. then in the watcher re assigned it to the local data. you should try to figure it out imo. the example is there to get you started.

@sontis you should mark as solved concerning the thread title since there’s nothing wrong with the event. your real issue was mutating your store, anyway here’s what i got https://codesandbox.io/s/q306jwnjx6 click “home” -> 'vuex table`, check the consoles, dunno if this is what you did, i would still suggest making a local copy and run your action/mutation @save event since that shows in vue devtools and is the vuex way of doing it.

@sontis hard to figure what you are actually doing in your vuex mutation, like i said in earlier post copy it first locally then that local data is what you should feed to your QTable’s data props then on your QPopupedit’s save event is where you call your actual vuex mutation/action. Per your thread’s title, there’s no issue there.

About the vuex issue, would take some time for me to exactly emulate what’s wrong unless you provide a minimal pen of how you were doing it. I will try tho…

@sontis it’s there in my example, @save event you have access to the initialValue and the newValue, you only commit the newValue when all goes well and can still revert to initialValue if something fails. like i said this has nothing to do with vuex or whatever data source you are using, the idea is the same. It’s a pretty solid component tbh and I don’t think in this case there’s a need for something to change, since clearly the functionalities are working as they should be.

@ssuess uncomment this line… export default function (/* { store, ssrContext } */) like this export default function ({ store } ) then you’ll have access to your store. you don’t need to import the store itself.