Yoigo eCare frontend stack: What’s it like?
I’ve been working in the frontend of Yoigo’s private area over the last few months. This project was called Lumiere, yes, like the candelabra from Beauty and the Beast. We have a lot of peculiar names for the projects: Pikachu, Thor, Optimus Prime, etc. Maybe we could talk about that at another time…
Here at MasMovil, teams are organised with our system of tribes and squads. We identify the requirements or issues in each planning or refinement, and the squad aligns itself to find the best solution. This way, tribe or squad members have a high level of autonomy when they tackle the issues. This also affects the technology stack.
Our stack
We have squads working with different frontend technologies; some stacks are more similar than others, and our stack consists of:
- Angular
- NgRx
- Angular Material + Sass
However, every squad shared some core ideas:
- Redux pattern.
- Robust testing: unit and e2e tests.
- Continuous integration: GitHub, CircleCI, Kubernetes and Slack as Pablo Moncada explained in his post.
Angular
Lumiere is made with Angular 6 and Typescript. We try to update them and take advantage of new releases, but maybe what you are asking for is:
Why Angular and not React, Vue or another one?
Everyone is always talking about the benefits and disadvantages of each framework or library. We could give a list of good reasons, but we would get into an endless discussion about what the best super JS framework is. And, worst of all, that wouldn’t be answering the question.
Angular is excellent, but to answer honestly we should bear in mind the following:
- The new release of Angular 2 in September 2016 and its huge popularity across the community at this time.
- The large number of projects started this year, as a result of the fast growth of MasMovil.
- The previous experience of the Yoigo website team with Angular; their help was essential!
In this context, Lumiere was started, and Angular was the most reasonable solution to be able to release a new private area. A lot of times we wonder about if Angular is the best option. For now, we can’t see a really good reason to replace it.
Ng-Rx
We are dealing with a really big project. As a user, you can check your consumption, invoices, tariffs, have access to exclusive offers, buy extra data, etc. But also, there are multiple business integrations such as Google Tag Manager, a data management platform, push notifications and GDPR to name a few. That’s why we use NgRx to manage the application state.
NgRx is an implementation of Redux pattern. As we know, it’s based on the following ideas:
- The application has a single source of truth, the state.
- The state is immutable (read-only), and it can only be changed by emitting an action.
- Changes are made with pure functions (reducers). They create a new state through the current state and an action.
How do we organise our components?
Our components can mainly be divided into two types:
- Components (aka dumb or presentational) must render UI, showing the input data. Also, these components can send events to change some part of the store.
- Containers are in charge of dealing with the state, subscribing to the store and dispatching actions to change the state. Also, they pass data to and listen to possible events from components.
As applications grow, we have a considerable number of components interconnected through services to share some information, and everything is a mess. However, NgRx makes it possible to have a unidirectional data flow from store to containers, and from containers to components.
Another interesting advantage of using NgRx consists of indicating to Angular when the change detection mechanism of the components has to run. This is possible if the changeDetectionStrategy is set to “onPush” for every child component, and because our data are immutable. In other words, a component will only change if an action has happened. This improves the application’s performance because Angular stops running change detection every time.
Angular Material + Sass
We have recently refactored every Bootstrap style to Angular Material. As our designers chose a theme based on cards, Angular Material fit our needs perfectly.
Our layouts and UI components consist of:
- A simple grid using some Sass mixins.
- Angular Material theme with a catalogue of colours.
- Some Placeholders to "extend" cards, buttons, links...
- Flexbox to place each component's elements correctly.
By applying these points, we can get clean and maintainable CSS. Remember DRY!
Testing
It isn’t an option. We have to test!
Angular CLI allow us to make things easier for us. It provides a great environment to create and launch our unit and e2e tests. We only have to add some configuration if we want to customise something:
- Unit tests: we use Karma and Jasmine, although we prefer the Mocha reporter because it shows a cleaner and elegant result.
In the case of the effects, we create our RxJS marble tests with the help of the jasmine-marbles. This library allows us to mock actions and services and compare observables’ behaviour easily. It is worth noting that we avoid having Angular or TestBed dependencies, and we don’t use TestScheduler to control the time if not necessary.
Here there’s a Gist if you want to see some examples of our Marble tests.
- e2e tests: Protractor was the most reasonable option in the same way of before. But we have to think our e2e strategy again because our backend has some dependencies that not always work as expected. It might be an excellent opportunity to try another e2e test framework since debugging with Protractor can be very painful.
We use the Page Object Model to keep tests and element locators separate. This way, our e2e tests are more readable and maintainable because locators can be reused.
As you can see…
We love technology, we like what we do, and we try to improve our app every day. That’s why the objective of this post was to show you the Lumiere stack. Please feel free to relay your comments and suggestions. MasMovil is an ego-free zone.
Happy Coding!
