Website-Suche

typescript - „privat“ und „öffentlich“ in Angular-Komponente

Wenn ich private nicht vor foo, loadBar und text hinzufüge, glaube ich, dass sie standardmäßig public sind.

export class RandomComponent {
  @Input() foo: string;
  @Output() loadBar = new EventEmitter();
  text: string;
}

Gibt es einen Anwendungsfall, bei dem sie im Component public sind?

Aus Kapselungs-/Sicherheitsgründen, sollte ich immer private für alle wie unten hinzufügen?

export class RandomComponent {
  @Input() private foo: string;
  @Output() private loadBar = new EventEmitter();
  private text: string;
}

Antwort #1

Es gibt viel zu dieser Frage zu sagen, dies sind die ersten Gedanken, die mir in den Sinn kamen:

Zuallererst sollten Sie im Hinterkopf behalten, dass private nur eine zur Kompilierzeit wirksame Konstruktion ist - es kann zur Laufzeit nicht durchgesetzt werden (siehe hier und hier für relevante Diskussionen): Bitte verwerfen Sie jegliche Vorstellungen, dass private in irgendeiner Weise für Sicherheitszwecke nützlich sein könnte. Darum geht es schlichtweg nicht.

Es geht um Kapselung, und wenn Sie ein Feld oder eine Methode in Ihrer Komponente haben, die Sie darin kapseln möchten, wodurch klar wird, dass sie von sonstwo nicht zugegriffen werden sollte, dann sollten Sie sie auf jeden Fall private machen: Dafür ist private da: Es signalisiert Ihre Absicht, dass das, worauf Sie es angewendet haben, von außerhalb der Klasse nicht berührt werden sollte.

Dasselbe gilt für public: Auch dies ist nur eine Konstruktion zur Compile-Zeit, daher hat die Tatsache, dass Klassenmitglieder standardmäßig public sind, obwohl sie zutrifft, zur Laufzeit exakt keine Bedeutung. Wenn Sie jedoch ein Mitglied haben, das Sie ausdrücklich der Außenwelt als Teil der API Ihrer Klasse zugänglich machen möchten, sollten Sie es unbedingt public machen, um diese Absicht zu signalisieren: Dafür ist public da.

Dies gilt im Allgemeinen für Typescript. Speziell in Angular gibt es definitiv valide Anwendungsfälle dafür, öffentliche Mitglieder in Component-Klassen zu haben: Zum Beispiel, wenn man das Container/Component- (auch Smart/Dumb-) Muster implementiert, wobei „dumme“ Kinder „smarte“ Eltern über Constructor Injection einfügen, ist es äußerst wichtig, die eigenen Absichten darüber zu kommunizieren, welche Mitglieder des Elternteils von den Kindern berührt werden dürfen und welche nicht: Andernfalls sollte man nicht überrascht sein, wenn man diese dummen Kinder dabei erwischt, wie sie im Spirituosenschrank ihrer Eltern rummachen.

Also, meine Antwort auf deine Frage:

Soll ich immer privat für alle von ihnen wie unten hinzufügen?

ist ein nachdrückliches Nein. Du solltest nicht immer private hinzufügen, weil du damit den Zweck des Schlüsselworts untergräbst, da es keine Absicht mehr signalisiert, wenn du es überall einfügst: Du könntest es genauso gut gar nicht verwenden.

Antwort #2

@drewmoore gibt eine gute Antwort, dass privat/öffentlich im Wesentlichen auf die Absicht hinausläuft. Es gibt jedoch noch einige weitere Dinge, die beim Verwenden injizierter privater Werte zu berücksichtigen sind:

  • Sowohl TypeScript (noUnusedLocals) als auch TSLint (no-unused-variable) melden Fehler, wenn Sie @Import() private foo oder constructor(private foo) {} verwenden und foo nur in Ihrer Vorlage verwenden.
  • AOT wird nicht funktionieren:

Wenn wir TypeScript als Ausgabe des AoT-Kompilierungsprozesses ausgeben möchten, müssen wir sicherstellen, dass wir in den Templates unserer Komponenten nur auf öffentliche Felder zugreifen.

  • Es wird als Anti-Pattern betrachtet

Verwandte Artikel