Ask HN: Vue developers, how do you do your Vuex?

6 points by jgalvez 6 years ago

I recently wrote an article where I discuss code organization practices for Nuxt apps:

https://vuejsdevelopers.com/2018/07/16/7-tips-large-nuxt-app-vue/

There I mention https://gist.github.com/galvez/57771b43caf26cdbc9f903c0e81dbb63

A little helper I wrote to put my Nuxt app's Vuex Store together more cleanly.

I also came across this recently: https://gist.github.com/uriannrima/d131db13256255d2f07d9e33e7adca63

Which seems like the beginning of a good idea. I'm looking to know other approaches and ideas to try and improve this further.

If you're Vue developer and have got something along these lines to show, please do!

cutety 6 years ago

I wish there was more information out there about what some more people are doing with Vuex that wasn't trivial "how to put api data in store". So, thanks for your contribution to putting a bit more advanced Vuex tips out there. But, I'm mostly happy with Vuex (been using it since v1), and v2 actually fixed 90% of my annoyances with using it. I essentially use just use namespaced modules as database tables (so modules just store specific types of records), or a simple k-v module that will get used for components that need one for simple caching, and sometimes as a poor mans GenServer as a way to track shared state for multiple short-lived components. I try to keep any data more than a few children need in it, so I don't have to keep passing data all around. Really if the data isn't specific to a component (e.g. is this button showing?) I'll usually put it in Vuex somewhere.

However, one thing I think is being heavily underutilized is the plugin api. I got sick of writing boilerplate code for different api endpoints/modules, I thought I'd give making a plugin a try to take care of it for me, and now I'm super annoyed I had been just ignoring it before. I was able to get rid of all my boilerplate code, now if I need to add a new endpoint/module I just have to pass the type name and the root endpoint it can be reached at, and because I'm following the JSONApi spec, the responses to things are then able to find the rest of the way around the api programmatically through actions. I then setup a few Proxy's, so that when you get a record from the store, you can fetch relations data from it's module by just accessing it's name like you would on a Rails/Django setup `record.child` will lookup the childs module in the store and pull fetch it if it has been loaded. Now that I don't have to put up with my biggest annoyance, there really isn't anything I'm particularly unhappy with about using it.

But, it did get me thinking about what kinda cool (if only as a proof-of-concept) things you could make with the plugin api. So, to get a little more familiar with it, I recently spent a day or so making a generic Queue plugin that will create arbitrary queue modules, as well a prioritized queues, and uses Proxy's to provide an api for easily working with them. I don't see any real need or use cases for it, except for why I made it, which is my next PoC plugin -- a background processor (e.g. Sidekiq/Celery) using WebWorkers and Vuex as the queue/bus -- and even then that's not going to particularly useful for most people. It just seems like a neat idea to play with.

My queue plugin in is (as of now) on GitHub[1] if you want to take a look for whatever reason. The documentation is pretty sparse, and likely not 100% accurate, but it was working the last time I was working on it (also the first time... one of these days).

I also plan to eventually rip the JSONApi plugin I made out of the app and open source it too, as I could see a few people getting some use out of it.

[1] https://github.com/NickHurst/Queuex