Dropping Quasar is more than ’ because it has some trade off’, it’s a fear that the deviation from the Vue phylosphy & standards continue to esculate in the future & reaches a stage where it’s so fundamentally different from Vue is basics like @clickk events, but potentially many more.

We initially thought of Quasar as an extension to Vue, a GUI front end framework based on Vue. From a production point of view we thought that to use Quasar we would simply update & add to our existing Vue skillsets, but as fundemental deviations away from Vue fundementals grow within Quasar then the Vue based minimum skill-set advantage disapears. We don’t have the time to learn another adaptation of Vue, that’s based on Vue, but different.

Hope this explains our decision.

Dab’s

Hi,
My issue with these types of changes is that Quasar is becoming less & less Vue. When working a multiple Vue code bases this type of change is making it harder to maintain a common coding standard.
While the link aboave states what we must now do it does not explain why!

Unfortunately this has now put Quasar outside of the scope of approved development technologies for my company as the fear is it will become more & more diverse from Vue so we will be returning to ‘pure’ Vue.

q-table: column setting field to object.property syntax?
I have tried :
{
name: ‘name’,
required: true,
label: ‘Name’,
align: ‘left’,
field: ‘delDetails.name’, // Note object.property data assignment.
sortable: true,
},
but I never get the data value as held in the data array.

Primary data objects work OK :
{
name: ‘timeReceived’,
required: true,
label: ‘Received’,
align: ‘left’,
field: ‘dateTime’, // Note single object data assignment
sortable: true,
},

Quasar CLI: v0.17.23
Quasar Framework: v0.17.19

Any help/suggestions appreciated.

Regards.
Jonathan