Fermer

août 21, 2020

Que signifie React 17 pour les développeurs


Voyez trois des changements les plus importants – mises à jour graduelles, modifications de la délégation d'événements et mises à jour de la trace de pile – et voyez ce que ces changements signifient pour l'avenir de React dans son ensemble.

La semaine dernière, l'équipe React a annoncé une version candidate de React 17 avec le titre convivial «Pas de nouvelles fonctionnalités».

Mais malgré les titres «Pas de nouvelles fonctionnalités», React 17 inclut quelques changements dont tous les développeurs React devraient être conscients.

Dans cet article, je vais vous aider à vous lever

Mises à jour progressives

L'objectif principal de React 17 est de faciliter la mise à niveau de React lui-même. Extrait du blog de publication:

«React 17 permet des mises à niveau progressives de React. Lorsque vous passez de React 15 à 16 (ou, bientôt, de React 16 à 17), vous mettez généralement à niveau l'ensemble de votre application en même temps. Cela fonctionne bien pour de nombreuses applications. Mais cela peut devenir de plus en plus difficile si la base de code a été écrite il y a plus de quelques années et n'est pas activement maintenue. Et bien qu'il soit possible d'utiliser deux versions de React sur la page, jusqu'à React 17 cela a été fragile et a causé des problèmes avec les événements. »

Dans le monde de l'entreprise, il est courant que les développeurs souhaitent utiliser de nouveaux fonctionnalités du framework, mais ne pas avoir la capacité de le faire, car il est difficile de justifier le temps nécessaire pour mettre à niveau le logiciel sans livrer de nouvelles fonctionnalités. Ce changement dans React 17 présente un nouveau flux de travail de mise à niveau intéressant, où les développeurs React peuvent laisser leur code existant sur une version héritée de React, tout en écrivant un nouveau code avec le dernier et le meilleur.

Et il y a une priorité pour ces deux versions- flux de travail d'un cadre sur une page. Par exemple, l'équipe Angular vous autorise depuis longtemps à exécuter simultanément Angular 1 et Angular 2+ et l'exécution d'une recherche Google «exécuter Angular un et deux ensemble» renvoie plus de 38 millions de résultats.

Cela étant dit, l'équipe React tient à préciser que ce flux de travail ne doit être utilisé que lorsque c'est absolument nécessaire.

«Pour la plupart des applications, la mise à niveau en une seule fois reste la meilleure solution. Le chargement de deux versions de React – même si l'une d'elles est chargée paresseusement à la demande – n'est toujours pas idéal. »

Si vous souhaitez essayer ce nouveau flux de travail, consultez l'exemple d'application fourni par l'équipe React avec la libération . Il est bien organisé et la structure des dossiers indique très clairement quel code est hérité, lequel est moderne et lequel est partagé entre les approches.

 folder-structure "title =" folder-structure "/> </p>
<h2 id= Modifications apportées à la délégation d'événements

Le deuxième grand changement dans React 17 affecte le fonctionnement de la délégation d'événements dans React. Sur le blog:

" In React 17, React n'attachera plus de gestionnaires d'événements au niveau du document. Au lieu de cela, il les attachera au conteneur DOM racine dans lequel votre arbre React est rendu. »

Cette modification ne vous affectera probablement plus, car c'est le cas un détail d'implémentation que React n'a exposé via aucune API. Mais comme React est désormais mieux isolé – autrement dit, le framework ne dépend plus de gestionnaires d'événements en dehors de son élément racine – cela ouvre des possibilités intéressantes.

Par exemple, plusieurs applications React peuvent maintenant exister sur la même page avec peu de risque de conflit. Par exemple, vous pouvez utiliser l'application par défaut Create React App et faire quelque chose de stupide comme ceci:

 < div   id  =  "racine" > </  div  >
< div   id  =  "root2" > </  div >
< div   id  =  "root3" > </  div >
< div   id  =  "root4" > </  div >
 ReactDOM.render (
   < React.StrictMode > 
     < App  />[19659028Often</[19459030[]React.StrictMode[19459004letter>,
  document.getElementById ('racine')
);

ReactDOM.render (
   < React.StrictMode > 
     < App  />[19659028Often</[19459030[]React.StrictMode[19459004letter>,
  document.getElementById ('racine2')
);

ReactDOM.render (
   < React.StrictMode > 
     < App  />[19659028[/[19459030.
  document.getElementById ('racine3')
);

ReactDOM.render (
   < React.StrictMode > 
     < App  />[19659028[/[19459030.
  document.getElementById ('racine4')
);

Et avec un peu de CSS, vous pourriez avoir une page avec quatre applications React identiques, qui ressemblent à ceci.

 Plusieurs versions de React une page "title =" Plusieurs versions de React une page "/> </p>
<p> Bien que votre application moyenne ne devrait pas afficher plusieurs instances React, cela ouvre des possibilités intéressantes pour les applications de type tableau de bord. Par exemple, imaginez une application de tableau de bord avec un certain nombre de widgets, et tous les widgets sont des mini-applications React. [19659006] Dans un sens plus pratique, cette modification de la délégation d'événements permettra à React de mieux jouer avec d'autres frameworks. D'après le blog: </p>
<blockquote>
<p> «Cette modification facilite également l'intégration de React dans des applications créées avec d'autres technologies. Par exemple, si le Le «shell» externe de votre application est écrit en jQuery, mais le nouveau code à l'intérieur de celui-ci est écrit avec React, e.stopPropagation () à l'intérieur du code React l'empêcherait désormais d'atteindre le code jQuery – comme vous vous en doutez. "[19659010] C'est assez courant pour d'autres frameworks, en particulier alliez des frameworks basés sur DOM comme jQuery, pour jouer avec les événements au niveau du document. Maintenant que React n'utilise pas d'événements en dehors de son contexte de rendu, il est beaucoup plus sûr d'introduire React dans des applications héritées, où vous pouvez avoir un tas d'outils JavaScript plus anciens que vous ne pouvez pas facilement supprimer. </p>
<h2 id= Better Stack Traces [19659008] Le dernier changement qui a attiré mon attention affecte la façon dont React rend les traces de pile. D'après le blog:

«Dans React 17, les piles de composants sont générées en utilisant un mécanisme différent qui les assemble à partir des piles JavaScript natives normales. Cela vous permet d'obtenir les traces de pile de composants React entièrement symbolisées dans un environnement de production. "

La façon dont ils accomplissent cela est un peu folle.

" La façon dont React implémente cela est quelque peu peu orthodoxe. À l'heure actuelle, les navigateurs ne permettent pas d'obtenir le cadre de pile d'une fonction (fichier source et emplacement). Ainsi, lorsque React détecte une erreur, il reconstruira maintenant sa pile de composants en lançant (et en capturant) une erreur temporaire de l'intérieur de chacun des composants ci-dessus, lorsque cela est possible. »

Whoa.

Mais cela fonctionne, et Je peux voir que cela est extrêmement utile pour le débogage de production. Par exemple, supposons que vous utilisiez le code suivant pour détecter les erreurs dans votre application:

 import  React  from   'react' ;
 import  {ErrorBoundary}  de   "react-error-boundary" ;

 fonction   ErrorFallback  ( {componentStack} )  {
   console  .log (componentStack);

   retour  (
     < p   style  =  {{  couleur:  " red "}}>  Une erreur s'est produite!  </  p > 
  )
}

 fonction   Application  ()  {
   retour  (
     < ErrorBoundary   FallbackComponent  =  {ErrorFallback} > 
      {/ * Votre application * /}
     </  ErrorBoundary > 
  );
}

Le ErrorFallback utilise ici les limites d'erreur de React API et enregistre chaque erreur componentStack chaque fois qu'un problème survient. Avec React 16, le code ci-dessus produit des traces de pile peu utiles en cas de problème en production.

Par exemple. voici une trace pas particulièrement utile que j'obtiens en essayant d'appeler toUpperCase () sur null .

     in  s
     dans   i 
     dans  u
     dans  StrictMode App  .js :  6 :  10 

Après la mise à niveau de l'application vers React 17, la trace de la pile inclut désormais un lien vers l'emplacement de chaque composant dans le code source.

 s  @http : // localhost :  8000  / static / js / main.  15  f3e38c.chunk.  js:  1 :  470 
i  @http : // localhost :  8000  / static / js /  2.477  a9a31.chunk.  js:  2 [19659069]:  1611 
u

En soi, cela n'est pas particulièrement utile – sauf si vous êtes maladroitement conscient de ce qu'est 2.477a9a31.chunk.js: 2: 1611 – mais si vous combinez ces traces de pile avec des cartes sources et un symbole d'erreur comme Sentry, vous aurez la possibilité d'obtenir des traces complètes d'erreurs de production dans la pile de composants.

C'est certainement une fonctionnalité qui vaut la peine d'être utilisée si vous avez du mal à déboguer vos erreurs de réaction de production.

The Future of React

Dans l'ensemble, React 17 vise à rendre React plus stable et plus facile à mettre à niveau, mais qu'est-ce que cela signifie pour l'avenir de React? D'après le blog:

«Nous travaillons activement sur les nouvelles fonctionnalités de React, mais elles ne font pas partie de cette version. La version React 17 est un élément clé de notre stratégie pour les déployer sans laisser personne de côté. »

Lorsque vous opérez à l'échelle de React, il est presque impossible d'introduire des changements sans segmenter votre base d'utilisateurs.

Consider React crochets. Bien que les hooks ne soient pas un changement radical, ils ont segmenté toute la documentation et les didacticiels en ligne en deux groupes: ceux qui utilisent des hooks et ceux qui n'en utilisent pas. Chez Progress, nous avons ressenti cette lutte de première main, car certains de nos utilisateurs de KendoReact préfèrent voir la documentation avec des crochets, certains préfèrent voir la documentation avec des composants de classe, et certains veulent que les deux soient disponibles. Évidemment, nous voulons rendre tous les utilisateurs heureux, mais il n'y a qu'un nombre limité de permutations de versions et d'API de React que nous pouvons raisonnablement prendre en charge.

Dans ce contexte, je suis rassuré que l'équipe de React a passé une version en se concentrant sur l'expérience. de votre développeur React moyen et s'efforce d'améliorer le chemin de mise à niveau. J'espère que cela facilitera l'utilisation des futures fonctionnalités de React pour tout le monde ?







Source link