Comparing the three Angular view encapsulation methods
Diario del capitán, fecha estelar d343.y38/AB
Diario del capitán, fecha estelar d343.y38/AB
Since we started the company, we have been using Angular for most of our frontend development projects.
In this blog post, I'm going to share how we encapsulate the views in Angular, by doing a comparison of the three view encapsulation methods available right now.
I have been working on the frontend part of the projects at MarsBased for over four years now. Even though we've incorporated React and even done some projects using Vue.js lately, we've been using Angular since the company was born in 2014. We used it in our first big project, the Barcelona Startup Map and then in ongoing projects such as Zapptales.
Throughout the years, we have seen dozens of configurations and setups for both small and big clients, and especially in critical projects, the encapsulation of the views can make or break a project in Angular.
Angular allows a very thought-through organisation of components, where we can separate in each component the TypeScript, the SCSS and the HTML code.
How? When we declare a component in Angular, we can say how we want the styles to act using the ViewEncapsulation configurations. In code, this translates into:
@Component({
selector: 'my-app',
template: '<h1>Hello World!</h1>',
encapsulation: ViewEncapsulation.ShadowDom
})
class MyApp {
}
For further details, we suggest reading the Angular documentation, but we're describing and comparing the three methods here:
This configuration emulates Native scoping of styles by adding an attribute containing surrogate id to the Host Element and pre-processing the style rules provided via styles or styleUrls, and adding the new Host Element attribute to all selectors.
This is, by the way, the default option.
This solution, a priori, seems very good but as you develop further, it becomes more and more complex over time mainly due to child components not being able to inherit the styles of the parent.
When a given component is loaded in the <head>, all its styles are loaded with it and applied to the <style> tags.
However, this can also generate confusion and bugs. As we are most of the time building single page application (SPAs), the users barely ever reload the pages - they only browse through the app - and therefore the styles are never reloaded, thus carrying excessive styles in sections where they shouldn't be.
As the name suggests, this uses the browser's native implementation of ShadowDOM to encapsulate the styles of the application.
Each project requires a different setup, as there is no one-size-fits-all.
For most of the new projects we are working on, we are using ViewEncapsulation.None directly in the main page component and we will use more specific selectors through the main components.
If need be, we can also break away from the Angular paradigm, and create styles limited to certain pages in specific separate SCSS files, when we need to work on pages that look radically different than the rest of the application, or simply to avoid dragging along unnecessary styles and potential bugs.
Hope you found this useful!
One annoying thing about RxJS is its memory leaks because of Observables and Subscriptions. Here's what we do to deal with them.
Leer el artículo
How to change the detection strategy in Angular to improve performance and to adapt it to your project requirements.
Leer el artículo
We share useful Angular resources, questions, experiences, tools, guides and tutorials to keep this curated Angular reference post up-to-date. Enjoy it!
Leer el artículo