Comparing the Three Angular View Encapsulation Methods

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.

Barcelona - Photo by Erwan Hesry on Unsplash

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.

Implementation

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:

ViewEncapsulation.Emulated (default)

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.

ViewEncapsulation.None

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.

ViewEncapsulation.ShadowDom

As the name suggests, this uses the browser's native implementation of ShadowDOM to encapsulate the styles of the application.

And the Winner is…

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 and remember to share your findings in the comments section below!

Javier Artero

Javier Artero

Javier es un diseñador web experimentado que ha pasado años enseñando las maravillas del desarrollo frontend y el diseño. Sus principales aficiones son añadir animaciones CSS en todas partes y jugar a Overwatch.

comments powered by Disqus

Estás a un paso de conocer a tu mejor socio.

Hablemos