Developing mature components with the Component Cohesion Principles in Vue.js
In this publication I will build on the Principles of Component Cohesion, described in the book Clean Architecture: A Craftsman’s Guide to Software Structure and Design by Robert C. Martin (a.k.a Uncle Bob), for creating not only mature components, but also mature relationships between components.
Summary
What is an component?
Reuse/Release Equivalence Principle (REP)
An example and a practical reflection
Common Closure Principle (CCP)
An practical example
Common Reuse Principle (CRP)
Reflection
I can't apply the three…
Conclusion
What is an component?
Thanks to the advent of SPA's frameworks and creation libraries, we started to hear more about the components.
In the environments that these provide us, it is simple understand an component — more implicitly than explicitly.
In the environments where we do not use frameworks with greater power of opinion, it becomes more difficult to distinguish a component. Therefore, it follows the definition of Uncle Bob himself:
Components are the units of deployment. They are the smallest entities that can be deployed as part of a system. In Java, they are jar files. In Ruby, they are gem files. In .Net, they are DLLs. In compiled languages, they are aggregations of binary files. In interpreted languages, they are aggregations of source files. In all languages, they are the granule of deployment.
Complementing the mention above, in Vue.js are vue files!
Many understand components in Vue.js 2 as classes with super powers. The reading of these principles is at a level of granularity slightly greater than that of the classes.
However, I believe that we can take advantage of these studies to create more mature and professional components and relationships between them.
Considering this perspective, I will explain each principle followed by an example or reflection.
Reuse/Release Equivalence Principle (REP)
This principle instructs us to provide mature reuse when it comes to components. Such reuse comes with tracking the launch of each component.
Following the same premise of launching new versions of applications that we consume on a daily basis, when a new update appears, we check the changelog in order to make the decision whether we really want to update it or not.
When we provide components that are reusable, without proper tracking of releases, features or components that consume them, they are blind.
In conclusion, the idea is that such components are released separately, versioned and tracked to ensure the safe reuse of the code.
An example and a practical reflection
Framing for the context of Vue.js components, most of the time we launch them using a Pull Request, grouping a set of commits. Thinking that way, in a well-defined continuous delivery environment, it makes sense to create a different Pull Request for each component that provides reuse.
With that, we left room for documentation of the changes, in addition to the possible explanation of them by affirmation tests.
Reading this way seems obvious, but how many of us do not circumvent this simple precaution, sacrificing the safety of dependents right?!
Common Closure Principle (CCP)
As the author himself says, this principle is a reformulation of the SOLID Single Responsibility Principle (SRP), but for components.
In short, it tells us that a component cannot have several different reasons for change. It tells us which items should be grouped together — I use the adaptation “items” because the original reading deals with classes.
Here, the message is that when we have a change, it is preferable that it be in one place rather than spread around.
An practical example
Supposing that we have a container component containing two inputs: one for state and one for city. When the user selects the state, we will make an asynchronous call to an arbitrary point, returning the list of cities contained in that state.
If the container contains the state input together with its asynchronous calling logic, the reason for changing this component would be the container logic (not specified) and the input logic. Two reasons. Not to mention a possible logic in the city input that was not mentioned.
When maintaining this component, we have to worry about 3 logics with different reasons, going against the hand of reading this principle.
Common Reuse Principle (CRP)
Finally, the focus of this principle would be not to allow dependence on resources that the dependent component does not need.
According to the author, depending on a function of another component creates a weak dependency, and if what is being used requires a more profound change, the change must also be responsible for the component that uses it. Even if the component that uses it doesn’t care about changing it.
This principle says about items that should be together, but more about items that should be separate.
Reflection
We have a strong relationship with the SOLID Interface Segregation Principle (ISP), where we cannot depend on something that contains items for which we do not use.
We see a contradiction with the CCP. While one talks about joining components that change for the same reasons, another says about breaking weak dependencies between components.
I can’t apply the three…
As the author reveals, the principles struggle with each other. While REP and CCP propose to increase our components, the reading of the CRP goes against the opposite.
By implementing the principles, we can only succeed in two. One will be abandoned.
In the diagram below (Tension Diagram for Component Cohesion), there are the edges describing the cost of abandoning the principle of the opposite vertex.
Conclusion
There is no right or wrong about the formulation of components following these principles.
They are more associated with needs according to the time and moment of the project.
The great art lies in discerning the best for the moment and applying it.
References
- Clean Architecture: A Craftsman’s Guide to Software Structure and Design de Robert C. Martin
