
Ask HN: Vue developers, how do you do your Vuex? - jgalvez
I recently wrote an article where I discuss code organization practices for Nuxt apps:<p>https:&#x2F;&#x2F;vuejsdevelopers.com&#x2F;2018&#x2F;07&#x2F;16&#x2F;7-tips-large-nuxt-app-vue&#x2F;<p>There I mention
https:&#x2F;&#x2F;gist.github.com&#x2F;galvez&#x2F;57771b43caf26cdbc9f903c0e81dbb63<p>A little helper I wrote to put my Nuxt app&#x27;s Vuex Store together more cleanly.<p>I also came across this recently:
https:&#x2F;&#x2F;gist.github.com&#x2F;uriannrima&#x2F;d131db13256255d2f07d9e33e7adca63<p>Which seems like the beginning of a good idea. I&#x27;m looking to know other approaches and ideas to try and improve this further.<p>If you&#x27;re Vue developer and have got something along these lines to show, please do!
======
cutety
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](https://github.com/NickHurst/Queuex)

