Quasar + Vuex
I’ve been deep diving into Vuex and built a Quasar sample app based on this article.
git clone https://github.com/beebase/learn-vuex-by-building-notes-app.git
The code in the article is outdated so I’ve used latest syntax for
Vue ^ 2.1.10
The solution demonstrates vuex basics with a todo list.
Vuex is very cool. Once you know the pattern, it’s basically re using it over and over again.
And it feels very organised. Here’s a sample of that pattern.
And it’s VERY cool how vue-dev-tools in Chrome keeps track of all the states that vuex goes through.
Yup. Vuex is pretty cool. It makes reasoning about your data a lot simpler.
Excellent post, Martin!
The first pic in particular is worth its weight in gold.
@Jon I was hoping so! It always surprises me why there’s never such a “mental picture” shown, when reading articles about vuex, redux etc…
Describing it in words makes it way too complicated.
@Martin Of course, I’ve just realised the weight of a .png is negligible
Nonetheless, I’ve printed it and pinned it on the wall above my monitor for easy reference as I’m about to dive into Vuex and AXIOS (god help me)
I’m just starting with Vuex + Quasar and find it awsome so far.
But I have a question buzzing me:
My backend is Restify and Rethinkdb as DB.
Can anyone point me the right way of updating the store when a new product has been inserted in the DB ? Doing a massive fetch doesn’t sound very reactive to me
Thx in advance!
Thanks for share : )
@Martin this is a great example, thanks for sharing this.
I simply noticed that all the actions in this example are synchronous, so the actions layer is not mandatory. If your mutations names were lowercase then you could directly use ‘mapMutations’ instead of actions + ‘mapActions’. Vuex is really cool
@Diferno If I’m right since the RethinkDB team stopped working on Horizon you have to write your own websocket stuff for your client to react to DB changes. That’s why I’m using firebase with https://github.com/vuejs/vuefire
@LaurentPayot I’m also using Firebase as backend. It’s great, but I’m having trouble sometimes controlling all the firebase listeners. Especially when the data model becomes complex/relational, needing data from multiple nodes at the same time, Firebase listeners may start acting like a christmas tree.
I’m not using vuefire or vuexfire, but I wonder if any best practices have evolved regarding listeners.
If you know of any ‘must reads’ let me know please.
All in all I find it though to get the right balance between normalising/denormalising data and keeping listeners under control.
Maybe Firebase is just not fit for highly relational stuff.
In an ideal world, I’d rather use a real time graph database like http://gun.js.org/.
GunJS looks promising, but it’s not production ready yet.
@Martin no problem for me so far with vuefire but my app is far from complete. It’s true that, just like with any other nosql database, relations are painful.
I really enjoy the Firebase authentication system, although it was bit tricky to implement a complete solution with usernames. Unfortunately they don’t care about i18n (english only password reset page etc.). The free hosting is something to mention too.
Just like you I had a look at gun.js in 2016, and keeping an eye on it