Ist es besser zu definieren, Staat im Konstruktor oder über die Eigenschaft Initialisierungen?

Laut diese babel-Dokumentation für den richtigen Weg, um ES6+ mit Reagieren ist zum ersten Komponenten wie diese:

class Video extends React.Component {
  static defaultProps = {
    autoPlay: false,
    maxLoops: 10,
  }
  static propTypes = {
    autoPlay: React.PropTypes.bool.isRequired,
    maxLoops: React.PropTypes.number.isRequired,
    posterFrameSrc: React.PropTypes.string.isRequired,
    videoSrc: React.PropTypes.string.isRequired,
  }
  state = {
    loopsRemaining: this.props.maxLoops,
  }
}

Aber einige offizielle Beispiele, wie Dan Abramov eigenen Reagieren DnD Modul verwendet ES6+ aber immer noch definiert Staat innerhalb des Konstruktors:

constructor(props) {
    super(props);
    this.moveCard = this.moveCard.bind(this);
    this.state = {
       //state stuff
    }
}

Nun Dan Abramov, wird ein wesentlicher Beitrag zu Reagieren, weiß wahrscheinlich, dass er definieren kann, Stand außerhalb des Konstruktors, aber immer noch entscheidet sich, es zu tun, innerhalb des Konstruktors.

So, ich Frage mich nur, welcher Weg ist besser und warum?

  • Es gibt keine schlechte oder gute, sind Sie gleichwertig, das ist eine Frage der Präferenz
  • Eigenschaften der Klasse sind ein Vorschlag. Sie sind nicht Teil des ES7. Bitte Lesen Sie die tag-Beschreibung mindestens: ecmascript-7.
InformationsquelleAutor abustamam | 2016-06-13
  1. 68

    Ich glaube, es ist eine Frage der persönlichen Vorliebe. Die transpiled Ausgabe ist die gleiche in Bezug auf die Semantik.

    • Wenn die Klasse extends React.Component Sie nicht transpile, um die gleiche Sache
    • Ja, fair genug, aber die Semantik der this.state ändert sich nicht.
    InformationsquelleAutor ctrlplusb
  2. 7

    Sind Sie gleichwertig, weil Feld " Klasse Vorschlag ist syntaktischer Zucker für Konstruktor-Körper-code.

    In Fall gibt es keine Notwendigkeit für explizite Konstruktor (anlegen von temporären lokalen Variablen, etc), constructor verzichtet werden kann, zugunsten der Klasse Felder.

    Das problem mit expliziten Konstruktor ist, dass super Argumente (props) werden Häufig weggelassen, die durch Fehler, kann dies zu Problemen führen:

    constructor() {
    super();
    this.state = { foo: this.props.foo } //this.props is undefined
}

    Expliziten Konstruktor kann vorteilhaft für die Lesbarkeit. Methoden sind konventionelle unten constructor auch Pfeil-Eigenschaften. Dies wird nicht so funktionieren wie Sie sollen, da Klassen-Feldern zugeordnet sind, in der Reihenfolge, wie Sie aufgeführt wurden:

    state = { foo: { method: this.someMethod } } //this.someMethod is undefined

someMethod = () => ...;

    In diesem Fall explizite Konstruktor können, führt zu besser lesbarem code:

    constructor(props) {
    super(props);

    //<-- this is the place where this.someMethod is really assigned

    this.state = { foo: { method: this.someMethod } }
}

someMethod = () => ...;
    InformationsquelleAutor Estus Flask
  3. 1

    Dan s code hat tatsächlich einen subtilen Fehler, die ist, warum ich empfehle, mit den Initialisierungen, Wann immer möglich. Reagieren Komponente Konstruktoren nimmt zwei Argumente - Requisiten und Rahmen. Er ist nicht der übergabe an den Eltern-Konstruktor und es könnte leicht übersehen werden, durch einige andere Entwickler, die es benötigt.

    Manchmal haben Sie keine Wahl, wie bei der Initialisierung hängt der Konstruktor Argumente, so denken Sie daran, zu geben all die Argumente der Eltern.

    Nach dem Versuch ein paar Sachen, die aussieht wie Reagieren nicht die Frage, die ich dachte. Sie weitergeben können, was Sie wollen, um die parent-Konstruktor, und es wird in Ordnung sein. E. g.:

    class MyComponent extends React.Component {
  constructor(props) {
    super({})
  }

  render() {
    //this.props will still be set correctly here
  }
}

    Ich noch empfehlen, mit den Initialisierungen als nicht zum Aufruf des übergeordneten Konstruktors ist eine Sache weniger zu denken.

    • Ich hatte keine Ahnung, dass Reagieren Konstruktoren nahm zwei Argumente. Was ist der Kontext?
    • Es ist ein Weg, um die übertragung von Daten von Komponenten, die tiefer in der Hierarchie, ohne Requisiten auf alle Vermittler. Ich habe versucht, ein paar tests und sieht wie Reagieren nicht die Frage, die ich erwähnt. Punkt ist immer noch gültig, obwohl.
    • "Sie können gehen, was Sie wollen, um die parent-Konstruktor und es wird gut werden" - NÖ. facebook.github.io/reagieren/docs/reagieren-Komponente.html#Konstruktor und auch : facebook.github.io/react/docs/state-and-lifecycle.html
    • Dokumentation nicht immer einer Meinung mit der Realität. Nicht sagen, dass die Menschen ignorieren sollten die docs, nur darauf hin, dass Reagieren, verhält sich anders als in der Wirklichkeit. github.com/facebook/react/blob/...
    InformationsquelleAutor Gunchars
Schreibe einen Kommentar