@s-molinari definitely it was a good food. About stateless he proposes to reverse the mvc and just pass the state with control, which in my opinion works superb, I used that.

You took that reactivity to another level, wow - whole reactive system, not only visuals. I agree it would be an overkill. In context of Quasar, I’d like to think of specific use cases, where such architecture level decision would be necessary. As for now, I found something like this:

Imagine QTree, where underlying hierarchical data model is lazy loaded. Changes are synchronized with backend in real-time allowing collaboration (as in google docs), with multi selection and multi cursors. And of course this data model and QTree themself allows to work offline (mobile) and supports non hierarchical data model actions (drag-n-drop and copy-paste of subtrees). Ideally data model would support peer-to-peer synchronization. Oh, sweet dreams…

@s-molinari Yep, he opposes querying backend data from client side in larger projects.
It is his opinion of course and our chance to disagree.

I posted this link, because it is another look at “reactivity” as a whole paradigm. Nice read for people used to think in terms of jquery/events.

Frankly, I’m not too fond of GraphQL either. I always assumed, that the client side technology, Vue, VueX, Quasar(?) etc. will go more in the way of this:
https://pouchdb.com/

There is this article:

https://www.infoq.com/articles/no-more-mvc-frameworks/

I find it a good read and can recommend not for blindly following but rather as a “mind expansion” ha ha

@Hawkeye64 honestly, I would’t cry at all, if the rest of the compound, interactive components (Table, Tree, Carousel maybe, etc) would be pulled out of standard library / core, and converted to AE. It is orders of magnitude easier for a developer to contribute to single AE component than to create PR to the whole Quasar framework. Developer traction is my main concern in the plan of global Quasar domination

@digiproduct I assume this argument has been made before. App Extensions are the answer to people, who wants to build their own components or extend existing ones or integrate totally other functionalities from another frameworks/libraries, without need to pollute the standard library. AE is ingenious idea, and common with other succesful systems, be it Python with PyPI or Javascript with NPM etc. There are different release cycles in standard library and user created libraries. There are different quality guarantees with those. AE components are not obliged to keep Quasar API conventions or any other “expected” behaviour. AE allows to build a community around Quasar which is crucial (developer traction). Keeping everything in “standard library” would be in effect closing the Quasar to developers (who would decide what is and what is not “worthy” of SL?), and that is why it needs to exist.

BUT you have a point, that AE system, AE components/libraries, AE ideology should be more promoted/presented/shouted. BUT, this AE technology/API/best practices, are as for now created and hardened, so I think it is quite wise to battle test this AE subsystem with several components and then and only then build a “presentation layer” with extension search, discovery etc. I am very grateful, that there already is such an easy way to incorporate those AE into your own projects. I assume that it will be slightly changed/upgraded in the future (as everything) but a realization, that somebody thought about that makes me sure, that everything with AE will be OK.

As for now, it is important to just write as many AE as possible and test more and more possible AE use cases. I’m somewhat sure, that the impact of this AE technology will greatly surprise us all in the future.

@sontis if your problem is based on unability to update Vuex, then this library surely solves that:
https://vuex-orm.github.io/vuex-orm/guide/store/inserting-and-updating-data.html#inserts

if your problem is based on QPopupEdit component behaviour (events, model), then I do not have an opinion on that.

@s-molinari in theory - yes, in practice - no

It looks as your app is big enough to use this:

https://github.com/vuex-orm/vuex-orm

In small use cases it is ok to create “spagetti” with those accessors/computed/events stuff, but in some point, the VueX querying is better. There are some other additional benefits: data models, normalization, easy synchronization.

@digiproduct don’t think, just do it Don’t you deserve something nice for yourself?
(and remember to post a picture of your new setup).

@digiproduct “Live Server” extension is nice, too.