Simplifying Angular components with Facade

On an Angular project, you have your components, managing the interaction with the user, and, quite often they can become massive and complex, making it hard to refactor anything, and for newcomers to understand the code.

One way to improve this situation is using the design pattern Facade. This pattern is used to mask, or hide, more complex interactions.

When structuring Angular projects, I like to think like this: the component should worry only about user interaction, showing and receiving information.

If the component needs something, it shouldn't go after it itself, but rather request it from someone else.

For example, the user enters a page with a list of products. The component shouldn't be the one to go after the products list. It should ask for the facade service to fetch that instead. When the component receives the list, it can display it to the user. That's the only thing the component should have to worry about, the interaction with the user.

The component should communicate only with the facade, using it to simplify the processing of information.

Think about the product list again.

The user enters a page with the list. The component goes to the facade and requests a list of products. Now, where the facade will get this information and if it will need some transformation are questions that don't concern the component. It's the facades’ job to go and get what the component asks. It should deliver it in a way that the component only has to show it to the user.
You can think of the facade like a secretary or a butler (like Alfred and Batman).

  private findAllProducts() {
    this.productsApiService.findAllProducts().subscribe((product: IProducts[]) => {
      this.products = books;
    });
  }

If you are using some state service to manage data, it's the same idea.

Remember that the component should communicate only with the facade, so it doesn't have to know how this state service works or what methods it has. The component should go to the facade, and the facade should get this state information.

Only the facade should know where to get the information, the component doesn't have to.

Think of the interaction like this.
Component: hey, the user typed its username and password. Check if it's a valid user.
Facade: Sure, I'll check and let you know.
Facade: It is a valid user. You can let him in.
Component: Ok, I'll tell him.

That's it. The component reacted to a user's action and asked the facade to verify the information. It got the response and delivered it to the user.
That way, you are separating responsibilities. Component with user interactions and facade with business logic.
CAUTION
Just be careful not to create a single facade to handle everything, ok? Otherwise, you will end up with a monster that is impossible to manage.
For me, it doesn't really matter how you choose to divide the facades.
For example, you can separate by domain (products, sales, login, etc), or by component, having one smaller facade for each component, or any other way you can think of. What matters is that it makes sense and you keep to it through the whole project.
It's pretty bad when you find that something works in one way in one part of the project and in a different way in another part.
That's the idea of this approach. To separate responsibilities. Component with user interactions and facade with business logic.

Remember this and try it on your next project.