{"body":"* Blog post: DOM Attributes in React 16\r\n\r\n* Testing the RC","patch":"diff --git a\/docs\/_posts\/2017-09-08-dom-attributes-in-react-16.md b\/docs\/_posts\/2017-09-08-dom-attributes-in-react-16.md\nnew file mode 100644\nindex 0000000000..fba64ecc85\n--- \/dev\/null\n+++ b\/docs\/_posts\/2017-09-08-dom-attributes-in-react-16.md\n@@ -0,0 +1,187 @@\n+---\n+title: \"DOM Attributes in React 16\"\n+author: gaearon\n+---\n+\n+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:\n+\n+```js\n+\/\/ Your code:\n+

\n+```\n+\n+would render an empty div to the DOM with React 15:\n+\n+````js\n+\/\/ React 15 output:\n+

\n+```\n+\n+In React 16, we are making a change. Now, any unknown attributes will end up in the DOM:\n+\n+```js\n+\/\/ React 16 output:\n+

\n+```\n+\n+## Why Are We Changing This?\n+\n+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:\n+\n+```js\n+

\n+```\n+\n+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:\n+\n+```js\n+\/\/ ...\n+summary: 'summary',\n+tabIndex: 'tabindex'\n+target: 'target',\n+title: 'title',\n+\/\/ ...\n+```\n+\n+This had two downsides:\n+\n+* 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.\n+\n+* 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.\n+\n+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.\n+\n+**Note that you should still use the canonical React naming for known attributes:**\n+\n+```js\n+\/\/ Yes, please\n+

\n+\n+\/\/ Warning: Invalid DOM property `tabindex`. Did you mean `tabIndex`?\n+

\n+```\n+\n+In other words, the way you use DOM components in React hasn't changed, but now you have some new capabilities.\n+\n+## Should I Keep Data in Custom Attributes?\n+\n+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.\n+\n+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.\n+\n+## Data and ARIA Attributes\n+\n+Just like before, React lets you pass `data-` and `aria-` attributes freely:\n+\n+```js\n+

\n+

dillon1000/react

Files changed