React v16.7 : non, ce n’est pas la version avec les Hooks

Notre dernière version comprend un correctif important de React.lazy. Bien que l’API reste inchangée, nous le publions en tant que mineure plutôt que simple correctif.

Pourquoi ce correctif donne-t-il lieu à une mineure ?

React utilise une gestion sémantique de versions. Ça signifie généralement que nous utilisons des versions de correctif quand on élimine des bugs, et des mineures pour de nouvelles fonctionnalités (qui ne brisent pas la compatibilité ascendante). Ceci dit, nous nous gardons la possibilité de publier des versions mineures même si elles n’incluent pas de nouvelles fonctionnalités. L’idée consiste à réserver les versions de correctifs pour les changements qui ont une très faible chance de casser quelque chose. Les correctifs sont versions les plus importantes car elles contiennent parfois des corrections critiques. Ça implique que les versions de correctifs mettent la barre de la fiabilité au plus haut. Il est inacceptable qu’un correctif introduise de nouveaux bugs, parce que si les gens en viennent a se méfier des correctifs, ça va réduire notre capacité à corriger les bugs dès qu’ils surviennent—par exemple pour corriger une faille de sécurité.

Nous ne livrons jamais des bugs volontairement. React a durement gagné sa réputation de stabilité, et nous avons bien l’intention de la conserver. Nous testons intensivement chaque version de React avant publication. Ça inclut des test unitaires, tests génératifs (fuzzy), tests d’intégrations, et une utilisation interne dans des dizaines de milliers de composants. Néanmoins, nous faisons parfois des erreurs. C’est pourquoi, à l’avenir, notre politique sera la suivante : si une version contient des modifications non triviales, nous incrémenterons la version mineure, même si le comportement externe est le même. Nous augmenterons aussi la version mineure si nous modifions des API préfixées par unstable_.

Puis-je enfin utiliser les Hooks ?

Pas encore, mais bientôt !

A la React Conf, nous avons dit que la 16.7 serait la première version à fournir les Hooks. C’était une erreur. Nous ne devrions pas lier un numéro de version spécifique à une fonctionnalité non publiée. Nous éviterons ça à l’avenir.

Même si la 16.7 n’inclut pas les Hooks, n’essayez pas de deviner la date de lancement des Hooks. Nos plans pour les Hooks n’ont pas changé :

• La proposition des Hooks a été acceptée (avec des changements mineurs suite à vos retours).
• L’implémentation a été fusionnée dans le dépôt React (derrière un drapeau).
• Nous sommes actuellement en phase de test, et vous pouvez attendre une sortie publique dans quelques mois.

Vous êtes nombreux·ses à nous avoir dit vouloir utiliser les Hooks dans vos applications. Nous sommes tout aussi impatients de les livrer ! Mais dans la mesure où les Hooks changent notre façon d’écrire des composants React, nous prenons bien le temps de peaufiner les détails. Nous apprécions votre patience alors que nous préparons cette super nouvelle fonctionnalité à être largement utilisée.

Pour en savoir plus sur notre feuille de route consultez l’article précédent.

Installation

React v16.7.0 est disponible sur npm.

Pour installer React 16 avec Yarn, exécutez :

yarn add react@^16.7.0 react-dom@^16.7.0

Pour installer React 16 avec npm, exécutez :

npm install --save react@^16.7.0 react-dom@^16.7.0

Nous fournissons aussi des builds UMD de React via un CDN :

<script crossorigin src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Référez-vous à la documentation pour des instructions détaillées d’installation.

Changelog

React DOM

• Correction de la performance de React.lazy pour un grand nombre de composants chargés paresseusement. (@acdlite dans #14429)
• Nettoyage de champs au démontage pour éviter les fuites mémoire. (@trueadm dans #14276)
• Correction d’un bug avec le SSR et les contextes quand on mélange react-dom/server@16.6 et react@<16.6. (@gaearon dans #14291)
• Correction d’un recul de performance en mode profilage. (@bvaughn dans #14383)

Planificateur (expérimental)

• Envois à MessageChannel plutôt qu’à window. (@acdlite dans #14234)
• Réduction des surcoûts de sérialisation. (@developit dans #14249)
• Correction du recours à setTimeout en secours dans les environnements de test. (@bvaughn dans #14358)
• Ajout de méthodes pour le débogage. (@mrkev dans #14053)