From 93cab8731c0a008ffe94bb3261360672a87b2808 Mon Sep 17 00:00:00 2001 From: Laura Date: Wed, 29 Jan 2020 23:13:35 -0500 Subject: [PATCH 1/2] :globe_with_meridians: Translation blog post 2017-09-08 --- .../2017-09-08-dom-attributes-in-react-16.md | 120 +++++++++--------- 1 file changed, 60 insertions(+), 60 deletions(-) diff --git a/content/blog/2017-09-08-dom-attributes-in-react-16.md b/content/blog/2017-09-08-dom-attributes-in-react-16.md index 31c66e53e..fe8e77fc3 100644 --- a/content/blog/2017-09-08-dom-attributes-in-react-16.md +++ b/content/blog/2017-09-08-dom-attributes-in-react-16.md @@ -1,38 +1,38 @@ --- -title: "DOM Attributes in React 16" +title: "Les attributs du DOM dans React 16" author: [gaearon] --- -In the past, React used to ignore unknown DOM attributes. If you wrote JSX with an attribute that React doesn't recognize, React would just skip it. For example, this: +Dans le passé, React ignorait les attributs DOM inconnus. Si vous écriviez du JSX avec un attribut que React ne reconnaissait pas, React le sautait tout simplement. Par exemple, ceci: ```js -// Your code: -
+// Votre code: +
``` -would render an empty div to the DOM with React 15: +rendrait une div vide dans le DOM avec React 15: ```js -// React 15 output: +// rendu de React 15:
``` -In React 16, we are making a change. Now, any unknown attributes will end up in the DOM: +Dans React 16, nous apportons un changement. Maintenant, tous les attributs inconnus se retrouveront dans le DOM: ```js -// React 16 output: -
+// rendu de React 16: +
``` -## Why Are We Changing This? {#why-are-we-changing-this} +## Pourquoi changeons-nous cela? {#pourquoi-changeons-nous-cela} -React has always provided a JavaScript-centric API to the DOM. Since React components often take both custom and DOM-related props, it makes sense for React to use the `camelCase` convention just like the DOM APIs: +React a toujours fourni une API Javascript centrée sur le DOM. Étant donné que les composants React prennent souvent à la fois des propriétés personnalisées et relative au DOM, il est logique que React utilise la convention `camelCase` tout comme les API DOM: ```js
``` -This has not changed. However, the way we enforced it in the past forced us to maintain a whitelist of all valid React DOM attributes in the bundle: +Cela n'a pas changé. Cependant, la façon dont nous l'avons appliqué dans le passé nous a obligés à maintenir une liste blanche de tous les attributs DOM React valides dans le paquet: ```js // ... @@ -43,127 +43,127 @@ title: 'title', // ... ``` -This had two downsides: +Cela avait deux inconvénients: -* You could not [pass a custom attribute](https://github.com/facebook/react/issues/140). This is useful for supplying browser-specific non-standard attributes, trying new DOM APIs, and integrating with opinionated third-party libraries. +* Vous ne pouviez pas [passer un attribut personnalisé](https://github.com/facebook/react/issues/140). Cela est utile pour fournir des attributs non standard spécifiques au navigateur, essayer de nouvelles API DOM et s'intégrer à des bibliothèques tierces avisées. -* The attribute list kept growing over time, but most React canonical attribute names are already valid in the DOM. Removing most of the whitelist helped us reduce the bundle size a little bit. +* La liste d'attributs n'a cessé de croître au fil du temps, mais la plupart des noms d'attributs canoniques React sont déjà valides dans le DOM. La suppression de la majorité de liste blanche nous a aidé à diminuer un peu la taille du paquet. -With the new approach, both of these problems are solved. With React 16, you can now pass custom attributes to all HTML and SVG elements, and React doesn't have to include the whole attribute whitelist in the production version. +Avec la nouvelle approche, ces deux problèmes sont résolus. Avec React 16, vous pouvez désormais transmettre des attributs personnalisés à tous les éléments HTML et SVG, et React n'a pas à inclure de liste blanche d'attributs dans sa version de production. -**Note that you should still use the canonical React naming for known attributes:** +** Notez que vous devez toujours utiliser la dénomination canonique React pour les attributs connus: ** ```js -// Yes, please +// Oui, s'il vous plaît
-// Warning: Invalid DOM property `tabindex`. Did you mean `tabIndex`? +// Attention: propriété du DOM invalide `tabindex`. Vous voulez certainement dire `tabIndex`?
``` -In other words, the way you use DOM components in React hasn't changed, but now you have some new capabilities. +En d'autres termes, la façon dont vous utilisez les composants du DOM dans React n'a pas changé, mais vous disposez désormais de nouvelles fonctionnalités. -## Should I Keep Data in Custom Attributes? {#should-i-keep-data-in-custom-attributes} +## Dois-je conserver les données dans des attributs personnalisés ? {#dois-je-conserver-les-donnees-dans-des-attributs-personnalises} -No. We don't encourage you to keep data in DOM attributes. Even if you have to, `data-` attributes are probably a better approach, but in most cases data should be kept in React component state or external stores. +Non. Nous ne vous encourageons pas à conserver les données dans les attributs DOM. Même si vous le devez, les attributs `data-` sont probablement une meilleure approche, mais dans la plupart des cas, les données doivent être conservées dans l'état du composant React ou dans des collections externes. -However, the new feature is handy if you need to use a non-standard or a new DOM attribute, or if you need to integrate with a third-party library that relies on such attributes. +Cependant, la nouvelle fonctionnalité est pratique si vous devez utiliser un attribut DOM non standard ou nouveau, ou si vous devez intégrer une bibliothèque tierce qui s'appuie sur de tels attributs. -## Data and ARIA Attributes {#data-and-aria-attributes} +## Attributs Data et ARIA {#Attributs-data-et-aria} -Just like before, React lets you pass `data-` and `aria-` attributes freely: +Comme auparavant, React vous permet de passer librement les attributs `data-` et `aria-`: ```js
-