My Vue/Nuxt Architecture Part 1

In building any application the first question is “what architecture or design pattern should I use”?. Very few of us stick to the default shipped with whatever framework we are using and vue is no different. We are social animals with different experiences in life. Experience is a great factor to perspective and it is as a result of these factors, that there are so many approaches to the same thing.

If you are familiar with Nuxt you know that it comes predefined with a style of separating concerns into folders which to me is beautiful. I mean it just works, my architecture is built on it because it is in my humble opinion one of the best code structures out there and I would strongly recommend to try and structure your frontend code like that in whatever framework you are using.

Before I dive into the details, I would like to share my thought process towards this architecture. My architecture is built on two things PURITY and SIDE EFFECTS. Anything Pure is anything that its behaviour is 100% predictable, be it a function, class or anything.

1+1 = 2

Using the example above, a summation is Pure in the sense that whatever the values are, you are sure that whatever it results in would be the summation of its entries and that is predictable. Anything considered a side effect is anything that may yield an expected result, an unexpected result or an error. e.g an API call. We as developers don’t like side effects because they lead to bugs which make us look bad and most times especially in building complex applications, we always end up having to integrate side effects in our codes.

With a complete understanding of purity and side effects, my thinking pattern asks these questions:

1. How predictable can we make our side effects
2. How can we separate our pure code from side effects
3. How do we effectively make them communicate with each other

HOW PREDICTABLE CAN WE MAKE SIDE EFFECTS

My answer to this question is simple “WRAPPERS”. We wrap each side effect with predictable wrappers to alter their outputs and in turn making them predictable.

Consider the sample class above. It is initialised with 3 parameters namely:

1. Status (Boolean)
2. Message (String)
3. Data (Any)

The status value is supposed to indicate success (true) and a failure or error (false). The message value is supposed to help with logging and alerting such that if it is a successful operation you can say append the value of message field in an alert or log it to console if an error. The data field can exist in many ways to represent the data you expect from the side effect when it’s good and bad. Let us use this class in a very simple example of an API.

From the picture above we see our previous class for the side effect. The sideeffectApiCall function mimics an API call to a backend using Axios (you should know about Axios if you’re reading this. if you don’t hurry and google it). In that function, we call an API and try to handle all the states in which it can occur or we care about. one thing similar is for every state we know of, we turn it into a repository response class instance so we can easily handle it in its caller the main function.

The article is getting too long so to summarize. The plan is to wrap our side effects in a homogenous format to make it predictable and there may be exceptions where you can never know all the possible outputs of a side effect the trick is to handle all you want and collectively group all you don’t want and that’s where the real skill in this architecture is. In the next article, we would look at how we can separate our pure code from side effects, Happy Coding.

https://medium.com/js-dojo/my-vue-nuxt-architecture-part-2-9d0e7f284826