Angular Style Encapsulation: You're Doing It Wrong
Tags: angular, css, refactorit, productivity
Published: 2019-09-14 08:31:54

Style encapsulation is a neat idea... I mean, we're banishing all those crazy collisions in the shared global, just putting your styles where you actually need them, right?

😂

The fact is, on any enterprise scale project you're likely to end up with a hodgepodge approach, with some stuff in the shared global, some in the component and some passed through into class bindings, or even in exceptional cases as dynamically generated and injected custom s/css objects. That's not *necessarily* bad, but in practice it often is.

![Look, this fancy new tool! Let's use it at random with no forethough, tackling each problem as if it exists in isolation! What could go wrong?](https://thepracticaldev.s3.amazonaws.com/i/c4q6elw3n7ef3hgiaf8e.jpg)

The issue for those who see encapsulation as a magic bullet that's going to fix all your styling woes by forcing things into the correct place is that it absolutely won't do that. If you're lazy and don't think through your strategy at a big picture level it can and will bite you in the ass. Repeatedly. And you won't enjoy the process. You have to be strict, you have to be rigorous and you have to expect that switching encapsulation on will, far from reducing your cognative overhead, actually likely increase it. This is because you can't just place your styles in the component that needs them in every scenario. There are many, many different situations, each of which require a different approach.

![Developer you think you are, hhhmmmm?](https://thepracticaldev.s3.amazonaws.com/i/z61jpym3dt6nzqihxdh3.jpg)

Firstly, and this should I hope be obvious to everyone: if a styling is genuinely applied over the whole app, and particularly if you expect to change it globally, it belongs somewhere shared. Now, you *can* use shared global css/scss files for this. You can also create a shared component that contains the styles within in. In many ways the latter is preferable, since you get all those lovely reuse benefits, but something to consider when doing it is this: every time you want to customise your component on a per page basis, you're going to have to mess about with input variables and bindings which, in a really large application, could be as much as 3 or 4 or even more layers deep. How much are you going to be customising, and by doing things this way, how much hassle are you going to create for yourself vs the old-school approach of s/css shared over some or part of an application? This is something specific to your application and you should know as a professional developer what the best way is in each scenario. You *have* to go through that mental process if you want your application to scale correctly.

Secondly, you might think that the little component you're making is just for the page you're on, but is it really? If you want to use those styles elsewhere, they're now stuck in a box. Did you really want to do that? Maybe you did. If you're certain then encapsulating them to a single, per page component was the right call. Again, though, you need to understand the complete design, not just the little patch you're working on.

Thirdly, and probably most importantly, there are no absolute rules you can follow for using styling encapsulation but you absolutely *cannot* do things at random and hope for the best. What you'll end up with won't just be a spaghetti mess, it'll be a system that actively forces you to create a spaghetti mess that gets worse and worse each time.

![Bending your mind around other people's encapulation choices is a bit like understanding The Matrix.](https://thepracticaldev.s3.amazonaws.com/i/5jkkflwi2zmdu2g2nbpj.jpg)

Don't do that.

If there's one thing you take home from this article it's that every time you make a call about where to place a style, you should consider from every angle available what that will mean.