Keagan Chisnall
3 min readJul 12, 2018

--

Totally agree re: microservices complicating the traditional frontend models. While I am not specifically trying to develop the solution, considering the time I’ve put into my own models, I’d love to contribute to a project around it and/or see what you mean in code/structure?

As you mentioned the challenges with the store, I’ll share another lesson I think I’ve learned: The store is not your controller (in an MVC pattern); it’s the store.

If we put application functionality into the actions of the store, that store will grow extremely quickly and no longer resemble a store, but rather the controller of the module/app. I did this for a long time until I realised how much trouble it was getting splitting modules into submodules just so my store files weren’t so unwieldy.

My new module model has a minimum of 4 files: module, routes, service, and store. The module file is an export of a customized instance of the ModuleClass I’ve made which the App “installs”; referencing all the other files in that installation process. The routes file is just an array of routes to add to VueRouter. The store file is *just* the store of the module, where Actions only call Mutations (except if it’s very simple store function). The service file is my module’s functions (initialize, add, remove, run, draw, etc) and any “service variables” come only from the store.

This extra service file makes the store actions VERY straight forward, meaning your store can hold all your actions without being unreadable.

Also see how I reference my store dispatch calls — app/module/action

And because the service file is just a collection of exported functions, you can have multiple service files and import specific functions when needed.

Also, if you want to use async in actions it’s not straight forward (or so I found). Splitting them into a service file means you let your store use the promise structure and your services use the sweet async syntax (or whatever you prefer).

I mean, like with any pattern or structure, the benefits scale; and so for smaller stuff, sure, put everything in your actions. Past a certain point though, the bit of extra effort in using things for what they were made for is worth it!

--

--

Keagan Chisnall
Keagan Chisnall

Written by Keagan Chisnall

I have a background in process engineering, management, and consulting; but my passion is making systems and processes more efficient. Visit me: chisnall.io

No responses yet