React v16.3.0: Neue Lebenszyklen und Kontext-API

Vor ein paar Tagen haben wir einen Artikel über bevorstehende Änderungen an unserem traditionellen Lebenszyklusansatz geschrieben, einschließlich einer schrittweisen Migrationsstrategie. In React 16.3.0 haben wir einige neue Lebenszyklusmethoden hinzugefügt, um die Migration zu unterstützen. Wir haben außerdem neue APIs für lang laufende Anforderungsfunktionen eingeführt: eine offizielle Kontext-API, eine Ref-Weiterleitungs-API und eine semantischere Ref-API.

Bitte lesen Sie weiter, um mehr über diese Veröffentlichung zu erfahren.

Offiziell zertifizierte Context-API

Seit vielen Jahren stellt React eine experimentelle API für Context bereit. Obwohl es sich um ein leistungsstarkes Tool handelt, wird seine Verwendung aufgrund der mit der API verbundenen Probleme verpönt. Daher beabsichtigen wir, diese experimentelle API durch eine bessere API zu ersetzen.

React 16.3 führt eine neue Kontext-API ein, die effizienter ist und statische Typprüfung und umfassende Aktualisierungen unterstützt.

Hinweis
Die alte ContextAPI bleibt in React 16.x weiterhin erhalten, sodass Sie Zeit für die Migration haben.

Hier ist ein Beispiel für das Einfügen eines „Themas“ mithilfe der neuen Kontext-API:

## by 司徒正美
const ThemeContext = React.createContext('light');

class ThemeProvider extends React.Component {
  state = {theme: 'light'};

  render() {
    return (
      <ThemeContext.Provider value={this.state.theme}>
        {this.props.children}
      </ThemeContext.Provider>
    );
  }
}

class ThemedButton extends React.Component {
  render() {
    return (
      <ThemeContext.Consumer>
        {theme => <Button theme={theme} />}
      </ThemeContext.Consumer>
    );
  }
}

createRef API

Zuvor bot React zwei Möglichkeiten zum Verwalten von Referenzen Methoden: String-Ref-API und Callback-Ref-API. Obwohl die String-Ref-API bequemer ist, weist sie mehrere Nachteile auf. Daher empfehlen wir offiziell die Verwendung von Callback-Ref.

React 16.3 bietet eine neue Lösung für die Verwaltung von Refs, die Komfort für String-Refs ohne Nachteile bietet:

## by 司徒正美

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

    this.inputRef = React.createRef();
  }

  render() {
    return <input type="text" ref={this.inputRef} />;
  }

  componentDidMount() {
    this.inputRef.current.focus();
  }
}

Hinweis

Zusätzlich zum Neuen Mit der createRef-API werden Callback-Referenzen weiterhin unterstützt.

Sie müssen Callback-Referenzen in der Komponente nicht ersetzen. Sie sind etwas flexibler und werden daher weiterhin eine erweiterte Funktion sein.

forwardRef API

Komponenten höherer Ordnung (oder HOCs) sind eine gängige Methode zur Wiederverwendung von Code zwischen Komponenten. Basierend auf dem obigen Beispiel für den Themenkontext können wir ein temporäres Objekt erstellen, in das das aktuelle „Thema“ als Eigenschaft eingefügt wird:

## by 司徒正美

function withTheme(Component) {
  return function ThemedComponent(props) {
    return (
      <ThemeContext.Consumer>
        {theme => <Component {...props} theme={theme} />}
      </ThemeContext.Consumer>
    );
  };
}

Wir können die oben beschriebene spezielle Methode verwenden, um die Komponente mit dem Themenkontext zu verbinden. und Es ist nicht notwendig, den Themenkontext direkt zu verwenden. Zum Beispiel:

## by 司徒正美

class FancyButton extends React.Component {
  buttonRef = React.createRef();

  focus() {
    this.buttonRef.current.focus();
  }

  render() {
    const {label, theme, ...rest} = this.props;
    return (
      <button
        {...rest}
        className={`${theme}-button`}
        ref={this.buttonRef}>

        {label}
      </button>
    );
  }
}

const FancyThemedButton = withTheme(FancyButton);

// We can render FancyThemedButton as if it were a FancyButton
// It will automatically receive the current "theme",
// And the HOC will pass through our other props.
<FancyThemedButton
  label="Click me!"
  onClick={handleClick}
/>;

HOCs übergeben normalerweise Requisiten an die Komponente, die sie umschließen. Leider sind die Schiedsrichter nicht vorgedrungen. Das bedeutet, dass wir, wenn wir einen FancyThemedButton verwenden, den Verweis nicht zum FancyButton hinzufügen und daher focus() nicht aufrufen können.

Die neue Proxy-API löst dieses Problem, indem sie eine Möglichkeit bietet, einen Verweis abzufangen und als normale Requisite weiterzuleiten:

## by 司徒正美

function withTheme(Component) {
  // Note the second param "ref" provided by React.forwardRef.
  // We can attach this to Component directly.
  function ThemedComponent(props, ref) {
    return (
      <ThemeContext.Consumer>
        {theme => (
          <Component {...props} ref={ref} theme={theme} />
        )}
      </ThemeContext.Consumer>
    );
  }

  // These next lines are not necessary,
  // But they do give the component a better display name in DevTools,
  // e.g. "ForwardRef(withTheme(MyComponent))"
  const name = Component.displayName || Component.name;
  ThemedComponent.displayName = `withTheme(${name})`;

  // Tell React to pass the "ref" to ThemedComponent.
  return React.forwardRef(ThemedComponent);
}

const fancyButtonRef = React.createRef();

// fancyButtonRef will now point to FancyButton
<FancyThemedButton
  label="Click me!"
  onClick={handleClick}
  ref={fancyButtonRef}
/>;

Komponentenlebenszyklus-Hook ändert sich

React-Klasse Die Komponenten-API gibt es schon seit Jahren mit kaum Änderungen. Da wir jedoch Unterstützung für erweiterte Funktionen wie Fehlergrenzen und den kommenden asynchronen Rendering-Modus hinzufügen, erweitern wir dieses Modell auf eine Weise, die ursprünglich nicht beabsichtigt war.

Zum Beispiel ist es in der aktuellen API sehr einfach, das anfängliche Rendern auf ungewöhnliche Weise zu verhindern. Dies liegt zum Teil daran, dass es so viele Hooks gibt, um diese Aufgabe zu erfüllen, und es nicht klar ist, welcher der beste ist. Wir haben festgestellt, dass das Interrupt-Verhalten der Fehlerbehandlung oft nicht berücksichtigt wird und zu Speicherlecks führen kann (dies wird auch den kommenden asynchronen Rendering-Modus betreffen). Die aktuelle Klassenkomponenten-API erschwert auch andere Aufgaben, beispielsweise die Arbeit unseres Code-Optimierers (Prepack).

componentWillMount, componentWillReceiveProps, componentWillUpdateDiese Hooks können leicht Probleme verursachen und den Lebenszyklus von React ernsthaft stören. Aus diesen Gründen lehnen wir diese Methoden zugunsten besserer Alternativen ab.

Wir sind uns bewusst, dass sich diese Änderung auf viele bestehende Komponenten auswirken wird. Daher wird der Migrationspfad so reibungslos wie möglich verlaufen und Migrationsoptionen bereitgestellt. (Bei Facebook haben wir über 50.000 React-Komponenten. Wir setzen auch auf einen progressiven Release-Zyklus!

HINWEIS

Veraltungswarnungen werden in zukünftigen Versionen von React16 aktiviert und bleiben bis dahin erhalten 17 wird veröffentlicht.

Auch in React17 können sie weiterhin verwendet werden, ihnen wird jedoch „UNSAFE_“ vorangestellt, um darauf hinzuweisen, dass sie möglicherweise Probleme verursachen vorhandener Code

Zusätzlich zur Ablehnung unsicherer Lebenszyklus-Hooks haben wir auch einige neue Lebenszyklus-Hooks hinzugefügt:

getDerivedStateFromProps für ComponentWillReceiveProps . Wird zum sicheren Lesen von Eigenschaften aus dem DOM vor dem Aktualisieren verwendet. Die Komponente

ist speziell dafür konzipiert, potenzielle Probleme aufzudecken. getSnapshotBeforeUpdate kann keine zusätzlichen Prüfungen aktivieren und Warnungen für die untergeordneten Komponenten.

In Version 16.3 hilft StrictMode:

1. Komponenten mit unsicheren Lebenszyklus-Hooks zu identifizieren.

2. Warnung zur Verwendung der Legacy-String-Ref-API.

3. Unerwartete Nebenwirkungen erkennen

Das obige ist der detaillierte Inhalt vonReact v16.3.0: Neue Lebenszyklen und Kontext-API. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!