Wie viel wissen Sie über React? Zusammenfassung der Dinge, die Sie bei React beachten sollten

In diesem Artikel geht es hauptsächlich um Dinge, die Sie über Reagieren wissen müssen, wie Containerkomponenten und Komponenteneigenschaften, SetState-Asynchronität usw. Schauen wir uns diesen Artikel gemeinsam an. Artikelleiste

Containerkomponente und Präsentationskomponente

Beim Schreiben von Komponenten mit React müssen wir die Komponenten bewusst integrieren. Die Aufteilung in Containerkomponenten und Präsentationskomponenten hilft uns, klarer zu sein darüber, wofür diese Komponente beim Schreiben von Komponenten verantwortlich sein sollte.

Die Containerkomponente ist für die Verarbeitung der Geschäftsprozesslogik verantwortlich, z. B. für das Senden von Netzwerkanforderungen, die Verarbeitung von Anforderungsdaten und die Weitergabe der verarbeiteten Daten an die Requisiten der Unterkomponenten zur Verwendung. Gleichzeitig stellt die Containerkomponente Methoden für Quelldaten bereit und übergibt sie in Form von Requisiten an Unterkomponenten. Wenn die Zustandsänderungen der Unterkomponente Änderungen in den Quelldaten verursachen, synchronisiert die Unterkomponente diese Änderungen Aufrufen der von der Containerkomponente bereitgestellten Methoden.

Präsentative Komponenten sind für das Erscheinungsbild der Komponente verantwortlich, d. h. für die Art und Weise, wie die Komponente gerendert wird, und weisen einen starken Zusammenhalt auf. Der Präsentationskomponente ist es egal, wie die beim Rendern verwendeten Komponenteneigenschaften (Requisiten) erhalten werden. Sie muss lediglich wissen, wie die Komponente mit diesen Requisiten gerendert werden soll. Wie die Eigenschaften abgerufen werden, liegt in der Verantwortung der Containerkomponente. Wenn Änderungen im Status einer Präsentationskomponente mit den Quelldaten synchronisiert werden müssen, muss eine Methode in der Containerkomponente aufgerufen werden. Diese Methode wird normalerweise über Props an die Präsentationskomponente übergeben.

Ein Todo-Projekt verfügt beispielsweise über eine Todo-Komponente und eine TodoList-Komponente. Die Todo-Komponente ist eine Containerkomponente, die für das Abrufen der To-Do-Liste vom Server verantwortlich ist. Es wird zur Anzeige an die TodoList übergeben. Nachdem Sie ein neues Aufgabenelement in der TodoList erstellt haben, müssen Sie die Methode zum Speichern des Aufgabenelements in der Todo-Komponente über die Requisiten der TodoList aufrufen, um das neue Aufgabenelement mit dem Server zu synchronisieren.

Containerkomponenten und Präsentationskomponenten können ineinander verschachtelt sein, und eine Containerkomponente kann auch Containerkomponenten und andere Anzeigekomponenten enthalten. Durch diese Art der Arbeitsteilung kann die Logik, die nicht direkt mit dem Rendern der Komponente zusammenhängt, zentralisiert und für die Containerkomponente verantwortlich gemacht werden, während sich die Präsentationskomponente nur auf die Rendering-Logik der Komponente konzentriert, wodurch die Wiederverwendung der Präsentationskomponente einfacher wird. Für sehr einfache Seiten reicht im Allgemeinen nur eine Containerkomponente aus. Für verantwortungsvolle Seiten sind jedoch mehrere Containerkomponenten erforderlich. Andernfalls ist die Komponente sehr komplex, wenn die gesamte Geschäftslogik verarbeitet wird , müssen die von dieser Komponente erhaltenen Quelldaten möglicherweise viele Schichten von Komponenten-Requisiten durchlaufen, bevor sie die endgültige Anzeigekomponente erreichen.

Props, State und gemeinsame Eigenschaften von Komponenten

Die Konzepte von Props und State sind sehr klar. Die gemeinsamen Eigenschaften einer Komponente beziehen sich auf die Eigenschaften, die direkt darunter angebracht sind die Komponente. Tatsächlich sind Props und State auch zwei gemeinsame Eigenschaften von Komponenten, da wir sie direkt über this.props und this.state abrufen können. In welchen Szenarien sollten also Props, State und andere gemeinsame Eigenschaften von Komponenten verwendet werden?

Props und State werden beide für das Rendern von Komponenten verwendet, das heißt, wie eine Komponente letztendlich aussehen wird, hängt von den Props und dem Status der Komponente ab. Änderungen an Requisiten und Status lösen die Rendermethode der Komponente aus . Aber es gibt Unterschiede zwischen den beiden. Bei Props handelt es sich um schreibgeschützte Daten, die von der übergeordneten Komponente übergeben werden, während State der von der Komponente selbst verwaltete und veränderbare Status ist. Der Status kann sich aufgrund von Änderungen in den Requisiten ändern. Wenn in der Komponente andere Eigenschaften benötigt werden und diese Eigenschaft nichts mit dem Rendern der Komponente zu tun hat (d. h. sie wird nicht in der Render-Methode verwendet), kann diese Eigenschaft direkt darunter aufgehängt werden, anstatt eine zu sein Zustand der Komponente.

Wenn beispielsweise in einer Komponente ein Timer benötigt wird und sich der Zustand der Komponente alle paar Sekunden ändert, können Sie eine this.timer-Eigenschaft definieren, um den Timer zu löschen, wenn die KomponenteWillUnmount erfolgt. (Wenn Sie mehr erfahren möchten, besuchen Sie die Spalte React Reference Manual der chinesischen PHP-Website, um mehr zu erfahren)

setState-Asynchronität

Die offizielle Website von React erwähnte, dass this.state und this.props Das Update kann asynchron sein und React kann aus Leistungsgründen mehrere setState-Aufrufe zu einem State-Update zusammenführen. Verlassen Sie sich also nicht auf die Werte von this.props und this.state, um den nächsten Status zu berechnen. Zitieren eines Codebeispiels von der offiziellen Website:

// Wrong
this.setState({
  counter: this.state.counter + this.props.increment,
});

Wenn Sie dies tun müssen, können Sie eine andere setState-Methode verwenden, die eine Funktion als Parameter verwendet. Der erste Parameter dieser Funktion ist der vorherige Status und der zweite Parameter ist der aktuelle Die neuesten empfangenen Requisiten. Wie unten gezeigt:

// Correctthis.setState(function(prevState, props) {
  return {
    counter: prevState.counter + props.increment
  };
});

在调用setState之后，也不能立即使用this.state获取最新状态，因为这时的state很可能还没有被更新，要想保证获取到的state是最新的state，可以在componentDidUpdate中获取this.state。也可以使用带用回调函数参数版本的setStatesetState(stateChange, [callback])，回调函数中的this.state会保证是最新的state。

componentWillReceiveProps

当组件的属性可能发生变化时，这个方法会被调用。这里说可能，是因为父组件render方法每次被调用时，子组件的这个方法都会被调用（子组件第一次初始化时除外），但并不一定每次子组件的属性都会发生变化。如果组件的State需要根据Props的变化而变化，那么这个方法就是最适合这个这个逻辑的地方。例如当Props变化时，组件的State需要重置，就可以在这个方法中调用this.setState()来重置状态。需要注意，在这个方法中调用this.setState()并不会重新触发componentWillReceiveProps的调用，也不会导致render方法被触发两次。一般情况下，接收到新Props会触发一次render，调用this.setState也会触发一次render，但在componentWillReceiveProps中调用this.setState，React会把原本需要的两次render，合并成一次。

shouldComponentUpdate

这个方法常作为优化React性能使用。当shouldComponentUpdate返回false时，组件本次的render方法不会被触发。可以通过在这个方法中比较前后两次state或者props，根据实际业务场景决定是否需要触发render方法。

React提供了一个React.PureComponent组件，这个组件重写了shouldComponentUpdate，会对前后两次的state和props进行浅比较，如何不一致，才会返回true，触发后续的render方法。这里的浅比较指，只会对state和props的第一级属性进行比较（使用!==），这满足一般的使用场景。如果你的组件继承了React.PureComponent，但在setState时，传入的state是直接修改的原有state对象，就会因为依然满足浅比较的条件，而不会重新触发render方法，导致最终DOM和state不一致。例如state={books: ['A','B']}，在setState时，使用this.setState({name: this.state.books.push('C')})直接修改books对象，这样虽然books内容发生了修改，但因为对象引用并没有变化，所以依然满足浅比较条件，不会触发render方法。

一般情况下，让shouldComponentUpdate返回默认的true是不会有太大问题的。虽然这样可能导致一些不必要的render方法被调用，但render方法直接操作的是虚拟DOM，只要虚拟DOM没有发生变化，并不会导致实体DOM的修改。而JS慢是慢在实体DOM的修改上。只要你的render方法不是很复杂，多调用几次render方法并不会带来多大的性能开销。

render

父组件每次render方法被调用，或者组件自己每次调用setState方法，都会触发组件的render方法（前提是shouldComponentUpdate使用默认行为，总是返回true）。那么组件每次render，是不是都会导致实体DOM的重新创建呢？答案是，不是！

React之所以比直接操作DOM的JS库快，原因是React在实体DOM之上，抽象出一层虚拟DOM，render方法执行后，得到的是虚拟DOM，React 会把组将当前的虚拟DOM结构和前一次的虚拟DOM结构做比较，只有存在差异性，React才会把差异的内容同步到实体DOM上。如果两次render后的虚拟DOM结构保持一致，并不会触发实体DOM的修改。

React速度快的原因，还有一个是它出色的Diff算法。标准的比较两棵树的Diff算法的时间复杂是 O(n3) 。而React基于非常符合实际场景的两个假设，就将Diff算法的时间复杂度降到了接近O(n)。这两个假设是：

1. 如果两个组件或元素类型不同，那么他们就是完全不同的树，不需要再比较他们的子节点。例如，59da28f5dfb08cc4320eedd48bbc94b6和c87d292abd3767e5a975339e763d52ff将产生是两个完全的树状结构；e388a4556c0f65e1904146cc1a846beechildren94b3e26ee717c64999d7867364b1b4a3和e388a4556c0f65e1904146cc1a846beechildren94b3e26ee717c64999d7867364b1b4a3也是两个完全不同的树。这种情况下，组件会被完全重建，旧的DOM节点被销毁，组件经历componentWillUnmount()，然后重新创建一棵新树， 组件经历 componentWillMount() 和  componentDidMount()。

2. 可以为组件或元素设置key属性，key用来标识这个组件或元素。key不需要全局唯一，只需要在兄弟组件或兄弟元素间保证唯一性就可以。key常用到集合（List）元素中。例如：

<ul><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

当在第一个位置插入一条记录Book C 时，

<ul><li key=&#39;c&#39;>Book C</li><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

由于有key的标识，React知道此时新增了一条记录，会创建一个新的25edfb22a4f469ecb59f1190150159c6元素，并把它插入到列表中的第一个位置。如果没有设置key，React并不知道是新增了一条记录，还是原来的两条记录完全替换成新的三条记录，或者其他更加复杂的修改场景。React需要自上而下的比较每一条记录，这样每次比较节点都不同，所以需要修改两次节点，然后再新增一个节点，效率明显要差很多。

这里同时揭露了另一个问题，不要使用元素在集合中的索引值作为key，因为一旦集合中元素顺序发生改变，就可能导致大量的key失效，进而引起大量的修改操作。

如何发送网络请求

当我们需要从服务器获取数据时，我们应该在组件的哪一个生命周期方法中发送网络请求呢？React官网上提到，可以在componentDidMount中发送网络请求，这也是一般情况下的最佳实践。有些人也会把发送网络请求放在componentWillMount中，并且认为这个方法先于componentDidMount调用，所以可以更快地获取数据。个人认为，这种使用方法一般也是没有问题的，但在一些场景下会出现问题，比如需要在服务器端渲染时，componentWillMount会被调用两次，一次是在Server端，一次是在Client端。可参考这篇文章。

本篇文章到这就结束了（想看更多就到PHP中文网React使用手册栏目中学习），有问题的可以在下方留言提问。

Das obige ist der detaillierte Inhalt vonWie viel wissen Sie über React? Zusammenfassung der Dinge, die Sie bei React beachten sollten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!