Modularizing the logic of your Vue.js Application
TLDR: In this article, we discuss building a functional core for our Vue.js application logic. Code available at https://github.com/vinicius0026/modularizing-logic-in-vue
This is the third article in our Structuring Large Vue.js Applications series. Here is the full list of released and planned articles:
- Properly typed Vuex Stores published May 13, 2020
- Adopting TypeScript in your Vue.js Application in a sane way published May 14, 2020
- Modularizing the logic of your Vue.js Application published May 15, 2020 — You are here
- Data-driven components — published May 25, 2020
- Handling data at the edge of your Vue.js application — published June 1st, 2020
As an application grows, it is, unfortunately, common to see poorly designed components, with a lot of duplicate code, business logic scattered across methods, complex logic embedded in the templates, and so on. The components become large, brittle, and hard to change and test. The application becomes increasingly hard to evolve, sometimes reaching a point where the developers are eager to start from scratch, preferring a costly and risky rewrite than handling the current application state.
It doesn’t have to be that way. We can and should do better. In this article, we will discuss moving the bulk of the application’s business logic into a functional core that will be easy to reuse, easy to test and change, and which will lead to smaller, leaner, and more maintainable components.
We will pick up from where we left in our previous article, so you might want to check that first if you still haven’t.
Interfaces and Functional Modules instead of Classes
When we discussed adopting TypeScript in Vue.js applications, we took a somewhat unconventional route. Instead of modeling our data around classes, we have defined very lean interfaces to add type-annotations to our data. We have only used the fields that make up our objects in the interfaces — we have not mentioned methods or any operation over the data yet.
This article does not aim at doing an in-depth debate about Functional vs. Object-Oriented programming paradigms. Both have pros and cons, but I tend to prefer a functional style, because it is easier to follow and to test, in my opinion. Thus, we will use a functional approach to build our application core, and we will try to show how it leads to a modular, testable, and reusable codebase.
We will continue developing the simplified Invoice application that we started in the previous article.
Planning the app functionality
Before we jump right into the code, let’s talk about what functionalities we need in our application. In a real scenario, we would probably receive the requirements from a task description developed by a product team, or, if working on a side-project that we fully control, we would define that ourselves.
For our simple app, we will need ways to create and manipulate invoices. This will involve adding, removing, and changing line items, selecting products, and setting rates and quantities. We will also need a way to instantiate User and Product objects easily.
As we did for the types definitions, we want a modular way of building these functionalities.
Building our modules
We will put our modules inside a modules directory under src. We will split the functionality into as many files as it is sensible to do, grouping related functionality into single modules.
Let’s start with the User and Product modules:
These two modules are very simple and similar, but they serve as a container for all the functionality related to users or products we might need down the road. Even though it looks that we are repeating code, we should not try to unify these create functions in any way — that would cause coupling between unrelated concepts and would make the code harder to change.
Notice how we have defined default values for all the parameters. This will allow us to call the create functions without passing arguments and still have a valid object of the appropriate type.
One thing you might be concerned about the code above is that we are listing all of the fields as individual parameters. We only have a couple of arguments in each of the create function, but the number of parameters could grow a lot as we make our models more complex. We will ignore it for now, but we will revisit this when we discuss defining a clear application boundary in a future article.
Even though we have declared the LineItem interface in the same file as the Invoice, we will use a separate file for the Invoice and LineItem modules. We could group the invoice and the line item modules using a directory, but we will keep it simple and flat for now. You can use any folder structure that suits your particular situation.
The lineItem module will be pretty simple as well:
Let’s move on to the Invoice module now. It will be a more complex module, so we are going to stub out the functions before implementing them.
Developing the Invoice module with TDD
When we modify the line items in an invoice, by adding, removing, or changing a line item, we have to recalculate the invoice total. This is critical data in our application — we cannot afford to have the wrong amount calculated for the invoice — so we should test the invoice module thoroughly. With our modular core logic, it will be pretty straightforward to add tests.
When we scaffolded this app, we didn’t add any of the unit test features available, but vue-cli makes it very easy to add plugins to existing projects. We will use jest to write our tests, and we can add it to our project by running:
$ vue add unit-jestThat will take care of installing and configuring jest to work in a Vue project. Let’s write a few tests for our Invoice module.
These tests are a little bit lengthy, but they are easy to follow. We start by ensuring that our create function in the invoice module returns an empty invoice. Then we move on to test the other parts of our Invoice module. We have added a testData function to help creating objects used in the tests.
In a production-grade application, we would add more tests, especially to cover edge cases, making sure our module would work in every possible scenario. But for this article, this is good enough.
We should now run these tests:
As expected, the tests fail because we haven’t implemented our functions yet. Let’s do that now.
We have created two helper functions to avoid repeating code. The first one was the calculateTotal function. It takes the invoice and returns the total amount. It does so by first calculating the subtotal for each line item, using a new function we have added to the LineItem module, then summing all the line item totals. Let's see what the LineItem module looks like now.
The calculateLineTotal function is very simple. It just multiplies the rate by the quantity. Still, having it in a separate function makes our code easier to follow and easier to change.
Back to the invoice module, we can see that the setLineItem helper function takes an invoice and a list of line items and then returns an updated invoice with the given line items and the calculated total amount.
With these helper functions in place, implementing our public functions is very simple — they just need to generate the new list of line items (based on the operation) and use the helper functions to return an updated invoice.
And now our tests pass!
Using the modules in a Vue component
Let’s rewrite our createInvoice method in the HelloWorld.vue component, just to have a taste of how we use our modules in a component.
Again, this is a contrived example, but it already looks better than before. We now have the objects with the appropriate type from the modules’ create functions (instead of having just the type inference). In a more realistic scenario, the user would be the authenticated user; the product would come from some selector that reads from a product list; the rate and quantity would be set in the UI using inputs; and it would be possible to add/remove/update line items directly in the UI. We will build those components in the next article.
Wrapping up
At this point, we can have a fair degree of confidence that our invoice related logic is working. We should probably add some more tests, but we have a great baseline to develop our invoice application.
We have built a solid functional core for our application logic. We are not spreading the business rules across components and, when the time comes to wire this functionality up with the UI, the components will end up being a skinny layer to connect the user actions to our core modules.
Let me know what you think of this approach in the comments!
Shameless Plug: If you liked this article and there are openings in your company, I’m currently looking for a job as a Senior Full Stack Engineer. You can check my Linkedin and drop me a line at vinicius0026 at gmail dot com if you think I’m a good fit. Cheers! 😃
Originally published at https://viniciusteixeira.tk on May 13, 2020.
