When, some days ago, I told you about adaptability and maintainability, I introduced the idea of how we apply a set of patterns and norms to the development process of both our products and projects.
As you know perfectly, developing this idea in all its complexity could be quite hard. In fact, if you consider the simple thought that things should be done right, there are several facts hidden: the individual, what we are doing and even the technology. For all of this, I would like to focus on how we do things in web frontend development, and, in particular how we have adopted React.
Certainly, this is not an easy question. Despite the fact that Proxia® supports any frontend’s framework-or-library (as, e.g., Angular or Vue), it is also true that you must made decisions if you want to ensure the maintainability of products and projects in the future.
Although, I could have used any other solution, I think that using React was the best answer from the point of view of services’ aggregation-and-composition in a web portal. It provides us with a good balance between several functionalities as: market penetration; functionality; being less opinionated and being simpler when you want to create a not monolithic fronted which should be orchestrated from the backed layer.
Obviously, these types of decisions are not set in stone, even less in a so dynamic market as the technological one, in which Heraclitus’ saying about flow and changing fits smoothly
You could ask me; what kind of question is this one? React is React. Actually, we have two different React approaches, the functional and the class-based one. I decided to go on with the functional approach and using, therefore, hooks and components.
This decision was based upon two different reasons. On the one hand, React has made an important effort to move on the component and hooks-based approach. On the other hand, I think that this approach is lighter and, hence, simpler to understand.
Nevertheless, I’m perfectly conscious that the functional approach is not a perfect one, since it manages some concepts in a quite complex way, and you should notice that being lighter, sometimes, goes against clarity. But, as you know, there is never a perfect solution, just a solution, and the actual important thing is being able to recognize its limits.
The truth is that adopting React has not been easy and, even, we haven’t followed a straight path. We have gone through several evolution steps, until we have managed to use it in a way that looks like the one shown in the following image.
If you pay attention to it, you will be able to find a series of global services, including:
Using this global services layer, we could build the project specific code, adhering to an schema as the next one.
Going into detail, I’d like to focus on:
When it comes down to it, we are not inventing anything but just using concepts and known architectures in web frontend development.
In any case, by using this consciuous and controlled approach, we are able to guarantee our clients both maintanbility of our solutions and the adaptability to new changes.
Icons used are provided by Flaticon