Using REACT in our frontend development

[Versión en castellano]This link opens in a popup window

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 ReactThis link opens in a popup window.

Why 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

What React?

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.

How do we use React?

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.

Arquitectura_global_esArquitectura_global_es

If you pay attention to it, you will be able to find a series of global services, including:

  • Internationalization support, built on i18next This link opens in a popup windowand using Proxia®’s language management support and translation layer.
  • Network layer based on standard fetch API, providing our projects with different capabilities as: CSRF support; long-standing requests – a request which could last minutes - ; simplifying the conversion of parameters to querystring, JSON and multipart; and websocket/long-polling connections.
  • A library which includes different components and utilities as network hooks¸ form components – dates, files, multiple select, repeat blocks and many others – and a routing engine optimized for a portal environment – multi-service – .

Using this global services layer, we could build the project specific code, adhering to an schema as the next one.

Detalle_servicio_esDetalle_servicio_es

Going into detail, I’d like to focus on:

  • We use TypeScriptThis link opens in a popup window, mainly because it provides us with a clear and well-defined contract by using its typed nature.
  • We have a model or entity layer using classes, enumeration and interfaces to define all object types our application is going to work with.
  • A network API layer helped by the definition of server endpoints according to OpenAPI This link opens in a popup windowstandard. This layer is able to automatically generate both code to query those endpoints and interfaces to model which information the server expects or will return.
    We use interfaces because we don’t want server API to condition how model should be defined. Using interfaces and properly designed client models, we are able to follow SOLID principles in our developments.
  • An control layer which uses the network API layer to work with the model. Hence, allowing: memory persistance, server data recovery, server update, etc. In this layer we use either the network API layer directly or solutions as Redux-Saga.
  • The view which just render information as directed by the control. This view modifies the model, through functions provided by that interaction layer.
    Besides, this view layer is utterly split between TypeScript specific code – the REACT one – and SASS code.
    If you ask me the reason behind this splitting I could answer you that this is a personal opinion. Although I understand the idea behind generating everything in javascript is just that, IMHO, i don’t like how it smells.
  • A routing layer, which controls our application screens. It works by calling the appropiate interactor attending to user navigation decision.

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.

Credits

Icons used are provided by Flaticon