1. Feature Die
Fragmentvorlage
unterstützt Fragment- und String-Typen, die ReactElement-Arrays und -Strings entsprechen
v16.2.0 bietet auch Unterstützung für JSX-Fragmente:
Fehlerbehandlung auf
Komponentenebene auf <> </> Fehlergrenze , Unterstützung für die Erfassung interner Ausnahmen im Unterkomponentenbaum und eine Lösung für die UI-Ebene
Mit Portal
kann der Komponentenbaum nicht mit der DOM-Baumstruktur inkonsistent sein und wird in Szenarien wie Hovercards, QuickInfos usw. verwendet.
In der DOM-Struktur des Tooltips sind Ziel und Tipp im Allgemeinen Brüder (für das Layout erforderlich), während Tipp logischerweise zum Ziel gehört, bei dem es sich um eine Eltern-Kind-Beziehung handelt. Portale werden zur Behandlung dieses Szenarios verwendet.
Insbesondere nach der Verarbeitung von Ereignisblasen kann die übergeordnete Komponente der Portalkomponente weiterhin Blasenbenachrichtigungen erhalten (vor Reaktion 16 wurde ein Ereignissystem eingebaut, um den Unterschied beim DOM-Ereignisblasen auszugleichen. Übrigens wird das Beispiel für das Sprudeln von Blasen unterstützt).
Die Unterstützung für benutzerdefinierte DOM-Attribute verfügt über eine
integrierte Whitelist mit HTML / SVG-Attributnamen. Benutzerdefinierte Attribute werden blockiert und ignoriert. Durch Reaktion 16 wird diese Einschränkung aufgehoben
Es gibt zwei Gründe, um diese Einschränkung aufzuheben: Zum einen ist die integrierte Eigenschaftsfilterung dieser Schicht nicht für nicht standardmäßige (wie die Vorschlagsphase) neue Eigenschaften und andere Bibliotheken / Frameworks (wie Angular, Polymer) geeignet, zum anderen ist sie im Bundle erforderlich Eingebaute weiße Liste von Attributen, die nicht klein sind, was schwierig zu pflegen ist
Das verbesserte serverseitige Rendering
soll dreimal schneller sein als React 15 (Benchmark-Szenario, ein Geschäftsszenario soll 1,3-mal schneller sein) und hat mehrere Dinge getan:
Support-Stream
Die redundante process.env (der Zugriff auf diese Variable in der Knotenumgebung ist sehr zeitaufwändig) wurde während der Erstellung entfernt.
Der Client berechnet die Prüfsumme nicht mehr, sondern verwendet das vorhandene DOM so weit wie möglich wieder (ähnlich wie bei der Implementierung von Inferno für die Wiederverwendung von DOM-Knoten, aber die Wiederverwendung von Inferno scheint auf einige Probleme gestoßen zu sein und wird jetzt nur als Option und nicht als Hervorhebungsfunktion bereitgestellt).
Hinweis: Bei Reaktion 16 scheint es Probleme mit der Wiederverwendung von DOM-Knoten zu geben:
However, it’s dangerous to have missing nodes on the server render as this might cause sibling nodes to be created with incorrect attributes.PS Auf welche gefährlichen Szenen man achten sollte, kann der offizielle Blog später geben, und es ist vorerst nicht klar
Reduzierte Dateigröße
React Bundle Slimming (überarbeitete, abgeflachte Verpackungsstrategie und ersetzt durch Rollup), 30% kleiner
2. Die
größte Veränderung in *** sollte *** sein, diesmal habe ich es ernsthaft erkannt (der vorherige *** scheint am Boden aufgegriffen zu werden)
1. Die neue API-
Serverseite fügt renderToNodeStream, renderToStaticNodeStream hinzu, die renderToString bzw. renderToStaticMarkup entsprechen
Hydrat auf Kundenseite hinzugefügt
2. Lose Konsistenzprüfung Die
clientseitige Überprüfung ist nicht so streng:
In Reaktion 15 führt der Client eine Konsistenzprüfung auf Zeichenebene für die erhaltenen *** Ergebnisse durch. Wenn eine Nichtübereinstimmung vorliegt, wird der Client das gesamte Ergebnis neu generieren und ersetzen.
React 16 ermöglicht eine inkonsistente Attributreihenfolge und repariert nicht automatisch inkonsistente Attribute und nimmt Änderungen auf Teilbaumebene vor, wenn eine nicht übereinstimmende Tag-Struktur auftritt, anstatt die gesamte zu ersetzen
Außerdem werden die Prüfsumme (Datenreaktionsprüfsumme) und die ID (Datenreaktions-ID) in der Server-HTML-Struktur entfernt, und die Größe des Antwortkörpers wird erheblich reduziert:
<!-- react 15 -->
<div data-reactroot="" data-reactid="1"
data-react-checksum="122239856">
<!-- react-text: 2 -->This is some <!-- /react-text -->
<span data-reactid="3">server-generated</span>
<!-- react-text: 4--> <!-- /react-text -->
<span data-reactid="5">HTML.</span>
</div>
<!-- react 16 -->
<div data-reactroot="">
This is some <span>server-generated</span> <span>HTML.</span>
</div>
3. Durch die Leistungsoptimierung
wird der redundante Zugriff auf process.env.NODE_ENV standardmäßig entfernt, ohne dass eine manuelle Kompilierung und Entfernung erforderlich ist
*** Erstellen Sie kein einmaliges virtuelles DOM mehr, das Ganze ist viel schneller
Die Unterstützung von Stream bietet die folgenden Leistungsvorteile:
Der Server sendet es, während er macht, anstatt darauf zu warten, dass der *** abgeschlossen ist, bevor er alles auf einmal sendet, ist TTFB (die Zeit bis zum ersten Byte) schneller
Der Client zeichnet während der Verbindung, anstatt zu warten, bis der Antwortinhalt vollständig ist, bevor er mit dem Zeichnen beginnt. Die Zeitpunkte für das Parsen, Zeichnen und Laden externer Ressourcen sind alle erweitert
4. Fehlergrenze und
Portalreaktion 16 werden nicht unterstützt *** Fehlergrenze und Portal werden nicht unterstützt
Das Rendern der Service-Terminal-Komponente ist falsch und wird nicht durch die Fehlergrenze blockiert. Um Leistungsvorteile zu streamen, wird die Fehlergrenze geopfert:
This is intentional / a known limitation. With streaming rendering it’s impossible to “call back” markup that has already been sent, and we opted to keep renderToString and renderToNodeStream’s output identical.
Nicht nur renderToNodeStream, renderToStaticNodeStream unterstützt weder Error Boundary noch renderToString. Wie oben erwähnt, müssen keine zwei Mechanismen beibehalten werden, um die Ausgabeergebnisse konsistent zu halten
PS Weitere Informationen zu *** Error Boundary finden Sie unter componentDidCatch funktioniert nicht in renderToString von React 16
Die Portal-Funktion kann einen "Reflow" verursachen, der mit "Fehlergrenze" identisch ist. Sie kann vom Stream-Mechanismus nicht unterstützt werden (es ist natürlich unmöglich, Portal-Inhalte in den gesendeten Stream einzufügen).
3. Die
neue Kernarchitektur von Fibre (es dauerte 2 Jahre), um den Komponenten-Rendering-Mechanismus vollständig neu zu schreiben. Die wichtigste Funktion ist das asynchrone Rendering, das ein planbares Rendering implementiert (lösen Sie das Problem vollständig, dass der Mount-Prozess nach dem Start nicht unterbrochen werden kann. Problem)
Der Refactoring-Prozess ist
eine große Sache, und der Ausführungsprozess des Refactorings ist sehr interessant. im Allgemeinen:
Ziehen Sie dazu keinen neuen Zweig. Die Umschaltung erfolgt über den useFiber-Funktionsschalter, der die tägliche Wartung / Konfliktbehandlung usw. vereinfachen soll.
Der erste Schritt besteht darin, ein Skelett (Skelett) herzustellen. Unterstützen Sie einen Teil der API und führen Sie dann langsam alle Testfälle durch (das sogenannte TDD, die testgetriebene Entwicklung und schließlich 2000 Fälle).
Ingenieurhilfen. Einschließlich Fortschrittsverfolgung, Verfolgung einzelner Testergebnisse (um leicht herauszufinden, was in einer Übermittlung behoben wurde, was fehlerhaft ist, ist die Methode sehr einfach: Hinzufügen von tests-failed.txt, tests-passing.txt zur git-Verfolgung), kontinuierliche Überprüfung der Produktionsumgebung ( Das sogenannte Hundefutter, der gesamte Prozess vom frühen Stadium bis zum letzten einzelnen Testdurchlauf, wird kontinuierlich "tatsächlich verifiziert", was als sichtbarer Glaube angesehen werden kann.
Finden Sie ein geeignetes Unternehmen als Prüfstand. Nachdem es fast stabil ist, sich durch das eigentliche Geschäft als produktionsbereit erweisen und Daten durch A / B-Tests abrufen, 200 Millionen Benutzer helfen lassen, es zu fühlen, und dann auf die volle Menge zugeschnitten, gleichzeitig wird das interne System vollständig abgeschnitten und das Überprüfungsszenario erweitert, schließlich Reagieren Die native Anwendung ist in Graustufen erhältlich
Nicht direkt am neuen Mechanismus. Derzeit wird es immer noch synchron ausgeführt (obwohl Fibre asynchron unterstützt). Bereiten Sie sich darauf vor, sich noch einige Monate zurückzuhalten, um den Übergang zu glätten
Informationen zum spezifischen Refactoring-Prozess finden Sie unter Reaktion 16: Ein Blick in eine API-kompatible Umschreibung unserer Frontend-UI-Bibliothek
Daher wird asynchrones Rendern vorübergehend nicht unterstützt:
This initial React 16.0 release is mostly focused on compatibility with existing apps. It does not enable asynchronous rendering yet. We will introduce an opt-in to the async mode later during React 16.x. We don’t expect React 16.0 to make your apps significantly faster or slower, but we’d love to know if you see improvements or regressions.Vorteile und
neue Funktionen
Fehlerbehandlung auf Komponentenebene, Rendering-Rückgaben für mehrere Komponenten und andere Funktionen, die zuvor nicht einfach zu implementieren waren, können nach dem Refactoring erstellt werden
Vorteil erleben
Glasfaser ist nicht unbedingt schneller, aber sie ist flüssiger (geteilte Rendering-Aufgaben und Balance-Planung, um zu vermeiden, dass der Haupt-Thread für lange Zeit belegt wird), zusätzlich zur Aufgabenprioritätssteuerung, die Animation und andere Prioritätsausführung ermöglicht
Der Unterschied liegt auf der Hand, siehe React Stack vs Fibre
Referenzmaterialien
reagieren v16.0
Was ist neu beim serverseitigen Rendern in Reaktion 16?
Wie React Fibre Ihre Web- und mobilen Apps reibungsloser und reaktionsschneller machen kann