diff --git a/TRANSLATORS.md b/TRANSLATORS.md index 64e6b42e8..4793bf68f 100644 --- a/TRANSLATORS.md +++ b/TRANSLATORS.md @@ -130,6 +130,7 @@ Voici la liste par ordre alphabétique (prénom, nom). **🙏🏻 Mille mercis
  • Remerciements
  • Blog (accueil)
  • Blog : React Canaries
    • +
  • Blog : React Labs mars 2023
  • Avertissement : prop ARIA invalide
  • Avertissement : règles des Hooks
  • Avertissement : props à traitement spécial
    • diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index a6592fd3b..eb58a8140 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -1,14 +1,14 @@ --- -title: "React Labs: What We've Been Working On – March 2023" +title: "React Labs : ce sur quoi nous bossons – mars 2023" --- -March 22, 2023 by [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite) +Le 22 mars 2023 par [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage) et [Andrew Clark](https://twitter.com/acdlite). --- -In React Labs posts, we write about projects in active research and development. We've made significant progress on them since our [last update](https://react.dev/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022), and we'd like to share what we learned. +Dans les billets React Labs, nous vous parlons de nos projets de recherche et développement actifs. Depuis notre [dernier bulletin](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022), nous avons fait des progrès significatifs et nous aimerions partager ce que nous avons appris. @@ -16,87 +16,91 @@ In React Labs posts, we write about projects in active research and development. ## React Server Components {/*react-server-components*/} -React Server Components (or RSC) is a new application architecture designed by the React team. +Les React Server Components (ou RSC) sont une nouvelle architecture applicative conçue par l'équipe React. -We've first shared our research on RSC in an [introductory talk](/blog/2020/12/21/data-fetching-with-react-server-components) and an [RFC](https://github.com/reactjs/rfcs/pull/188). To recap them, we are introducing a new kind of component--Server Components--that run ahead of time and are excluded from your JavaScript bundle. Server Components can run during the build, letting you read from the filesystem or fetch static content. They can also run on the server, letting you access your data layer without having to build an API. You can pass data by props from Server Components to the interactive Client Components in the browser. +La première fois que nous avons parlé de nos recherches sur les RSC, c'était dans un [talk de présentation](/blog/2020/12/21/data-fetching-with-react-server-components) et *via* une [RFC](https://github.com/reactjs/rfcs/pull/188). En résumé, nous introduisons un nouveau type de composant — les Composants Serveur — qui sont exécutés en amont et exclus de votre *bundle* JavaScript. Les Composants Serveur peuvent être exécutés pendant le *build*, ce qui leur permet de lire le système de fichiers ou de charger du contenu statique. Ils peuvent aussi être exécutés côté serveur, ce qui permet d'accéder à votre couche de données sans avoir besoin d'une API. Vous pouvez passer des données *via* les props entre les Composants Serveur et les Composants Client interactifs dans le navigateur. -RSC combines the simple "request/response" mental model of server-centric Multi-Page Apps with the seamless interactivity of client-centric Single-Page Apps, giving you the best of both worlds. +RSC combine la simplicité du modèle mental requête/réponse, courant dans les applis multi-page *(MPA pour Multi-Page Apps, NdT)* centrées sur le serveur, avec l'interactivité transparente des applis mono-page *(SPA pour Single-Page Apps, NdT)* centrées sur le client, ce qui vous donne le meilleur des deux mondes. -Since our last update, we have merged the [React Server Components RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) to ratify the proposal. We resolved outstanding issues with the [React Server Module Conventions](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) proposal, and reached consensus with our partners to go with the `"use client"` convention. These documents also act as specification for what an RSC-compatible implementation should support. +Depuis notre dernier bulletin, nous avons intégré la [RFC des React Server Components](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) afin de ratifier cette proposition. Nous avons résolu les problèmes en suspens de la proposition de [conventions de modules React serveur](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md), et atteint un consensus avec nos partenaires concernant la convention `"use client"`. Ces documents jouent aussi le rôle d'une spécification à respecter par les implémentations compatibles de RSC. -The biggest change is that we introduced [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) as the primary way to do data fetching from Server Components. We also plan to support data loading from the client by introducing a new hook called `use` that unwraps Promises. Although we can't support `async / await` in arbitrary components in client-only apps, we plan to add support for it when you structure your client-only app similar to how RSC apps are structured. +Le plus gros changement survenu tient à l'introduction de [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) comme mécanisme principal de chargement de données dans les Composants Serveur. Nous prévoyons aussi de permettre le chargement de données depuis les clients au moyen d'un nouveau Hook appelé `use` qui repose en interne sur des promesses (`Promise`). Même si nous ne pouvons pas autoriser `async / await` au sein de n'importe quel composant d'une appli 100% côté client, nous prévoyons de le prendre en charge lorsque la structure de votre appli 100% côté client est similaire à celle d'applis basées sur les RSC. -Now that we have data fetching pretty well sorted, we're exploring the other direction: sending data from the client to the server, so that you can execute database mutations and implement forms. We're doing this by letting you pass Server Action functions across the server/client boundary, which the client can then call, providing seamless RPC. Server Actions also give you progressively enhanced forms before JavaScript loads. +À présent que nous avons suffisamment débroussaillé le sujet du chargement de données, nous explorons l'autre direction : l'envoi de données du client vers le serveur, afin que vous puissiez exécuter des modifications de base de données et implémenter des formulaires. Nous vous permettons pour cela de passer des fonctions d'Actions Serveur à travers la frontière serveur/client, fonctions que le code client peut alors appeler, ce qui fournit une sorte de RPC *(Remote Procedure Call, NdT)* transparent. Les Actions Serveur vous permettent aussi de proposer des formulaires en amélioration progressive pendant le chargement de JavaScript. -React Server Components has shipped in [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). This showcases a deep integration of a router that really buys into RSC as a primitive, but it's not the only way to build a RSC-compatible router and framework. There's a clear separation for features provided by the RSC spec and implementation. React Server Components is meant as a spec for components that work across compatible React frameworks. +Une implémentation des React Server Components a été livrée au travers de [l'*App Router* de Next.js](/learn/start-a-new-react-project#nextjs-app-router). +C'est un bon exemple d'une intégration profonde d'un routeur qui traite les RSC comme une primitive importante, mais ce n'est pas la seule façon de construire un routeur ou un framework compatibles RSC. Il existe une distinction claire entre les fonctionnalités que permet la spec des RSC, et leur implémentation. Les React Server Components sont pensés comme une spec de composants qui puisse être prise en charge par n'importe quel framework React compatible. -We generally recommend using an existing framework, but if you need to build your own custom framework, it is possible. Building your own RSC-compatible framework is not as easy as we'd like it to be, mainly due to the deep bundler integration needed. The current generation of bundlers are great for use on the client, but they weren't designed with first-class support for splitting a single module graph between the server and the client. This is why we're now partnering directly with bundler developers to get the primitives for RSC built-in. +Nous vous conseillons généralement d'utiliser un framework existant, mais si vous devez construire votre propre framework, c'est possible. Créer votre propre framework compatible RSC n'est pas aussi aisé que nous le voudrions, principalement en raison d'une exigence d'intégration profonde avec votre *bundler*. La génération actuelle de *bundlers* est super pour un usage centré sur le client, mais ils n'ont pas été conçus avec une prise en charge de premier plan pour la découpe d'un graphe de modules selon un axe client / serveur. C'est pourquoi nous avons un partenariat en cours avec les développeurs de *bundlers* afin d'intégrer dans leurs outils les primitives nécessaires à RSC. -## Asset Loading {/*asset-loading*/} +## Chargement de ressources {/*asset-loading*/} -[Suspense](/reference/react/Suspense) lets you specify what to display on the screen while the data or code for your components is still being loaded. This lets your users progressively see more content while the page is loading as well as during the router navigations that load more data and code. However, from the user's perspective, data loading and rendering do not tell the whole story when considering whether new content is ready. By default, browsers load stylesheets, fonts, and images independently, which can lead to UI jumps and consecutive layout shifts. +[Suspense](/reference/react/Suspense) vous permet de spécifier quoi afficher à l'écran pendant que les données ou le code de vos composants sont encore en train de charger. Ça permet à vos utilisateurs de voir progressivement davantage de contenu au cours du chargement de la page, ainsi que pendant les navigations de routage qui chargent davantage de données ou de code. Ceci dit, du point de vue de l'utilisateur, le chargement de données et le rendu ne suffisent pas à pleinement représenter la disponibilité de nouveau contenu. Par défaut, les navigateurs chargent indépendamment les feuilles de style, les fontes et les images, ce qui peut entraîner des décalages subits et désagréables de l'affichage *(layout shifts, NdT)*. -We're working to fully integrate Suspense with the loading lifecycle of stylesheets, fonts, and images, so that React takes them into account to determine whether the content is ready to be displayed. Without any change to the way you author your React components, updates will behave in a more coherent and pleasing manner. As an optimization, we will also provide a manual way to preload assets like fonts directly from components. +Nous travaillons à intégrer pleinement Suspense avec le cycle de vie du chargement des feuilles de styles, fontes et images, afin que React puisse les prendre en compte pour déterminer si le contenu est prêt à être affiché. Sans rien changer à votre façon d'écrire vos composants React, ces mises à jour produiront un comportement plus cohérent et agréable. À titre d'optimisation, nous fournirons également un mécanisme manuel de préchargement de ressources telles que les fontes, directement depuis vos composants. -We are currently implementing these features and will have more to share soon. +Nous travaillons actuellement sur ces fonctionnalités et nous devrions pouvoir vous en montrer prochainement davantage à ce sujet. -## Document Metadata {/*document-metadata*/} +## Métadonnées des documents {/*document-metadata*/} -Different pages and screens in your app may have different metadata like the `` tag, description, and other `<meta>` tags specific to this screen. From the maintenance perspective, it's more scalable to keep this information close to the React component for that page or screen. However, the HTML tags for this metadata need to be in the document `<head>` which is typically rendered in a component at the very root of your app. +Selon la page ou l'écran de votre appli, vous aurez besoin de métadonnées distinctes telles que la balise `<title>`, la description et d'autres balises `<meta>` spécifiques à un écran donné. En termes de maintenance, il est préférable de conserver cette information à proximité du composant React pour la page ou l'écran. Seulement voilà, les balises HTML pour ces métadonnées doivent être dans le `<head>` du document, qui figure généralement à la racine de votre appli. -Today, people solve this problem with one of the two techniques. +Pour le moment, les gens utilisent une des deux techniques suivantes pour résoudre ce problème. -One technique is to render a special third-party component that moves `<title>`, `<meta>`, and other tags inside it into the document `<head>`. This works for major browsers but there are many clients which do not run client-side JavaScript, such as Open Graph parsers, and so this technique is not universally suitable. +La première consiste à faire le rendu d'un composant spécial tierce-partie qui déplace les `<title>`, `<meta>` et autres éléments qu'il contient dans le `<head>` du document. Ça fonctionne pour tous les principaux navigateurs mais de nombreux clients n'exécutent pas JavaScript, comme par exemple les *parsers* Open Graph, de sorte que cette technique n'est pas toujours adaptée. -Another technique is to server-render the page in two parts. First, the main content is rendered and all such tags are collected. Then, the `<head>` is rendered with these tags. Finally, the `<head>` and the main content are sent to the browser. This approach works, but it prevents you from taking advantage of the [React 18's Streaming Server Renderer](/reference/react-dom/server/renderToReadableStream) because you'd have to wait for all content to render before sending the `<head>`. +L'autre technique consiste à faire un rendu côté serveur en deux passes de la page. On commence par faire le rendu du contenu principal et y collecter toutes les balises concernées. Ensuite, on fait le rendu du `<head>` avec ces balises. Pour finir, tant le `<head>` que le contenu principal sont envoyés au navigateur. Cette approche fonctionne, mais elle vous empêche de tirer parti du [rendu serveur *streamé* de React 18](/reference/react-dom/server/renderToReadableStream), puisqu'il vous faut attendre que tout le contenu ait fini son rendu avant d'envoyer le `<head>`. -This is why we're adding built-in support for rendering `<title>`, `<meta>`, and metadata `<link>` tags anywhere in your component tree out of the box. It would work the same way in all environments, including fully client-side code, SSR, and in the future, RSC. We will share more details about this soon. +C'est pourquoi nous ajoutons une prise en charge native du rendu des balises de métadonnées `<title>`, `<meta>` et `<link>` partout dans votre arborescence de composants. Elle fonctionnerait de façon identique dans tous les environnements, y compris du code 100% côté client, du SSR, et à l'avenir les RSC. Nous vous en dirons davantage bientôt. -## React Optimizing Compiler {/*react-optimizing-compiler*/} +## Compilateur optimisant pour React {/*react-optimizing-compiler*/} -Since our previous update we've been actively iterating on the design of [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), an optimizing compiler for React. We've previously talked about it as an "auto-memoizing compiler", and that is true in some sense. But building the compiler has helped us understand React's programming model even more deeply. A better way to understand React Forget is as an automatic *reactivity* compiler. +Depuis notre dernier bulletin nous avons beaucoup affiné la conception de [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), un compilateur optimisant pour React. Nous en avons parlé comme d'un « compilateur auto-mémoïsant », et c'est vrai dans un sens. Mais construire ce compilateur nous a aidés à comprendre plus en profondeur le modèle de programmation de React. Il serait en réalité plus juste de décrire React Forget comme un compilateur de *réactivité* automatique. -The core idea of React is that developers define their UI as a function of the current state. You work with plain JavaScript values — numbers, strings, arrays, objects — and use standard JavaScript idioms — if/else, for, etc — to describe your component logic. The mental model is that React will re-render whenever the application state changes. We believe this simple mental model and keeping close to JavaScript semantics is an important principle in React's programming model. +L'idée maîtresse de React, c'est que les développeurs définissent leur UI comme une fonction de l'état courant. Vous travaillez avec des valeurs JavaScript brutes — des nombres, des chaînes de caractères, des tableaux, des objets — et vous utilisez des idiômes JavaScript standard — `if`/`else`, `for`, etc. — pour décrire la logique de vos composants. Le modèle mental veut que React refasse un rendu dès que l'état de votre application change. Nous aimons ce modèle mental simple, et rester au plus près de la sémantique de JavaScript fait partie intégrante du modèle de programmation de React. -The catch is that React can sometimes be *too* reactive: it can re-render too much. For example, in JavaScript we don't have cheap ways to compare if two objects or arrays are equivalent (having the same keys and values), so creating a new object or array on each render may cause React to do more work than it strictly needs to. This means developers have to explicitly memoize components so as to not over-react to changes. +Le souci, c'est que React peut parfois être *trop* réactif : il fait parfois trop de rendus. Par exemple, en JavaScript nous ne disposons pas d'un mécanisme léger pour déterminer si deux objets ou tableaux sont équivalents (s'ils ont les mêmes clés et valeurs), ce qui fait que créer un nouvel objet ou tableau à chaque rendu peut amener React a faire beaucoup plus de travail que strictement nécessaire. Ça implique que les développeurs doivent explicitement mémoïser des composants pour ne pas sur-réagir aux modifications. -Our goal with React Forget is to ensure that React apps have just the right amount of reactivity by default: that apps re-render only when state values *meaningfully* change. From an implementation perspective this means automatically memoizing, but we believe that the reactivity framing is a better way to understand React and Forget. One way to think about this is that React currently re-renders when object identity changes. With Forget, React re-renders when the semantic value changes — but without incurring the runtime cost of deep comparisons. +Notre objectif avec React Forget, c'est de garantir que les applis React ont juste assez de réactivité par défaut : que ces applis ne refont un rendu que lorsque l'état change de façon *signifiante*. Du point de vue de l'implémentation, ça implique une mémoïsation automatique, mais nous pensons qu'il est plus utile, pour comprendre React et Forget, d'y penser en termes de réactivité. Aujourd'hui, React refait un rendu quand l'identité d'un objet change. Avec Forget, React ne referait un rendu que si la valeur sémantique change — sans pour autant payer le prix d'une comparaison profonde. -In terms of concrete progress, since our last update we have substantially iterated on the design of the compiler to align with this automatic reactivity approach and to incorporate feedback from using the compiler internally. After some significant refactors to the compiler starting late last year, we've now begun using the compiler in production in limited areas at Meta. We plan to open-source it once we've proved it in production. +Pour ce qui est de nos progrès concrets, depuis notre dernier bulletin nous avons fortement itéré sur la conception du compilateur afin de l'aligner sur cette approche de réactivité automatique et d'incorporer les retours issus de l'utilisation interne de ce compilateur. Après d'importantes refontes du compilateur qui ont démarré sur la fin de l'année dernière, nous avons commencé à l'utiliser en production sur des périmètres limités chez Meta. Nous prévoyons de publier le code source lorsque nous aurons prouvé la valeur ajoutée du compilateur en production. -Finally, a lot of people have expressed interest in how the compiler works. We're looking forward to sharing a lot more details when we prove the compiler and open-source it. But there are a few bits we can share now: +Pour finir, vous êtes nombreux à avoir exprimé un intérêt pour le fonctionnement interne du compilateur. Nous avons hâte de partager beaucoup plus de détails lorsque nous l'aurons validé et *open-sourcé*. Voici quelques éléments que nous pouvons d'ores et déjà vous donner : -The core of the compiler is almost completely decoupled from Babel, and the core compiler API is (roughly) old AST in, new AST out (while retaining source location data). Under the hood we use a custom code representation and transformation pipeline in order to do low-level semantic analysis. However, the primary public interface to the compiler will be via Babel and other build system plugins. For ease of testing we currently have a Babel plugin which is a very thin wrapper that calls the compiler to generate a new version of each function and swap it in. -As we refactored the compiler over the last few months, we wanted to focus on refining the core compilation model to ensure we could handle complexities such as conditionals, loops, reassignment, and mutation. However, JavaScript has a lot of ways to express each of those features: if/else, ternaries, for, for-in, for-of, etc. Trying to support the full language up-front would have delayed the point where we could validate the core model. Instead, we started with a small but representative subset of the language: let/const, if/else, for loops, objects, arrays, primitives, function calls, and a few other features. As we gained confidence in the core model and refined our internal abstractions, we expanded the supported language subset. We're also explicit about syntax we don't yet support, logging diagnostics and skipping compilation for unsupported input. We have utilities to try the compiler on Meta's codebases and see what unsupported features are most common so we can prioritize those next. We'll continue incrementally expanding towards supporting the whole language. +Le noyau du compilateur est presque entièrement découplé de Babel, et l'API noyau du compilateur se résume grossièrement à un AST de départ en entrée, un AST remanié en sortie (tout en préservant les informations d'emplacement source). Sous le capot, nous utilisons un circuit sur-mesure de représentation et de transformation du code source afin de faire une analyse sémantique de bas niveau. Ceci dit, l'interface publique principale du compilateur passera par Babel et d'autres plugins pour les systèmes de *build*. Afin de faciliter nos tests nous avons actuellement un plugin Babel qui est en fait une surcouche très fine appelant le compilateur pour générer une nouvelle version de chaque fonction et l'utiliser en remplacement. -Making plain JavaScript in React components reactive requires a compiler with a deep understanding of semantics so that it can understand exactly what the code is doing. By taking this approach, we're creating a system for reactivity within JavaScript that lets you write product code of any complexity with the full expressivity of the language, instead of being limited to a domain specific language. +Lors des refontes du compilateur de ces derniers mois, nous nous sommes concentrés sur l'affinage du modèle noyau de compilation pour garantir que nous pouvions gérer des complexités telles que les conditionnels, les boucles, la réaffectation et les mutations. Ceci dit, JavaScript offre de nombreuses manières d'exprimer chacun de ces points : `if`/`else`, les ternaires, `for`, `for-in`, `for-of`, etc. Si nous avions voulu prendre en charge l'intégralité du langage d'entrée de jeu, nous aurions trop retardé le point de validation du modèle noyau. Nous avons choisi de plutôt commencer avec un sous-ensemble représentatif du language : `let`/`const`, `if`/`else`, les boucles `for`, les objets, les tableaux, les primitives, les appels de fonctions et quelques autres fonctionnalités. Au fur et à mesure que nous gagnions en confiance dans notre modèle noyau et que nous en affinions les abstractions internes, nous avons étendu le sous-ensemble pris en charge. Nous indiquons de façon explicite les parties de la syntaxe que nous ne prenons pas encore en charge, en maintenant des journaux de diagnostic et en sautant la compilation des sources non prises en charge. Nous avons des utilitaires pour essayer le compilateur sur les bases de code de Meta et voir quels aspects non encore pris en charge sont les plus couramment utilisés, pour prioriser les évolutions à venir. Nous allons continuer à étendre progressivement tout ça jusqu'à prendre en charge l'intégralité du langage. -## Offscreen Rendering {/*offscreen-rendering*/} -Offscreen rendering is an upcoming capability in React for rendering screens in the background without additional performance overhead. You can think of it as a version of the [`content-visiblity` CSS property](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) that works not only for DOM elements but React components, too. During our research, we've discovered a variety of use cases: +Pour permettre à du code JavaScript classique d'être réactif dans des composants React, il faut que le compilateur ait une compréhension profonde de sa sémantique pour déterminer précisément ce que fait ce code. En adoptant cette approche, nous avons créé un système de réactivité en JavaScript qui vous permet d'écrire du code métier de quelque complexité que ce soit, en bénéficiant de la pleine expressivité du langage, plutôt que de vous limiter à un langage taillé sur-mesure. -- A router can prerender screens in the background so that when a user navigates to them, they're instantly available. -- A tab switching component can preserve the state of hidden tabs, so the user can switch between them without losing their progress. -- A virtualized list component can prerender additional rows above and below the visible window. -- When opening a modal or popup, the rest of the app can be put into "background" mode so that events and updates are disabled for everything except the modal. +## Rendu hors-écran {/*offscreen-rendering*/} -Most React developers will not interact with React's offscreen APIs directly. Instead, offscreen rendering will be integrated into things like routers and UI libraries, and then developers who use those libraries will automatically benefit without additional work. +Le rendu hors-écran *(offscreen rendering, NdT)* désigne la possibilité prochaine pour React de calculer les rendus de vos écrans en arrière-plan, sans nuire aux performances. Vous pouvez y penser comme à une variation de la [propriété CSS `content-visiblity`](https://developer.mozilla.org/fr/docs/Web/CSS/content-visibility), qui ne fonctionnerait pas seulement pour les éléments du DOM mais aussi pour les composants React. Au fil de nos recherches, nous avons découvert plusieurs scénarios d'utilisation : -The idea is that you should be able to render any React tree offscreen without changing the way you write your components. When a component is rendered offscreen, it does not actually *mount* until the component becomes visible — its effects are not fired. For example, if a component uses `useEffect` to log analytics when it appears for the first time, prerendering won't mess up the accuracy of those analytics. Similarly, when a component goes offscreen, its effects are unmounted, too. A key feature of offscreen rendering is that you can toggle the visibility of a component without losing its state. +- Un routeur pourrait précalculer le rendu d'écrans en arrière-plan pour que lorsque l'utilisateur navigue vers l'un d'eux, il soit immédiatement disponible. +- Un composant d'onglets pourrait préserver l'état d'onglets masqués, pour que lorsque l'utilisateur rebascule dessus, il ne perde pas sa progression. +- Un composant de liste virtualisée pourrait précalculer le rendu de lignes supplémentaires en amont ou en aval de la zone visible. +- Lors de l'ouverture d'une boîte de dialogue modale ou d'une zone surgissante, le reste de l'appli pourrait « passer en arrière-plan » pour que ses événements et mises à jour soient désactivées pour tout ce qui ne concerne pas la zone mise en avant. -Since our last update, we've tested an experimental version of prerendering internally at Meta in our React Native apps on Android and iOS, with positive performance results. We've also improved how offscreen rendering works with Suspense — suspending inside an offscreen tree will not trigger Suspense fallbacks. Our remaining work involves finalizing the primitives that are exposed to library developers. We expect to publish an RFC later this year, alongside an experimental API for testing and feedback. +La plupart des développeurs React n'interagiront pas directement avec les API de gestion hors-écran de React. Le rendu hors-écran sera plutôt intégré dans des choses comme les bibliothèques de routage ou d'UI, et les développeurs qui utilisent ces bibliothèques en bénéficieront automatiquement, sans travail supplémentaire. -## Transition Tracing {/*transition-tracing*/} +L'idée, c'est que vous devriez pouvoir faire le rendu d'un arbre React hors-écran sans changer la façon dont vous écrivez vos composants. Lorsqu'un composant fait son rendu hors-écran, il n'est pas réellement *monté* jusqu'à ce qu'il devienne visible — ses Effets ne sont pas déclenchés. Si par exemple un composant utilise `useEffect` pour tenir des journaux analytiques lorsqu'il apparaît pour la première fois, le prérendu ne nuira pas à la justesse de ces données analytiques. Dans le même esprit, lorsqu'un composant passe hors-écran, ses effets sont démontés. Un aspect clé du rendu hors-écran veut que vous puissiez basculer la visibilité d'un composant sans perdre son état. -The Transition Tracing API lets you detect when [React Transitions](/reference/react/useTransition) become slower and investigate why they may be slow. Following our last update, we have completed the initial design of the API and published an [RFC](https://github.com/reactjs/rfcs/pull/238). The basic capabilities have also been implemented. The project is currently on hold. We welcome feedback on the RFC and look forward to resuming its development to provide a better performance measurement tool for React. This will be particularly useful with routers built on top of React Transitions, like the [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). +Depuis notre dernier bulletin, nous avons testé une version expérimentale du prérendu en interne chez Meta dans nos applis React Native sur Android et iOS, avec des résultats de performance encourageants. Nous avons aussi amélioré la collaboration du rendu hors-écran avec Suspense — suspendre au sein d'un arbre hors-écran ne déclenchera pas les rendus de secours de Suspense. Il nous reste à finaliser les primitives qui seront exposées aux développeurs de bibliothèques. Nous prévoyons de publier une RFC plus tard cette année, accompagnée d'une API expérimentale pour vos tests et retours d'expérience. -* * * -In addition to this update, our team has made recent guest appearances on community podcasts and livestreams to speak more on our work and answer questions. +## Pistage des transitions {/*transition-tracing*/} -* [Dan Abramov](https://twitter.com/dan_abramov) and [Joe Savona](https://twitter.com/en_JS) were interviewed by [Kent C. Dodds on his YouTube channel](https://www.youtube.com/watch?v=h7tur48JSaw), where they discussed concerns around React Server Components. -* [Dan Abramov](https://twitter.com/dan_abramov) and [Joe Savona](https://twitter.com/en_JS) were guests on the [JSParty podcast](https://jsparty.fm/267) and shared their thoughts about the future of React. +L'API de pistage des transitions vous permet de détecter que des [transitions React](/reference/react/useTransition) ralentissent, et d'enquêter sur les causes du ralentissement. Depuis notre dernier bulletin, nous avons terminé la conception initiale de l'API et publié une [RFC](https://github.com/reactjs/rfcs/pull/238). Les capacités de base ont été implémentées. Le projet est actuellement en suspens. Nous sommes à l'écoute de vos retours sur la RFC et espérons reprendre le développement pour fournir de meilleurs outils de mesure de la performance pour React. Ça sera particulièrement utile pour les routeurs basés sur les transitions React, tels que [l'*App Router* de Next.js](/learn/start-a-new-react-project#nextjs-app-router). -Thanks to [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), and [Sophie Alpert](https://twitter.com/sophiebits) for reviewing this post. +--- + +En complément de ce bulletin, notre équipe est récemment apparue dans des podcasts communautaires et des *livestreams* pour parler de notre travail et répondre à vos questions. + +* [Dan Abramov](https://twitter.com/dan_abramov) et [Joe Savona](https://twitter.com/en_JS) étaient interviewés par [Kent C. Dodds sur sa chaîne YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), pour parler de leurs préoccupations sur les React Server Components. +* [Dan Abramov](https://twitter.com/dan_abramov) et [Joe Savona](https://twitter.com/en_JS) étaient les invités du [podcast JSParty](https://jsparty.fm/267) pour parler de leurd visions respectives de l'avenir de React. + +Merci à [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster) et [Sophie Alpert](https://twitter.com/sophiebits) pour leurs relectures de ce billet. -Thanks for reading, and see you in the next update! +Merci de nous avoir lus, et rendez-vous dans notre prochain bulletin ! diff --git a/src/content/blog/index.md b/src/content/blog/index.md index 1ece91c37..32035e24a 100644 --- a/src/content/blog/index.md +++ b/src/content/blog/index.md @@ -16,9 +16,9 @@ Traditionnellement, les nouveautés de React n'étaient d'abord disponibles qu'a </BlogCard> -<BlogCard title="React Labs: What We've Been Working On – March 2023" date="March 22, 2023" url="/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023"> +<BlogCard title="React Labs : ce sur quoi nous bossons – mars 2023" date="22 mars 2023" url="/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023"> -In React Labs posts, we write about projects in active research and development. Since our last update, we've made significant progress on React Server Components, Asset Loading, Optimizing Compiler, Offscreen Rendering, and Transition Tracing, and we'd like to share what we learned. +Dans les billets React Labs, nous vous parlons de nos projets de recherche et développement actifs. Depuis notre dernier bulletin, nous avons fait des progrès significatifs sur les React Server Components, le chargement de ressources, un compilateur optimisant, le rendu hors-écran et le pistage des transsitions, et nous aimerions partager ce que nous avons appris. </BlogCard> diff --git a/src/sidebarBlog.json b/src/sidebarBlog.json index af8824f60..5a87f4161 100644 --- a/src/sidebarBlog.json +++ b/src/sidebarBlog.json @@ -19,8 +19,8 @@ "path": "/blog/2023/05/03/react-canaries" }, { - "title": "React Labs: What We've Been Working On – March 2023", - "titleForHomepage": "React Labs: March 2023", + "title": "React Labs : ce sur quoi nous bossons – mars 2023", + "titleForHomepage": "React Labs : mars 2023", "icon": "labs", "date": "22 mars 2023", "path": "/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023"