{"componentChunkName":"component---src-templates-blog-js","path":"/blog/2017/09/08/dom-attributes-in-react-16.html","result":{"data":{"markdownRemark":{"html":"

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
// Your code:\n<div mycustomattribute=\"something\" />
\n

would render an empty div to the DOM with React 15:

\n
// React 15 output:\n<div />
\n

In React 16, we are making a change. Now, any unknown attributes will end up in the DOM:

\n
// React 16 output:\n<div mycustomattribute=\"something\" />
\n

Why Are We Changing This?

\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
<div tabIndex=\"-1\" />
\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
// ...\nsummary: 'summary',\ntabIndex: 'tabindex'\ntarget: 'target',\ntitle: 'title',\n// ...
\n

This had two downsides:

\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

Note that you should still use the canonical React naming for known attributes:

\n
// Yes, please\n<div tabIndex=\"-1\" />\n\n// Warning: Invalid DOM property `tabindex`. Did you mean `tabIndex`?\n<div tabindex=\"-1\" />
\n

In other words, the way you use DOM components in React hasn’t changed, but now you have some new capabilities.

\n

Should I Keep Data in Custom Attributes?

\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

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

Data and ARIA Attributes

\n

Just like before, React lets you pass data- and aria- attributes freely:

\n
<div data-foo=\"42\" />\n<button aria-label=\"Close\" onClick={onClose} />
\n

This has not changed.

\n

Accessibility is very important, so even though React 16 passes any attributes through, it still validates that aria- props have correct names in development mode, just like React 15 did.

\n

Migration Path

\n

We have included a warning about unknown attributes since React 15.2.0 which came out more than a year ago. The vast majority of third-party libraries have already updated their code. If your app doesn’t produce warnings with React 15.2.0 or higher, this change should not require modifications in your application code.

\n

If you still accidentally forward non-DOM props to DOM components, with React 16 you will start seeing those attributes in the DOM, for example:

\n
<div myData='[Object object]' />
\n

This is somewhat safe (the browser will just ignore them) but we recommend to fix these cases when you see them. One potential hazard is if you pass an object that implements a custom toString() or valueOf() method that throws. Another possible issue is that legacy HTML attributes like align and valign will now be passed to the DOM. They used to be stripped out because React didn’t support them.

\n

To avoid these problems, we suggest to fix the warnings you see in React 15 before upgrading to React 16.

\n

Changes in Detail

\n

We’ve made a few other changes to make the behavior more predictable and help ensure you’re not making mistakes. We don’t anticipate that these changes are likely to break real-world applications.

\n

These changes only affect DOM components like <div>, not your own components.

\n

Below is a detailed list of them.

\n\n

While testing this release, we have also created an automatically generated table for all known attributes to track potential regressions.

\n

Try It!

\n

You can try the change in this CodePen.
\nIt uses React 16 RC, and you can help us by testing the RC in your project!

\n

Thanks

\n

This effort was largely driven by Nathan Hunzaker who has been a prolific outside contributor to React.

\n

You can find his work on this issue in several PRs over the course of last year: #6459, #7311, #10229, #10397, #10385, and #10470.

\n

Major changes in a popular project can take a lot of time and research. Nathan demonstrated perseverance and commitment to getting this change through, and we are very thankful to him for this and other efforts.

\n

We would also like to thank Brandon Dail and Jason Quense for their invaluable help maintaining React this year.

\n

Future Work

\n

We are not changing how custom elements work in React 16, but there are existing discussions about setting properties instead of attributes, and we might revisit this in React 17. Feel free to chime in if you’d like to help!

","excerpt":"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: would render an empty div to the DOM with React 15: In React 16, we are making a change. Now, any unknown attributes will end up in the DOM: Why Are We Changing This? 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…","frontmatter":{"title":"DOM Attributes in React 16","next":null,"prev":null,"author":[{"frontmatter":{"name":"Dan Abramov","url":"https://twitter.com/dan_abramov"}}]},"fields":{"date":"September 08, 2017","path":"content/blog/2017-09-08-dom-attributes-in-react-16.md","slug":"/blog/2017/09/08/dom-attributes-in-react-16.html"}},"allMarkdownRemark":{"edges":[{"node":{"frontmatter":{"title":"Introducing the New JSX Transform"},"fields":{"slug":"/blog/2020/09/22/introducing-the-new-jsx-transform.html"}}},{"node":{"frontmatter":{"title":"React v17.0 Release Candidate: No New Features"},"fields":{"slug":"/blog/2020/08/10/react-v17-rc.html"}}},{"node":{"frontmatter":{"title":"React v16.13.0"},"fields":{"slug":"/blog/2020/02/26/react-v16.13.0.html"}}},{"node":{"frontmatter":{"title":"Building Great User Experiences with Concurrent Mode and Suspense"},"fields":{"slug":"/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html"}}},{"node":{"frontmatter":{"title":"Preparing for the Future with React Prereleases"},"fields":{"slug":"/blog/2019/10/22/react-release-channels.html"}}},{"node":{"frontmatter":{"title":"Introducing the New React DevTools"},"fields":{"slug":"/blog/2019/08/15/new-react-devtools.html"}}},{"node":{"frontmatter":{"title":"React v16.9.0 and the Roadmap Update"},"fields":{"slug":"/blog/2019/08/08/react-v16.9.0.html"}}},{"node":{"frontmatter":{"title":"Is React Translated Yet? ¡Sí! Sim! はい！"},"fields":{"slug":"/blog/2019/02/23/is-react-translated-yet.html"}}},{"node":{"frontmatter":{"title":"React v16.8: The One With Hooks"},"fields":{"slug":"/blog/2019/02/06/react-v16.8.0.html"}}},{"node":{"frontmatter":{"title":"React v16.7: No, This Is Not the One With Hooks"},"fields":{"slug":"/blog/2018/12/19/react-v-16-7.html"}}}]}},"pageContext":{"slug":"/blog/2017/09/08/dom-attributes-in-react-16.html"}},"staticQueryHashes":[]}