From ec247a4ef798f1904c0941e6ebbd76089adad992 Mon Sep 17 00:00:00 2001 From: Christophe Porteneuve Date: Wed, 6 Sep 2023 13:16:19 +0200 Subject: [PATCH 1/2] copy(blog/canaries): first full translation --- TRANSLATORS.md | 1 + src/content/blog/2023/05/03/react-canaries.md | 89 +++++++++---------- src/content/blog/index.md | 4 +- src/sidebarBlog.json | 4 +- 4 files changed, 48 insertions(+), 50 deletions(-) diff --git a/TRANSLATORS.md b/TRANSLATORS.md index e9441b78c..43cff30a4 100644 --- a/TRANSLATORS.md +++ b/TRANSLATORS.md @@ -129,6 +129,7 @@ Voici la liste par ordre alphabétique (prénom, nom). **🙏🏻 Mille mercis
  • Contributeurs aux docs
  • Remerciements
  • Blog (accueil)
    • +
  • Blog : React Canaries
  • Avertissement : prop ARIA invalide
  • Avertissement : règles des Hooks
  • Avertissement : props à traitement spécial
    • diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index 81da3fd00..ed7d29c23 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -1,94 +1,91 @@ --- -title: "React Canaries: Enabling Incremental Feature Rollout Outside Meta" +title: "React Canaries : livraison incrémentale de fonctionnalités hors de Meta" --- -May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite) +Le 3 mai 2023 par [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage) et [Andrew Clark](https://twitter.com/acdlite) --- -We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final, before they're released in a stable version--similar to how Meta has long used bleeding-edge versions of React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. +Nous aimerions offrir à la communauté React un moyen d'adopter individuellement des fonctionnalités dès que leur conception est quasi finalisée —  un peu comme l'utilisation que Meta fait de React en interne depuis longtemps déjà. Nous présentons donc un nouveau [canal de livraison officiel appelé Canary](/community/versioning-policy#canary-channel). Il permet à des environnements choisis tels que les frameworks de découpler leur adoption de fonctionnalités React individuelles du calendrier officiel de sortie de React. --- -## tl;dr {/*tldr*/} +## tl;pl {/*tldr*/} -* We're introducing an officially supported [Canary release channel](/community/versioning-policy#canary-channel) for React. Since it's officially supported, if any regressions land, we'll treat them with a similar urgency to bugs in stable releases. -* Canaries let you start using individual new React features before they land in the semver-stable releases. -* Unlike the [Experimental](/community/versioning-policy#experimental-channel) channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases. -* We will announce breaking changes and new features on our blog as they land in Canary releases. -* **As always, React continues to follow semver for every Stable release.** +* Nous ajoutons un [canal de livraison Canary](/community/versioning-policy#canary-channel) officiel pour React. Puisqu'il est officiellement pris en charge, si des régressions y surviennent, nous les traiterons avec la même priorité que des bugs dans les versions stables. +* Les Canaries vous permettent de commencer à utiliser des nouvelles fonctionnalités individuelles de React avant qu'elles arrivent dans les versions stables officielles. +* Contrairement au canal [Expérimental](/community/versioning-policy#experimental-channel), les Canaries React n'incluent que des fonctionnalités dont nous sommes raisonnablement sûrs qu'elles sont prêtes à être adoptées. Nous encourageons les frameworks à envisager d'incorporer en version fixe un Canary React. +* Nous annoncerons les ruptures de compatibilité ascendante et les nouvelles fonctionnalités sur notre blog dès qu'elles arrivent dans des livraisons Canary. +* **Comme toujours, React continue de respecter le versionnement sémantique pour chaque version du canal Stable.** -## How React features are usually developed {/*how-react-features-are-usually-developed*/} +## Comment les fonctionnalités de React sont-elles généralement développées ? {/*how-react-features-are-usually-developed*/} -Typically, every React feature has gone through the same stages: +En général, une fonctionnalité React est passée à travers les mêmes étapes de développement : -1. We develop an initial version and prefix it with `experimental_` or `unstable_`. The feature is only available in the `experimental` release channel. At this point, the feature is expected to change significantly. -2. We find a team at Meta willing to help us test this feature and provide feedback on it. This leads to a round of changes. As the feature becomes more stable, we work with more teams at Meta to try it out. -3. Eventually, we feel confident in the design. We remove the prefix from the API name, and make the feature available on the `main` branch by default, which most Meta products use. At this point, any team at Meta can use this feature. -4. As we build confidence in the direction, we also post an RFC for the new feature. At this point we know the design works for a broad set of cases, but we might make some last minute adjustments. -5. When we are close to cutting an open source release, we write documentation for the feature and finally release the feature in a stable React release. +1. Nous développons une version initiale et préfixons sont API par `experimental_` ou `unstable_`. La fonctionnalité n'est disponible que *via* le canal de livraison `experimental`. À ce stade, la fonctionnalité est susceptible de beaucoup évoluer. +2. Nous trouvons une équipe chez Meta motivée pour nous aider à tester cette fonctionnalité et nous faire des retours nourris dessus. Ça entraîne un premier lot de modifications. Au fur et à mesure que la fonctionnalité gagne en stabilité, nous collaborons avec davantage d'équipes chez Meta pour la mettre à l'épreuve. +3. Nous finissons par être confiants dans sa conception. Nous retirons alors le préfixe de ses noms d'API et la rendons disponible sur la branche par défaut `main`, utilisée par la plupart des produits de Meta. À ce stade, n'importe quelle équipe chez Meta peut utiliser cette fonctionnalité. +4. Alors que la confiance grandit, nous publions une RFC sur la nouvelle fonctionnalité. On sait à ce stade que la conception fonctionne pour un large éventail de cas, mais nous sommes encore susceptibles de faire des ajustements de dernière minute. +5. Lorsque nous sommes sur le point de faire une livraison *open source*, nous rédigeons la documentation de la fonctionnalité et la livrons enfin dans une version de React stable. -This playbook works well for most features we've released so far. However, there can be a significant gap between when the feature is generally ready to use (step 3) and when it is released in open source (step 5). +Cette stratégie fonctionne bien pour la plupart des fonctionnalités que nous avons livrées jusqu'ici. Cependant, il peut s'écouler un temps considérable entre le moment où une fonctionnalité est globalement prête à l'emploi (étape 3) et celle où elle est livrée en *open source* (étape 5). -**We'd like to offer the React community an option to follow the same approach as Meta, and adopt individual new features earlier (as they become available) without having to wait for the next release cycle of React.** +**Nous aimerions offrir à la communauté React un moyen de suivre la même approchez que chez Meta, en adoptant individuellement de nouvelles fonctionnalités React plus tôt (au fil de leur mise à disposition), sans avoir à attendre la prochaine version officielle de React.** -As always, all React features will eventually make it into a Stable release. +Comme toujours, toutes les fonctionnalités React arriveront à terme dans une version stable. -## Can we just do more minor releases? {/*can-we-just-do-more-minor-releases*/} +## Ne peut-on pas juste faire plus de versions mineures ? {/*can-we-just-do-more-minor-releases*/} -Generally, we *do* use minor releases for introducing new features. +En général, nous *utilisons bien* des versions mineures pour introduire de nouvelles fonctionnalités. -However, this isn't always possible. Sometimes, new features are interconnected with *other* new features which have not yet been fully completed and that we're still actively iterating on. We can't release them separately because their implementations are related. We can't version them separately because they affect the same packages (for example, `react` and `react-dom`). And we need to keep the ability to iterate on the pieces that aren't ready without a flurry of major version releases, which semver would require us to do. +Ce n'est toutefois pas toujours possible. Il arrive que de nouvelles fonctionnalités soient étroitement liées à *d'autres* nouvelles fonctionnalités qui ne sont pas tout à fait finies, et sur lesquelles nous itérons encore. Nous ne pouvons pas les livrer séparément parce que leurs implémentations sont imbriquées. Nous ne pouvons pas les versionner séparément parce qu'elles affectent les mêmes modules (par exemple `react` et `react-dom`). Et nous avons besoin de pouvoir continuer à itérer sur les parties qui ne sont pas encore prêtes sans publier une floppée de versions majeures, ce que le versionnement sémantique nous imposerait dans un tel cas. -At Meta, we've solved this problem by building React from the `main` branch, and manually updating it to a specific pinned commit every week. This is also the approach that React Native releases have been following for the last several years. Every *stable* release of React Native is pinned to a specific commit from the `main` branch of the React repository. This lets React Native include important bugfixes and incrementally adopt new React features at the framework level without getting coupled to the global React release schedule. +Chez Meta, nous avons résolu ce problème en construisant React à partir de sa branche `main`, et en le recalant manuellement sur un commit précis chaque semaine. C'est aussi l'approche suivie depuis quelques années par les versions publiées de React Native. Chaque version *stable* de React Native est calée sur un commit précis de la branche `main` du dépôt React. Ça permet à React Native d'inclure des correctifs importants et d'adopter de façon incrémentale les nouvelles fonctionnalités React au niveau du framework sans être couplé au calendrier global de versions de React. -We would like to make this workflow available to other frameworks and curated setups. For example, it lets a framework *on top of* React include a React-related breaking change *before* this breaking change gets included into a stable React release. This is particularly useful because some breaking changes only affect framework integrations. This lets a framework release such a change in its own minor version without breaking semver. +Nous aimerions rendre ce workflow disponible à d'autres frameworks et environnements choisis. Il permet par exemple à un framework *par-dessus* React d'inclure des modifications rompant la compatibilité ascendante de React *avant* que cette rupture n'apparaisse dans une version stable de React. C'est particulièrement utile parce que certaines ruptures de compatibilité n'affectent que les intégrations par ces frameworks. Ça permet au framework de sortir une telle évolution dans sa propre version mineure, sans casser son versionnement sémantique. -Rolling releases with the Canaries channel will allow us to have a tighter feedback loop and ensure that new features get comprehensive testing in the community. This workflow is closer to how TC39, the JavaScript standards committee, [handles changes in numbered stages](https://tc39.es/process-document/). New React features may be available in frameworks built on React before they are in a React stable release, just as new JavaScript features ship in browsers before they are officially ratified as part of the specification. +Des versions régulières sur le canal Canary nous permettront d'avoir une boucle de retours plus étroite et de nous assurer que les nouvelles fonctionnalités font l'objet de tests exhaustifs par la communauté. Ce workflow ressemble davantage à la façon dont le TC39 (le comité de standardisation de JavaScript) [gère ses évolutions par stades numérotés](https://tc39.es/process-document/). Les nouvelles fonctionnalités de React sont susceptibles d'être disponibles dans des frameworks basés sur React avant d'apparaître dans une version stable de React, tout comme des nouvelles fonctionnalités de JavaScript apparaissent dans des navigateurs avant d'être officiellement ratifiées dans la spécification. -## Why not use experimental releases instead? {/*why-not-use-experimental-releases-instead*/} +## Pourquoi ne pas plutôt utiliser les versions expérimentales ? {/*why-not-use-experimental-releases-instead*/} -Although you *can* technically use [Experimental releases](/community/versioning-policy#canary-channel), we recommend against using them in production because experimental APIs can undergo significant breaking changes on their way to stabilization (or can even be removed entirely). While Canaries can also contain mistakes (as with any release), going forward we plan to announce any significant breaking changes in Canaries on our blog. Canaries are the closest to the code Meta runs internally, so you can generally expect them to be relatively stable. However, you *do* need to keep the version pinned and manually scan the GitHub commit log when updating between the pinned commits. +Même si vous *pouvez* techniquement utiliser les [versions expérimentales](/community/versioning-policy#canary-channel), nous vous déconseillons de les utiliser en production car les API expérimentales peuvent subir des changements significatifs pendant leur phase de stabilisation (et sont même parfois carrément retirées). Même si les Canaries peuvent contenir des erreurs (comme pour toute version), nous avons l'intention désormais d'annoncer toute rupture importante de compatibilité dans les Canaries sur notre blog. Les Canaries sont ce qui se rapproche le plus du code que Meta utilise en interne, vous pouvez donc vous attendre à un bon niveau général de stabilité. En revanche, vous *aurez bien besoin* d'épingler (c'est-à-dire de vous caler sur) une version fixe et de manuellement scanner nos journaux de commits GitHub lorsque vous mettrez à jour la version épinglée. -**We expect that most people using React outside a curated setup (like a framework) will want to continue using the Stable releases.** However, if you're building a framework, you might want to consider bundling a Canary version of React pinned to a particular commit, and update it at your own pace. The benefit of that is that it lets you ship individual completed React features and bugfixes earlier for your users and at your own release schedule, similar to how React Native has been doing it for the last few years. The downside is that you would take on additional responsibility to review which React commits are being pulled in and communicate to your users which React changes are included with your releases. +**Nous nous attendons à ce que la majorité des utilisateurs de React ne travaillant pas sur un environnement choisi (comme un framework) souhaitent continuer à utiliser plutôt les versions stables.** Ceci dit, si vous construisez un framework, vous voudrez peut-être envisager d'incorporer une version Canary de React épinglée sur un commit précis, et de la mettre à jour à votre rythme. L'avantage de cette approche, c'est qu'elle vous permet de livrer des fonctionnalités individuelles finalisées de React (et des correctifs) plus tôt à vos propres utilisateurs, et suivant votre propre calendrier de versions, tout comme React Native le fait depuis plusieurs années. L'inconvénient, c'est que vous endossez davantage de responsabilités en examinant quels commits React sont récupérés et en communiquant sur ces évolutions auprès de vos utilisateurs. -If you're a framework author and want to try this approach, please get in touch with us. +Si vous êtes en charge d'un framework et souhaitez tenter cette approche, merci de nous contacter. -## Announcing breaking changes and new features early {/*announcing-breaking-changes-and-new-features-early*/} +## Annoncer les ruptures de compatibilité et les nouveautés plus tôt {/*announcing-breaking-changes-and-new-features-early*/} -Canary releases represent our best guess of what will go into the next stable React release at any given time. +Les versions Canary représentent notre meilleure vision, à un instant donné, de ce qui arrivera dans la version stable suivante. -Traditionally, we've only announced breaking changes at the *end* of the release cycle (when doing a major release). Now that Canary releases are an officially supported way to consume React, we plan to shift towards announcing breaking changes and significant new features *as they land* in Canaries. For example, if we merge a breaking change that will go out in a Canary, we will write a post about it on the React blog, including codemods and migration instructions if necessary. Then, if you're a framework author cutting a major release that updates the pinned React canary to include that change, you can link to our blog post from your release notes. Finally, when a stable major version of React is ready, we will link to those already published blog posts, which we hope will help our team make progress faster. +Historiquement nous n'annoncions les ruptures de compatibilité ascendante qu'à *la fin* du cycle de livraison (en sortant une version majeure). À présent que nous disposons d'un canal Canary officiel pour consommer React, nous pensons évoluer pour annoncer les ruptures de compatibilité et les nouveautés significatives *au fil de leur apparition* dans les Canaries. Si par exemple nous fusionnons une rupture de compatibilité qui apparaîtra dans un Canary, nous écrirons un billet à ce sujet sur le blog React, en incluant si besoin des *codemods* et des instructions de migration. À partir de là, si vous travaillez sur un e framework et sortez une version majeure qui met à jour sa version épinglée de React Canary pour inclure ces modifications, vous pourrez mettre un lien vers notre billet de blog dans vos notes de version. Enfin, lorsqu'une version majeure stable de React sera prête, nous y mettrons des liens vers les billets de blog déjà publiés, ce qui nous l'espérons aidera votre équipe à progresser plus vite. -We plan to document APIs as they land in Canaries--even if these APIs are not yet available outside of them. APIs that are only available in Canaries will be marked with a special note on the corresponding pages. This will include APIs like [`use`](https://github.com/reactjs/rfcs/pull/229), and some others (like `cache` and `createServerContext`) which we'll send RFCs for. +Nous prévoyons de documenter les API au fil de leur apparition dans les Canaries — même si cs API ne sont pas encore disponibles par ailleurs. Less API qui ne sont disponibles que dans les Canaries seront identifiées par une note spécifique dans leur documentation. Ça inclura des API comme [`use`](https://github.com/reactjs/rfcs/pull/229) et d'autres (telles que `cache` et `createServerContext`) pour lesquelles nous publierons des RFC. -## Canaries must be pinned {/*canaries-must-be-pinned*/} +## Les Canaries doivent être épinglés {/*canaries-must-be-pinned*/} -If you decide to adopt the Canary workflow for your app or framework, make sure you always pin the *exact* version of the Canary you're using. Since Canaries are pre-releases, they may still include breaking changes. +Si vous décidez d'adopter un workflow basé sur Canary pour votre appli ou votre framework, assurez-vous de toujours épingler la version *exacte* du Canary que vous utilisez. Dans la mesure où les Canaries sont des préversions, elles sont susceptibles d'inclure des ruptures de compatibilité. -## Example: React Server Components {/*example-react-server-components*/} +## Exemple : React Server Components {/*example-react-server-components*/} -As we [announced in March](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), the React Server Components conventions have been finalized, and we do not expect significant breaking changes related to their user-facing API contract. However, we can't release support for React Server Components in a stable version of React yet because we are still working on several intertwined framework-only features (such as [asset loading](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) and expect more breaking changes there. +Comme nous l'avons [annoncé en mars](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), les conventions des React Server Components sont finalisées, et nous n'anticipons pas de ruptures majeures dans leur contrat d'API publique. En revanche, nous ne pouvons pas encore prendre en charge les React Server Components dans une version stable de React parce que nous travaillons encore sur plusieurs fonctionnalités qui leur sont étroitement liées mais qui ne concernent que les frameworks (telles que le [chargement de ressources](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) et nous attendons à des ruptures de ce côté-là. -This means that React Server Components are ready to be adopted by frameworks. However, until the next major React release, the only way for a framework to adopt them is to ship a pinned Canary version of React. (To avoid bundling two copies of React, frameworks that wish to do this would need to enforce resolution of `react` and `react-dom` to the pinned Canary they ship with their framework, and explain that to their users. As an example, this is what Next.js App Router does.) +Ça signifie que les React Server Components sont prêts à être adoptés par les frameworks. Cependant, jusqu'à la prochaine version majeure de React, la seule manière pour un framework de les adopter sera d'utiliser une version Canary épinglée de React. (Pour éviter d'inclure deux copies de React dans les *bundles*, les frameworks qui optent pour cette approche devraitnt forcer une résolution des modules `react` et `react-dom` vers leur version Canary épinglée, et l'expliquer à leurs utilisateurs. C'est par exemple ce que fait le *App Router* de Next.js.) -## Testing libraries against both Stable and Canary versions {/*testing-libraries-against-both-stable-and-canary-versions*/} +## Tester des bibliothèques avec les versions Stable et Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} -We do not expect library authors to test every single Canary release since it would be prohibitively difficult. However, just as when we [originally introduced the different React pre-release channels three years ago](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), we encourage libraries to run tests against *both* the latest Stable and latest Canary versions. If you see a change in behavior that wasn't announced, please file a bug in the React repository so that we can help diagnose it. We expect that as this practice becomes widely adopted, it will reduce the amount of effort necessary to upgrade libraries to new major versions of React, since accidental regressions would be found as they land. +Nous ne nous attendons pas à ce que les équipes des bibliothèques tierces testent chaque version Canary, ce serait d'une difficulté prohibitive. En revanche, tout comme lorsque nous avions [introduit les canaux originaux de préversion de React il y a trois ans](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), nous encourageons les bibliothèques à exécuter leurs tests *à la fois* sur la dernière version stable, et sur la dernière version Canary. Si vous constatez un changement de comportement qui n'a fait l'objet d'aucune annonce, merci d'ouvrir un ticket sur le dépôt de Reat pour que nous puissions vous aider à diagnostiquer le problème. Nous estimons qu'une fois cette pratique largement répandue, elle réduira l'effort nécessaire à la mise à jour des bibliothèques pour les nouvelles versions majeures de React, dans la mesure où les régressions accidentelles seront découvertes au fil de leur apparition. -Strictly speaking, Canary is not a *new* release channel--it used to be called Next. However, we've decided to rename it to avoid confusion with Next.js. We're announcing it as a *new* release channel to communicate the new expectations, such as Canaries being an officially supported way to use React. +À proprement parler, Canary n'est pas un *nouveau* canal de publication — il s'appelait auparavant Next. Nous avons toutefois décidé de le renommer pour éviter la confusion avec Next.js. Nous l'annonçons comme un *nouveau* canal de publication pour en communiquer les nouvelles attentes, notamment dans la mesure où les Canaries sont désormais une manière officiellement prise en charge d'utiliser React. -## Stable releases work like before {/*stable-releases-work-like-before*/} - -We are not introducing any changes to stable React releases. - - +## Les versions stables marchetn comme avant {/*stable-releases-work-like-before*/} +Nous n'apportons aucun changement aux versions stables de React. diff --git a/src/content/blog/index.md b/src/content/blog/index.md index 4f63bef63..5edd74493 100644 --- a/src/content/blog/index.md +++ b/src/content/blog/index.md @@ -10,9 +10,9 @@ Ce blog est la source officielle des mises à jour par l'équipe React. Toute a
    - + -Traditionally, new React features used to only be available at Meta first, and land in the open source releases later. We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final--similar to how Meta uses React internally. We are introducing a new officially supported Canary release channel. It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. +Traditionnellement, les nouveautés de React n'étaient d'abord disponibles qu'au sein de Meta, pour arriver plus tard dans les livraisons *open source*. Nous aimerions offrir à la communauté React un moyen d'adopter individuellement des fonctionnalités plus en amont, alors que leur conception est quasi finalisée —  un peu comme l'utilisation que Meta fait de React en interne. Nous présentons donc un nouveau canal de livraison officiel appelé Canary. Il permet à des environnements choisis tels que les frameworks de découpler leur adoption de fonctionnalités React individuelles du planning officiel de sortie de React. diff --git a/src/sidebarBlog.json b/src/sidebarBlog.json index 3057f700c..af8824f60 100644 --- a/src/sidebarBlog.json +++ b/src/sidebarBlog.json @@ -12,8 +12,8 @@ "skipBreadcrumb": true, "routes": [ { - "title": "React Canaries: Enabling Incremental Feature Rollout Outside Meta", - "titleForHomepage": "React Canaries: Incremental Feature Rollout", + "title": "React Canaries : livraison incrémentale de fonctionnalités hors de Meta", + "titleForHomepage": "React Canaries", "icon": "blog", "date": "3 mai 2023", "path": "/blog/2023/05/03/react-canaries" From 98be404a291274eafed58c2476fbaf54c962df57 Mon Sep 17 00:00:00 2001 From: Christophe Porteneuve Date: Wed, 6 Sep 2023 13:32:11 +0200 Subject: [PATCH 2/2] copy(blog/canaries): final review pass --- src/content/blog/2023/05/03/react-canaries.md | 42 +++++++++---------- src/content/blog/index.md | 2 +- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index ed7d29c23..02c98fe30 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -16,27 +16,27 @@ Nous aimerions offrir à la communauté React un moyen d'adopter individuellemen ## tl;pl {/*tldr*/} -* Nous ajoutons un [canal de livraison Canary](/community/versioning-policy#canary-channel) officiel pour React. Puisqu'il est officiellement pris en charge, si des régressions y surviennent, nous les traiterons avec la même priorité que des bugs dans les versions stables. +* Nous ajoutons un [canal de livraison Canary](/community/versioning-policy#canary-channel) officiel pour React. Puisqu'il est officiellement pris en charge, si des régressions y surviennent, nous les traiterons avec la même priorité que des bugs survenant dans les versions stables. * Les Canaries vous permettent de commencer à utiliser des nouvelles fonctionnalités individuelles de React avant qu'elles arrivent dans les versions stables officielles. -* Contrairement au canal [Expérimental](/community/versioning-policy#experimental-channel), les Canaries React n'incluent que des fonctionnalités dont nous sommes raisonnablement sûrs qu'elles sont prêtes à être adoptées. Nous encourageons les frameworks à envisager d'incorporer en version fixe un Canary React. -* Nous annoncerons les ruptures de compatibilité ascendante et les nouvelles fonctionnalités sur notre blog dès qu'elles arrivent dans des livraisons Canary. -* **Comme toujours, React continue de respecter le versionnement sémantique pour chaque version du canal Stable.** +* Contrairement au canal [Expérimental](/community/versioning-policy#experimental-channel), les Canaries React n'incluent que des fonctionnalités dont nous sommes raisonnablement sûrs qu'elles sont prêtes à être adoptées. Nous encourageons les frameworks à envisager d'incorporer une Canary React en épinglant sa version. +* Nous annoncerons les ruptures de compatibilité ascendante et les nouvelles fonctionnalités sur notre blog dès qu'elles arriveront dans des livraisons Canary. +* **Comme toujours, React continue de respecter le versionnement sémantique pour chaque version publiée sur le canal Stable.** ## Comment les fonctionnalités de React sont-elles généralement développées ? {/*how-react-features-are-usually-developed*/} En général, une fonctionnalité React est passée à travers les mêmes étapes de développement : 1. Nous développons une version initiale et préfixons sont API par `experimental_` ou `unstable_`. La fonctionnalité n'est disponible que *via* le canal de livraison `experimental`. À ce stade, la fonctionnalité est susceptible de beaucoup évoluer. -2. Nous trouvons une équipe chez Meta motivée pour nous aider à tester cette fonctionnalité et nous faire des retours nourris dessus. Ça entraîne un premier lot de modifications. Au fur et à mesure que la fonctionnalité gagne en stabilité, nous collaborons avec davantage d'équipes chez Meta pour la mettre à l'épreuve. +2. Nous trouvons chez Meta une équipe motivée pour nous aider à tester cette fonctionnalité et nous faire des retours nourris dessus. Ça entraîne un premier lot de modifications. Au fur et à mesure que la fonctionnalité gagne en stabilité, nous collaborons avec davantage d'équipes chez Meta pour la mettre à l'épreuve. 3. Nous finissons par être confiants dans sa conception. Nous retirons alors le préfixe de ses noms d'API et la rendons disponible sur la branche par défaut `main`, utilisée par la plupart des produits de Meta. À ce stade, n'importe quelle équipe chez Meta peut utiliser cette fonctionnalité. 4. Alors que la confiance grandit, nous publions une RFC sur la nouvelle fonctionnalité. On sait à ce stade que la conception fonctionne pour un large éventail de cas, mais nous sommes encore susceptibles de faire des ajustements de dernière minute. -5. Lorsque nous sommes sur le point de faire une livraison *open source*, nous rédigeons la documentation de la fonctionnalité et la livrons enfin dans une version de React stable. +5. Lorsque nous sommes sur le point de faire une livraison *open source*, nous rédigeons la documentation de la fonctionnalité et la livrons enfin dans une version stable de React. -Cette stratégie fonctionne bien pour la plupart des fonctionnalités que nous avons livrées jusqu'ici. Cependant, il peut s'écouler un temps considérable entre le moment où une fonctionnalité est globalement prête à l'emploi (étape 3) et celle où elle est livrée en *open source* (étape 5). +Cette stratégie a bien fonctionné pour la plupart des fonctionnalités que nous avons livrées jusqu'ici. Cependant, il peut s'écouler un temps considérable entre le moment où une fonctionnalité est globalement prête à l'emploi (étape 3) et celui où elle est livrée en *open source* (étape 5). -**Nous aimerions offrir à la communauté React un moyen de suivre la même approchez que chez Meta, en adoptant individuellement de nouvelles fonctionnalités React plus tôt (au fil de leur mise à disposition), sans avoir à attendre la prochaine version officielle de React.** +**Nous aimerions offrir à la communauté React un moyen de suivre la même approche que chez Meta, en adoptant individuellement de nouvelles fonctionnalités React plus tôt (au fil de leur mise à disposition), sans avoir à attendre la prochaine version officielle de React.** -Comme toujours, toutes les fonctionnalités React arriveront à terme dans une version stable. +Comme toujours, toutes les fonctionnalités de React arriveront à terme dans une version stable. ## Ne peut-on pas juste faire plus de versions mineures ? {/*can-we-just-do-more-minor-releases*/} @@ -44,17 +44,17 @@ En général, nous *utilisons bien* des versions mineures pour introduire de nou Ce n'est toutefois pas toujours possible. Il arrive que de nouvelles fonctionnalités soient étroitement liées à *d'autres* nouvelles fonctionnalités qui ne sont pas tout à fait finies, et sur lesquelles nous itérons encore. Nous ne pouvons pas les livrer séparément parce que leurs implémentations sont imbriquées. Nous ne pouvons pas les versionner séparément parce qu'elles affectent les mêmes modules (par exemple `react` et `react-dom`). Et nous avons besoin de pouvoir continuer à itérer sur les parties qui ne sont pas encore prêtes sans publier une floppée de versions majeures, ce que le versionnement sémantique nous imposerait dans un tel cas. -Chez Meta, nous avons résolu ce problème en construisant React à partir de sa branche `main`, et en le recalant manuellement sur un commit précis chaque semaine. C'est aussi l'approche suivie depuis quelques années par les versions publiées de React Native. Chaque version *stable* de React Native est calée sur un commit précis de la branche `main` du dépôt React. Ça permet à React Native d'inclure des correctifs importants et d'adopter de façon incrémentale les nouvelles fonctionnalités React au niveau du framework sans être couplé au calendrier global de versions de React. +Chez Meta, nous avons résolu ce problème en construisant React à partir de sa branche `main`, et en le recalant manuellement sur un commit précis chaque semaine. C'est aussi l'approche suivie depuis quelques années par les versions publiées de React Native. Chaque version *stable* de React Native est calée sur un commit précis de la branche `main` du dépôt React. Ça permet à React Native d'inclure des correctifs importants et d'adopter de façon incrémentale les nouvelles fonctionnalités React au niveau du framework sans être contraint par le calendrier global de versions de React. -Nous aimerions rendre ce workflow disponible à d'autres frameworks et environnements choisis. Il permet par exemple à un framework *par-dessus* React d'inclure des modifications rompant la compatibilité ascendante de React *avant* que cette rupture n'apparaisse dans une version stable de React. C'est particulièrement utile parce que certaines ruptures de compatibilité n'affectent que les intégrations par ces frameworks. Ça permet au framework de sortir une telle évolution dans sa propre version mineure, sans casser son versionnement sémantique. +Nous aimerions rendre ce workflow disponible à d'autres frameworks et environnements choisis. Il permet par exemple à un framework *par-dessus* React d'inclure des modifications rompant la compatibilité ascendante de React *avant* que ces ruptures n'apparaissent dans une version stable de React. C'est particulièrement utile parce que certaines ruptures de compatibilité n'affectent que les intégrations par ces frameworks. Ça permet au framework de sortir une telle évolution dans sa propre version mineure, sans avoir à casser son propre versionnement sémantique. -Des versions régulières sur le canal Canary nous permettront d'avoir une boucle de retours plus étroite et de nous assurer que les nouvelles fonctionnalités font l'objet de tests exhaustifs par la communauté. Ce workflow ressemble davantage à la façon dont le TC39 (le comité de standardisation de JavaScript) [gère ses évolutions par stades numérotés](https://tc39.es/process-document/). Les nouvelles fonctionnalités de React sont susceptibles d'être disponibles dans des frameworks basés sur React avant d'apparaître dans une version stable de React, tout comme des nouvelles fonctionnalités de JavaScript apparaissent dans des navigateurs avant d'être officiellement ratifiées dans la spécification. +Des versions régulières sur le canal Canary nous permettront d'avoir une boucle de retours plus étroite et de nous assurer que les nouvelles fonctionnalités font l'objet de tests exhaustifs par la communauté. Ce workflow ressemble davantage à la façon dont le TC39 (le comité de standardisation de JavaScript) [gère ses évolutions par stades numérotés](https://tc39.es/process-document/). Les nouvelles fonctionnalités de React sont susceptibles d'être disponibles dans des frameworks basés sur React avant d'apparaître dans une version stable de React, tout comme des nouvelles fonctionnalités de JavaScript apparaissent dans des navigateurs avant d'être officiellement ratifiées dans la spécification du langage. ## Pourquoi ne pas plutôt utiliser les versions expérimentales ? {/*why-not-use-experimental-releases-instead*/} -Même si vous *pouvez* techniquement utiliser les [versions expérimentales](/community/versioning-policy#canary-channel), nous vous déconseillons de les utiliser en production car les API expérimentales peuvent subir des changements significatifs pendant leur phase de stabilisation (et sont même parfois carrément retirées). Même si les Canaries peuvent contenir des erreurs (comme pour toute version), nous avons l'intention désormais d'annoncer toute rupture importante de compatibilité dans les Canaries sur notre blog. Les Canaries sont ce qui se rapproche le plus du code que Meta utilise en interne, vous pouvez donc vous attendre à un bon niveau général de stabilité. En revanche, vous *aurez bien besoin* d'épingler (c'est-à-dire de vous caler sur) une version fixe et de manuellement scanner nos journaux de commits GitHub lorsque vous mettrez à jour la version épinglée. +Même si vous *pouvez* techniquement utiliser les [versions expérimentales](/community/versioning-policy#canary-channel), nous vous déconseillons de les utiliser en production car les API expérimentales peuvent subir des changements significatifs pendant leur phase de stabilisation (et sont même parfois carrément retirées). Même si les Canaries peuvent contenir des erreurs (comme pour toute version), nous avons l'intention désormais d'annoncer toute rupture importante de compatibilité dans les Canaries sur notre blog. Les Canaries sont ce qui se rapproche le plus du code que Meta utilise en interne, vous pouvez donc vous attendre à un bon niveau général de stabilité. En revanche, vous *aurez bien besoin* d'épingler (c'est-à-dire de vous caler sur) une version fixe et de parocurir manuellement nos journaux de commits GitHub lorsque vous mettrez à jour la version épinglée. -**Nous nous attendons à ce que la majorité des utilisateurs de React ne travaillant pas sur un environnement choisi (comme un framework) souhaitent continuer à utiliser plutôt les versions stables.** Ceci dit, si vous construisez un framework, vous voudrez peut-être envisager d'incorporer une version Canary de React épinglée sur un commit précis, et de la mettre à jour à votre rythme. L'avantage de cette approche, c'est qu'elle vous permet de livrer des fonctionnalités individuelles finalisées de React (et des correctifs) plus tôt à vos propres utilisateurs, et suivant votre propre calendrier de versions, tout comme React Native le fait depuis plusieurs années. L'inconvénient, c'est que vous endossez davantage de responsabilités en examinant quels commits React sont récupérés et en communiquant sur ces évolutions auprès de vos utilisateurs. +**Nous nous attendons à ce que la majorité des utilisateurs de React ne travaillant pas sur un environnement choisi (comme un framework) souhaitent continuer à plutôt utiliser les versions stables.** Ceci dit, si vous construisez un framework, vous voudrez peut-être envisager d'incorporer une version Canary de React épinglée sur un commit précis, et de la mettre à jour à votre rythme. L'avantage de cette approche, c'est qu'elle vous permet de livrer des fonctionnalités individuelles finalisées de React (et des correctifs) plus tôt à vos propres utilisateurs, et suivant votre propre calendrier de versions, tout comme React Native le fait depuis plusieurs années. L'inconvénient, c'est que vous endossez davantage de responsabilités en examinant quels commits React sont récupérés et en communiquant sur ces évolutions auprès de vos utilisateurs. Si vous êtes en charge d'un framework et souhaitez tenter cette approche, merci de nous contacter. @@ -62,23 +62,23 @@ Si vous êtes en charge d'un framework et souhaitez tenter cette approche, merci Les versions Canary représentent notre meilleure vision, à un instant donné, de ce qui arrivera dans la version stable suivante. -Historiquement nous n'annoncions les ruptures de compatibilité ascendante qu'à *la fin* du cycle de livraison (en sortant une version majeure). À présent que nous disposons d'un canal Canary officiel pour consommer React, nous pensons évoluer pour annoncer les ruptures de compatibilité et les nouveautés significatives *au fil de leur apparition* dans les Canaries. Si par exemple nous fusionnons une rupture de compatibilité qui apparaîtra dans un Canary, nous écrirons un billet à ce sujet sur le blog React, en incluant si besoin des *codemods* et des instructions de migration. À partir de là, si vous travaillez sur un e framework et sortez une version majeure qui met à jour sa version épinglée de React Canary pour inclure ces modifications, vous pourrez mettre un lien vers notre billet de blog dans vos notes de version. Enfin, lorsqu'une version majeure stable de React sera prête, nous y mettrons des liens vers les billets de blog déjà publiés, ce qui nous l'espérons aidera votre équipe à progresser plus vite. +Historiquement nous n'annoncions les ruptures de compatibilité ascendante qu'à *la fin* du cycle de livraison (en sortant une version majeure). À présent que nous disposons d'un canal Canary officiel pour consommer React, nous pensons annoncer les ruptures de compatibilité et les nouveautés significatives *au fil de leur apparition* dans les Canaries. Si par exemple nous fusionnons une rupture de compatibilité qui apparaîtra dans une Canary, nous écrirons un billet à ce sujet sur le blog React, en incluant si besoin des *codemods* et les instructions de migration appropriées. À partir de là, si vous travaillez sur un framework et sortez une version majeure qui met à jour sa version épinglée de React Canary pour inclure ces modifications, vous pourrez mettre un lien vers notre billet de blog dans vos notes de version. Enfin, lorsqu'une version majeure stable de React sera prête, nous y mettrons des liens vers les billets de blog déjà publiés, ce qui nous l'espérons aidera votre équipe à progresser plus vite. -Nous prévoyons de documenter les API au fil de leur apparition dans les Canaries — même si cs API ne sont pas encore disponibles par ailleurs. Less API qui ne sont disponibles que dans les Canaries seront identifiées par une note spécifique dans leur documentation. Ça inclura des API comme [`use`](https://github.com/reactjs/rfcs/pull/229) et d'autres (telles que `cache` et `createServerContext`) pour lesquelles nous publierons des RFC. +Nous prévoyons de documenter les API au fil de leur apparition dans les Canaries — même si ces API ne sont pas encore disponibles par ailleurs. Les API qui ne sont disponibles que dans les Canaries seront identifiées par une note spécifique dans leur documentation. Ça inclura des API comme [`use`](https://github.com/reactjs/rfcs/pull/229) et d'autres (telles que `cache` et `createServerContext`) pour lesquelles nous publierons des RFC. ## Les Canaries doivent être épinglés {/*canaries-must-be-pinned*/} -Si vous décidez d'adopter un workflow basé sur Canary pour votre appli ou votre framework, assurez-vous de toujours épingler la version *exacte* du Canary que vous utilisez. Dans la mesure où les Canaries sont des préversions, elles sont susceptibles d'inclure des ruptures de compatibilité. +Si vous décidez d'adopter un workflow basé sur Canary pour votre appli ou votre framework, assurez-vous de toujours épingler la version *exacte* de la Canary que vous utilisez. Dans la mesure où les Canaries sont des préversions, elles sont susceptibles d'inclure des ruptures de compatibilité. ## Exemple : React Server Components {/*example-react-server-components*/} -Comme nous l'avons [annoncé en mars](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), les conventions des React Server Components sont finalisées, et nous n'anticipons pas de ruptures majeures dans leur contrat d'API publique. En revanche, nous ne pouvons pas encore prendre en charge les React Server Components dans une version stable de React parce que nous travaillons encore sur plusieurs fonctionnalités qui leur sont étroitement liées mais qui ne concernent que les frameworks (telles que le [chargement de ressources](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) et nous attendons à des ruptures de ce côté-là. +Comme nous l'avons [annoncé en mars](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), les conventions des React Server Components sont finalisées, et nous n'anticipons pas de ruptures majeures dans leur contrat d'API publique. En revanche, nous ne pouvons pas encore prendre en charge les React Server Components dans une version stable de React parce que nous travaillons encore sur plusieurs fonctionnalités qui leur sont étroitement liées mais qui ne concernent que les frameworks (telles que le [chargement de ressources](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) et nous anticipons des ruptures de ce côté-là. -Ça signifie que les React Server Components sont prêts à être adoptés par les frameworks. Cependant, jusqu'à la prochaine version majeure de React, la seule manière pour un framework de les adopter sera d'utiliser une version Canary épinglée de React. (Pour éviter d'inclure deux copies de React dans les *bundles*, les frameworks qui optent pour cette approche devraitnt forcer une résolution des modules `react` et `react-dom` vers leur version Canary épinglée, et l'expliquer à leurs utilisateurs. C'est par exemple ce que fait le *App Router* de Next.js.) +Ça signifie que les React Server Components sont prêts à être adoptés par les frameworks. Cependant, jusqu'à la prochaine version majeure de React, la seule manière pour un framework de les adopter sera d'utiliser une version Canary épinglée de React. (Pour éviter d'inclure deux copies de React dans les *bundles*, les frameworks choisissant cette approche devraient forcer une résolution des modules `react` et `react-dom` vers leur version Canary épinglée, et l'expliquer à leurs utilisateurs. C'est par exemple ce que fait le *App Router* de Next.js.) ## Tester des bibliothèques avec les versions Stable et Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} -Nous ne nous attendons pas à ce que les équipes des bibliothèques tierces testent chaque version Canary, ce serait d'une difficulté prohibitive. En revanche, tout comme lorsque nous avions [introduit les canaux originaux de préversion de React il y a trois ans](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), nous encourageons les bibliothèques à exécuter leurs tests *à la fois* sur la dernière version stable, et sur la dernière version Canary. Si vous constatez un changement de comportement qui n'a fait l'objet d'aucune annonce, merci d'ouvrir un ticket sur le dépôt de Reat pour que nous puissions vous aider à diagnostiquer le problème. Nous estimons qu'une fois cette pratique largement répandue, elle réduira l'effort nécessaire à la mise à jour des bibliothèques pour les nouvelles versions majeures de React, dans la mesure où les régressions accidentelles seront découvertes au fil de leur apparition. +Nous ne nous attendons pas à ce que les équipes des bibliothèques tierces testent chaque version Canary, ce serait d'une difficulté prohibitive. En revanche, tout comme lorsque nous avions [introduit les canaux originaux de préversion de React il y a trois ans](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), nous encourageons les bibliothèques à exécuter leurs tests *aussi bien* sur la dernière version stable que sur la dernière version Canary. Si vous constatez un changement de comportement qui n'a fait l'objet d'aucune annonce, merci d'ouvrir un ticket sur le dépôt de React pour que nous vous aidions à diagnostiquer le problème. Nous estimons qu'une fois cette pratique largement répandue, elle réduira l'effort nécessaire à la mise à jour des bibliothèques pour les nouvelles versions majeures de React, dans la mesure où les régressions accidentelles seront découvertes au fil de l'eau. @@ -86,6 +86,6 @@ Nous ne nous attendons pas à ce que les équipes des bibliothèques tierces tes -## Les versions stables marchetn comme avant {/*stable-releases-work-like-before*/} +## Les versions stables marchent comme avant {/*stable-releases-work-like-before*/} Nous n'apportons aucun changement aux versions stables de React. diff --git a/src/content/blog/index.md b/src/content/blog/index.md index 5edd74493..1ece91c37 100644 --- a/src/content/blog/index.md +++ b/src/content/blog/index.md @@ -12,7 +12,7 @@ Ce blog est la source officielle des mises à jour par l'équipe React. Toute a -Traditionnellement, les nouveautés de React n'étaient d'abord disponibles qu'au sein de Meta, pour arriver plus tard dans les livraisons *open source*. Nous aimerions offrir à la communauté React un moyen d'adopter individuellement des fonctionnalités plus en amont, alors que leur conception est quasi finalisée —  un peu comme l'utilisation que Meta fait de React en interne. Nous présentons donc un nouveau canal de livraison officiel appelé Canary. Il permet à des environnements choisis tels que les frameworks de découpler leur adoption de fonctionnalités React individuelles du planning officiel de sortie de React. +Traditionnellement, les nouveautés de React n'étaient d'abord disponibles qu'au sein de Meta, pour arriver plus tard dans les livraisons *open source*. Nous aimerions offrir à la communauté React un moyen d'adopter individuellement des fonctionnalités plus en amont, alors que leur conception est quasi finalisée —  un peu comme l'utilisation que Meta fait de React en interne. Nous présentons donc un nouveau canal de livraison officiel appelé Canary. Il permet à des environnements choisis tels que les frameworks de découpler leur adoption de fonctionnalités React individuelles du calendrier officiel de sortie de React.