1. Fonctionnalité Le modèle de
fragment
prend en charge les types de fragment et de chaîne, correspondant aux tableaux et chaînes ReactElement
La v16.2.0 fournit également la prise en charge des fragments JSX: <> </> gestion des erreurs au niveau des composants de
limite d'
erreur, prise en charge de la capture des exceptions internes dans l'arborescence des sous-composants et solution pour la couche d'interface utilisateur
Portal
permet à l'arborescence des composants d'être incohérente avec la structure de l'arborescence DOM et est utilisé dans des scénarios tels que les hovercards, les info-bulles, etc.
Par exemple, dans la structure DOM de tooltip, target et tip sont généralement frères (requis pour la mise en page), alors que logiquement tip appartient à target, qui est une relation parent-enfant. Les portails sont utilisés pour gérer ce scénario.
En particulier, après le traitement du bullage d'événements, le composant parent du composant de portails peut toujours recevoir des notifications de bullage (avant React 16, un système d'événements était intégré pour lisser la différence de bullage d'événements DOM. En passant, l'exemple de bullage est pris en charge)
La prise en charge des attributs DOM personnalisés comporte une
liste blanche intégrée de noms d'attributs HTML / SVG. Les attributs personnalisés seront bloqués et ignorés. React 16 supprime cette restriction
Il y a deux raisons pour supprimer cette restriction. La première est que le filtrage des propriétés intégré de cette couche n'est pas compatible avec les nouvelles propriétés non standard (comme l'étape de proposition) et d'autres bibliothèques / frameworks (comme Angular, Polymer); deuxièmement, il est nécessaire dans le bundle Une liste blanche intégrée d'attributs qui ne sont pas de petite taille, ce qui est difficile à maintenir
L'amélioration du rendu côté serveur
serait 3 fois plus rapide que React 15 (scénario de référence, un scénario commercial serait 1,3 fois plus rapide), et a permis plusieurs choses:
Flux d'assistance
Le process.env redondant (accéder à cette variable dans l'environnement de nœud prend beaucoup de temps) a été supprimé lors de la construction.
Le client ne calcule plus la somme de contrôle, mais réutilise autant que possible le DOM existant (similaire à l'implémentation de inferno pour la réutilisation des nœuds DOM, mais la réutilisation inferno semble avoir rencontré quelques problèmes, et n'est désormais fournie qu'en option plutôt qu'en tant que fonction de mise en évidence)
Remarque: React 16 semble avoir des problèmes de réutilisation des nœuds DOM:
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 À quelles scènes dangereuses il faut prêter attention, le blog officiel peut être donné plus tard, et ce n'est pas clair pour le moment
Taille de fichier réduite
React bundle slimming (stratégie d'emballage refactorisée, aplatie et remplacée par rollup), 30% plus petite en taille
2. Le
plus gros changement dans *** devrait être ***, cette fois je m'en suis rendu compte sérieusement (le *** précédent semble être ramassé sur le terrain)
1. Le nouveau
côté serveur de l' API ajoute renderToNodeStream, renderToStaticNodeStream correspondant respectivement à renderToString, renderToStaticMarkup
Hydrate ajouté côté client
2. Vérification de la cohérence lâche La vérification
côté client n'est pas si stricte:
Dans React 15, le client effectuera un contrôle de cohérence au niveau des caractères sur les *** résultats obtenus, et en cas de non-concordance, le client régénérera et remplacera le résultat entier.
React 16 permet un ordre d'attribut incohérent, et ne répare pas automatiquement les attributs incohérents, et apportera des modifications au niveau de la sous-arborescence lors de la rencontre d'une structure de balise incompatible, plutôt que de remplacer la totalité
De plus, la somme de contrôle (data-react-checksum) et l'id (data-reactid) sur la structure HTML du serveur sont également supprimées, et la taille du corps de la réponse sera considérablement réduite:
<!-- 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. L'optimisation des performances
supprime l'accès redondant process.env.NODE_ENV par défaut, pas besoin de compiler et de supprimer manuellement
*** Plus besoin de créer un DOM virtuel unique, le tout est beaucoup plus rapide
La prise en charge du flux apporte les avantages de performances suivants:
Le serveur l'envoie en faisant, au lieu d'attendre que le *** soit terminé avant de tout envoyer en même temps, TTFB (le temps au premier octet) est plus rapide
Le client dessine lors de la connexion, au lieu d'attendre que le contenu de la réponse soit terminé avant de commencer à dessiner. Les moments d'analyse, de dessin et de chargement des ressources externes sont tous avancés.
4. Error Boundary et Portal
React 16 ne sont pas pris en charge *** Error Boundary et Portal ne sont pas pris en charge
Le rendu du composant de terminal de service est incorrect et ne sera pas bloqué par la limite d'erreur. Afin de diffuser les avantages des performances, la limite d'erreur est sacrifiée:
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.
Non seulement renderToNodeStream, renderToStaticNodeStream ne prend pas en charge Error Boundary, pas plus que renderToString. Comme mentionné ci-dessus, pour que les résultats de sortie restent cohérents, il n'y a pas deux mécanismes à maintenir
PS Pour plus d'informations sur *** Error Boundary, veuillez consulter componentDidCatch ne fonctionne pas dans le renderToString de React 16
La fonctionnalité de portail peut provoquer une "redistribution", ce qui équivaut à la limite d'erreur. Elle ne peut pas être prise en charge dans le cadre du mécanisme de flux (il est bien entendu impossible d'insérer le contenu du portail dans le flux qui a été envoyé)
3.
Nouvelle architecture de base de Fiber (il a fallu 2 ans) pour réécrire complètement le mécanisme de rendu des composants. La fonctionnalité la plus critique est le rendu asynchrone, qui implémente le rendu planifiable (résolvez complètement le problème que le processus de montage ne peut pas être interrompu une fois qu'il démarre. problème)
Le processus de refactoring est
une chose tellement énorme, et le processus d'exécution du refactoring est très intéressant. Discussion générale:
Ne tirez pas sur une nouvelle branche pour le faire. Il est commuté via le commutateur de fonctionnalité useFiber, qui simplifie la maintenance quotidienne / la gestion des conflits, etc.
La première étape consiste à fabriquer un squelette (squelette). Prise en charge d'une partie de l'API, puis parcourez lentement tous les cas de test (le soi-disant TDD, le développement piloté par les tests et enfin 2000 cas)
Aides techniques. Y compris le suivi de la progression, le suivi des résultats de test unique (pour une découverte facile de ce qui est corrigé dans une soumission, de ce qui est cassé, la méthode est très simple: ajoutez tests-failing.txt, tests-passant.txt au suivi git), vérification continue de l'environnement de production ( Le soi-disant dogfooding, l'ensemble du processus, du stade précoce à la dernière passe de test unique, est continuellement "effectivement vérifié", ce qui peut être considéré comme une croyance visible)
Trouvez une entreprise appropriée comme banc d'essai. Une fois qu'il est presque stable, prouvez qu'il est prêt pour la production via des activités réelles et obtenez des données via un test A / B, laissez 200 millions d'utilisateurs aider à le ressentir, puis coupez au montant total; en même temps, le système interne est entièrement coupé et le scénario de vérification est étendu; enfin, Réagissez L'application native est disponible en niveaux de gris
Pas directement sur le nouveau mécanisme. Pour le moment, il est toujours exécuté de manière synchrone (bien que Fiber prenne en charge asynchrone), préparez-vous à rester quelques mois de plus pour faciliter la transition
Pour le processus de refactoring spécifique, voir React 16: Un regard à l'intérieur d'une réécriture compatible API de notre bibliothèque d'interface utilisateur frontend
Le rendu asynchrone n'est donc pas pris en charge temporairement:
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.Avantages et
nouvelles fonctionnalités
La gestion des erreurs au niveau des composants, le rendu des retours vers plusieurs composants et d'autres fonctionnalités qui n'étaient pas faciles à implémenter auparavant peuvent être créés après la refactorisation
Avantage d'expérience
La fibre n'est pas forcément plus rapide, mais elle sera plus fluide (répartir les tâches de rendu et équilibrer la planification pour éviter de prendre le thread principal pendant longtemps), en plus du contrôle de la priorité des tâches, permettant l'animation et d'autres exécutions prioritaires
La différence est assez évidente, voir React Stack vs Fiber
Matériaux de référence
React v16.0
Nouveautés du rendu côté serveur dans React 16
Comment React Fiber peut rendre vos applications Web et mobiles plus fluides et plus réactives