This content originally appeared on Bits and Pieces - Medium and was authored by Kamil Konopka
Is It Still a Performance Perspective or Just Good Practice?
The Containers vs Component approach is a well-known pattern already existing within the Front-end world for a while. Most of you already use it widely and embrace its potential.
But have you ever wondered why containers vs components pattern is important to properly use it especially in Angular?
Before we answer that question, let us dive a little bit deeper into the actual use case.
Probably, you’ve already got a chance to experience *ngFor structural directive on wrapping HTML tag which contains an enormous number of HTML children with:
- method calls assigned to property binding
- method calls assigned to *ngIf structural directive
- multiple conditions spreading across multiple lines of code within *ngIf directive
- method calls within string interpolation (side note: in many cases, it can be solved by introducing pipe, but this is also a different story)
It’s the simplest example of a situation when the containers vs components technique make absolute sense or even becomes essential. This particular use case might be a good indication to start thinking, that there is certainly something not right in the code.
What is worth mentioning, just to avoid confusion:
In Angular, there’s no special treatment/entity for a container. It’s just yet another Angular component.
So, you can think of this technique, as your own initiative and you are responsible to manage it on your own.
In general, the container (so-called smart component) should handle:
- business logic/operations on data (CRUD operations)
- getting the initial set of data
- pass data to dumb/presentational component
On another hand component (so-called dumb/presentational component) should:
- display the data / present the content visually
- emit any change request (should not perform any data manipulation on its own — parent component is the only owner of the data)
- trigger change detection mechanism, only when it is necessary (when data managed by the container/parent has been changed) — true reactivity
Having said this (understanding the difference), we’re able to focus on the benefits of implementing this technique:
💡 Breaking down logic into smart containers and presentational components is a good architectural pattern, but if you’re using them often it might be time to start maintaining a library of reusable components that can be shared across differrent projects and teams with Bit.
Learn more here:
- mixing both smart and dumb components in one is not really following SOLID principles — containers vs components brings you one step closer
- it’s easier to write unit tests for both entities separately
- you can truly leverage the ChangeDetectionStrategy.OnPush with your presentational component, so only when either inputs provide data changes or events are being emitted, your component is going to be re-rendered. (you have to ensure data immutability in order to enable the mechanism to work as expected). Sounds super performant right?
- your component classes will be significantly smaller — another benefit from maintenance and clean code perspective
- you can easily adopt different presentational components to display the same set of data in a different manner (just imagine what you should do, to achieve it with mixed components)
- no need to assign method calls to property binding (which triggers change detection like ngDoCheck lifecycle hook, as Angular is not able to determine what will be the outcome of the method without retrieving its result), you are perfectly capable to handle these calculations within ngOnChanges lifecycle hook, or if you’re using Angular 16, you can take advantage of the signals and its computation.
In case of ngOnChanges lifecycle hook I’m usually being questioned by other developers, why to use it when there’s a setter available as well?
Well, setter is running out of Angular zone, what is more, if more inputs are involved in calculations there, the results might not be consistent. ngOnChanges guarantees consistency! And you’ll always get most recent inputs values in your calculation.
Does it still sound like performance optimization or is it yet another good practice, that you should take into consideration while delivering your solution in the first place?
Build Angular Apps with reusable components, just like Lego
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- Introducing Angular Component Development Environment
- 10 Useful Angular Features You’ve Probably Never Used
- Top 8 Tools for Angular Development in 2023
- Getting Started with a New Angular Project in 2023
- How We Build Micro Frontends
- How to Share Angular Components Between Projects and Apps
- How we Build a Component Design System
- Creating a Developer Website with Bit components
Containers vs Components in Angular was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Kamil Konopka
Kamil Konopka | Sciencx (2023-05-15T11:46:38+00:00) Containers vs Components in Angular. Retrieved from https://www.scien.cx/2023/05/15/containers-vs-components-in-angular/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.