My Vue/Nuxt Architecture Part 2

Ifeanyi Ibekie
Vue.js Developers
Published in
4 min readMay 15, 2020

This is a continuation of my series that talks about my approach to writing Vue/Nuxt code. if you are new to my series you can begin here https://medium.com/@dop3ch3f/my-vue-nuxt-architecture-part-1-db5bcb4970b7

HOW CAN WE SEPERATE OUR PURE CODE FROM SIDE EFFECTS

With our understanding of pure code and side effects, we need to identify sections within our code that we can call pure and side effects.

our sample vue instance

Using a default Vue component as in the example above (since most of Vue code will be written in components), we can say that state and its mutation with deterministic values can be seen as pure and whatever that would yield an uncertain value is a side effect. it is generally bad practice to directly leave the values of side effects to state as it would then make it unpredictable. So the idea is to separate the side effects into services.

sampleService.js

Using what we’ve learnt from the previous step about wrappers we have rewritten our Axios call in the previous example to a separate file and wrapped it in a ServiceResponse class that serves as a default return type structure for all our services. We’ve handled for all the cases we were aware of and also grouped any unexpected errors using the try-catch block making the side effect pure. This is because anytime we get a ServiceResponse status value as true we know its about to give us data we expect and if its false we know its data we don’t want or an error.

our updated vue instance

With our successful separation, Our new Vue instance clean and readable. The final step is the easiest of all.

HOW DO WE EFFECTIVELY MAKE THEM COMMUNICATE WITH EACH OTHER

This arguably shouldn’t be a step but it’s necessary for the closing remarks. With the proper implementation of the previous steps, it’s easier to join them together and have them interact with each other by simply using the status and data fields. This makes the side effects seem pure by just simply testing for boolean values which are exhaustive.

our final vue instance

In conclusion, any good architecture should provide answers to the three questions asked in this article. This is a basic lesson to teach the management of side effects in Vue but not limited to Vue as this approach can be applied in any language or framework. All you need to do is know your side effects, wrap them as good as you can to ensure they don’t surprise you from their end and expose them neatly to the pure side of your code. This way your debugging is easier because you can instantly know where a bug is.
To take this tutorial to the next level you can go further by breaking down your services into services and repositories. Your Repositories (API, LocalStorage) will represent the data sources and related (you can wrap them as well) while your Services can be an amalgamation of your Repositories with your business logic. For instance, your LoginService can use the API Repository to fetch the login user details and cache it using the Storage Repository. This goes a long way in making your code pure and in the case of coding a front end application, it would make your application the perfect middleman between the client and the back end application. I hope my thinking approach will stir up a thirst for clean code in you and will have a positive impact on your software development endeavours.

--

--