6

Imagine this:

export class MyComponent {

  namespace: string;

  constructor(private globals: Globals) {
    this.namespace = globals.namespace;
  } 
}

And then the template like this:

<div class="{{namespace}}-wrapper">
  <h1 class="{{namespace}}-title"></h1>
  <h2 class="{{namespace}}-subtitle"></h2>
</div>

This gives you complete control over your styling as no 3rd party styles (or very very few since not many will have the same namespace and suffixes) can interfere with your own styles, but what about performance? Let's say I have 20 bindings like this on average per template, does that affect performance in a way that should make you consider not using this approach?

Technically it shouldn't affect performance since it's only a one time binding, but maybe the load time increases by doing this? I haven't found any solid way of testing this so I can't know for certain.

I know about view encapsulation but I want to have an approach that enables me to turn that off and still be sure that nothing will break.

Is there a better way to achieve this perhaps or is this a perfectly good approach?

Chrillewoodz
  • 27,055
  • 21
  • 92
  • 175

1 Answers1

3

There is no one-time binding in Angular2. Every time change detection runs, properties used in such bindings are checked for changes.

Angular2 change detection is quite efficient and can be further optimized by using ChangeDetectionStrategy.OnPush.

If you have about 20 bindings per template this can become quite a big total number for the whole application and I'd expect this to harm performance.

I don't see a reason why this could harm load time.

Günter Zöchbauer
  • 623,577
  • 216
  • 2,003
  • 1,567
  • So what would you suggest that I do? – Chrillewoodz Oct 19 '16 at 10:36
  • Use default view encapsulation. I don't understand what's the problem with it. You can also use other selectors so that you for example only have a single class binding on every component, not on every element in its template. – Günter Zöchbauer Oct 19 '16 at 10:41
  • Ok, I guess another solution is to just write it out manually.. and if it needs to change to a ctrl + shift + f search and replace, although it's not a great solution it could suffice. – Chrillewoodz Oct 19 '16 at 10:51
  • That sounds horrible. I don't get yet what's the actual problem you're trying to solve. Why do you think there could be conflicts? – Günter Zöchbauer Oct 19 '16 at 10:53
  • Because I've experienced a number of times that my own classes conflicts with Bootstrap for example, so a `modal` class in bootstrap would conflict with my own `modal` class. So by adding a project prefix that problem would be solved. Like I said, I know about view encapsulation but at this stage we don't know if it's gonna be turned on or not. So I want to have an approach that allows it to be turned off with zero risks of conflicts with 3rd party libraries. I know it might sound like a weird scenario but that's what I'm stuck with unfortunately. – Chrillewoodz Oct 19 '16 at 10:59
  • Then just don't use `modal`. What's the problem of using `crwdz-modal` instead? I think this would make it quite unlikey to conflict. – Günter Zöchbauer Oct 19 '16 at 11:00
  • Well that's kinda my point, `crwdz` would still be a prefix that you would want to have on everything. Instead of having to come up with alternative names for things, like `modal-popup` etc. I seek simplicity but it looks like there isn't a decent way of achieving it the way I would have hoped for. – Chrillewoodz Oct 19 '16 at 11:05
  • If you include some more details for the `ChangeDetectionStrategy.onPush` and how to use it I can give you the bounty reward. – Chrillewoodz Oct 19 '16 at 11:06
  • With `ChangeDetection.onPush` change detection on a component is only run when an binding to one of its inputs has changed, when an event happens inside the component and there was a binding for that event or when an observable that is subscribed to using `| async`. If none of these occurs and you don't invoke change detection implicitely then change detection omits your component and all it's children. This reduces dramatically how much work change detection has to do. Because with your use case there is usually no change, the change detection itself is all the work that has to be done – Günter Zöchbauer Oct 19 '16 at 11:13
  • ... and OnPush makes this cheap. But you might have to take care yourself about some changes. – Günter Zöchbauer Oct 19 '16 at 11:14