Keep logic away from templates about angular-training-examples HOT 5 CLOSED

That is better but I think I wouldn't talk about the special <template> tag just yet to not confuse people.

@Component({
  selector: 'app-root',
  template: `
    <button (click)="toggleShow()">{{ show? 'hide': 'show' }}</button>
    <span *ngIf="show">{{ someString }}</span>`,
})
export class AppComponent {
  show = true;
  someString = 'What if you could conditionally show components?';
  toggleShow() {
    this.show = !this.show;
  };
}

from angular-training-examples.

• Template tags should definitely come later.
• The logic was in the *ngIf to illustrate the flexibility of the templating system. Although that is technically bad practice so let's go with the boolean solution.

from angular-training-examples.

It seems like it obscures the meaning and introduces more code. I understand the desire to separate concerns, but I don't think it helps in this case. There are cases where the logic is more than a simple expression; I would support using a method in those cases.

In addition, you then need to think of a method name for isVisible, introducing more work and giving people the opportunity to accidentally mislead the next person who comes along by naming it incorrectly.

I am, however, resistant to putting mutating logic in the template. For example: I wouldn't toggle the show state in the (click) expression.

from angular-training-examples.

The example is a bit contrived, though. I would instead do something like:

@Component({
  selector: 'app-root',
  template: `<button (click)="toggleShow()">{{ show? 'hide': 'show' }}</button>
    <template [ngIf]="show">{{ someString }}</template>`,
})
export class AppComponent {
  show = true;
  someString = 'What if you could conditionally show components?';
  toggleShow() {
    this.show = !this.show;
  };
}

from angular-training-examples.

You would definitely have a better idea of that. :- )

from angular-training-examples.