We have most of the component-specific styling in the components themselves (so scoped to the component). We do have some global styles, for instance, a bunch of variables and mixins (colors, interaction patterns) and things like typography and grids. When I joined the team they were using BEM as a solution, but in my opinion, it's useless once you have component-scoped CSS (it just adds a lot of fluff). For global styles, I can see the use case.
I'm reasonably happy with the current approach, but we do run into issues where we need to override styles with ng-deep too often. How do you deal with that, besides making the components so strict that they will always be implemented exactly the same?
::ng-deep is banned for us due to it being depricated, and support for it being planned to be dropped across browsers, though honestly I don't see how Google will justify the amount of breakage taking away this widely used tool will cause.
One solution that I touched on in the article is to construct a stylings object in the controller of the parent, then pass this through via an input binding and an ngStyle binding. Some people may dislike this approach due to it breaking separation of concerns, but it has often been the only option left short of, as you say, making everything look the same, which is some people's chosen option but not mine.
You are right about the global style and BEM being pretty useless with encapsulation to some degree, but what if you want to style an element contained within an element where those exist in different areas of the shadow DOM (nested components) which do not and are not supposed to have knowledge of each other?
Thanks for your reply! Yeah, I can see the use case of style objects. I think in React this pattern is more widely used than in Angular for some reason.
You're last point, you're talking about giving a nested component different styling based on the context they're used in? We'd be using ng-deep from the parent component in most cases, but we're starting to explore global styling for that kind of use case more and more. It's just a shame to lose the encapsulation, but in a way BEM will prevent most accidental overwrites. My gripe was more with using BEM within components that don't have children and have encapsulated styles.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We have most of the component-specific styling in the components themselves (so scoped to the component). We do have some global styles, for instance, a bunch of variables and mixins (colors, interaction patterns) and things like typography and grids. When I joined the team they were using BEM as a solution, but in my opinion, it's useless once you have component-scoped CSS (it just adds a lot of fluff). For global styles, I can see the use case.
I'm reasonably happy with the current approach, but we do run into issues where we need to override styles with ng-deep too often. How do you deal with that, besides making the components so strict that they will always be implemented exactly the same?
::ng-deep is banned for us due to it being depricated, and support for it being planned to be dropped across browsers, though honestly I don't see how Google will justify the amount of breakage taking away this widely used tool will cause.
One solution that I touched on in the article is to construct a stylings object in the controller of the parent, then pass this through via an input binding and an ngStyle binding. Some people may dislike this approach due to it breaking separation of concerns, but it has often been the only option left short of, as you say, making everything look the same, which is some people's chosen option but not mine.
You are right about the global style and BEM being pretty useless with encapsulation to some degree, but what if you want to style an element contained within an element where those exist in different areas of the shadow DOM (nested components) which do not and are not supposed to have knowledge of each other?
Thanks for your reply! Yeah, I can see the use case of style objects. I think in React this pattern is more widely used than in Angular for some reason.
You're last point, you're talking about giving a nested component different styling based on the context they're used in? We'd be using ng-deep from the parent component in most cases, but we're starting to explore global styling for that kind of use case more and more. It's just a shame to lose the encapsulation, but in a way BEM will prevent most accidental overwrites. My gripe was more with using BEM within components that don't have children and have encapsulated styles.