{"componentChunkName":"component---src-templates-blog-js","path":"/blog/2015/10/01/react-render-and-top-level-api.html","result":{"data":{"markdownRemark":{"html":"

When you’re in React’s world you are just building components that fit into other components. Everything is a component. Unfortunately not everything around you is built using React. At the root of your tree you still have to write some plumbing code to connect the outer world into React.

\n

The primary API for rendering into the DOM looks like this:

\n
ReactDOM.render(reactElement, domContainerNode)
\n

To update the properties of an existing component, you call render again with a new element.

\n

If you are rendering React components within a single-page app, you may need to plug into the app’s view lifecycle to ensure your app will invoke unmountComponentAtNode at the appropriate time. React will not automatically clean up a tree. You need to manually call:

\n
ReactDOM.unmountComponentAtNode(domContainerNode)
\n

This is important and often forgotten. Forgetting to call unmountComponentAtNode will cause your app to leak memory. There is no way for us to automatically detect when it is appropriate to do this work. Every system is different.

\n

It is not unique to the DOM. If you want to insert a React Native view in the middle of an existing iOS app you will hit similar issues.

\n

Helpers

\n

If you have multiple React roots, or a single root that gets deleted over time, we recommend that you always create your own wrapper API. These will all look slightly different depending on what your outer system looks like. For example, at Facebook we have a system that automatically ties into our page transition router to automatically call unmountComponentAtNode.

\n

Rather than calling ReactDOM.render() directly everywhere, consider writing/using a library that will manage mounting and unmounting within your application.

\n

In your environment you may want to always configure internationalization, routers, user data etc. If you have many different React roots it can be a pain to set up configuration nodes all over the place. By creating your own wrapper you can unify that configuration into one place.

\n

Object Oriented Updates

\n

If you call ReactDOM.render a second time to update properties, all your props are completely replaced.

\n
ReactDOM.render(<App locale=\"en-US\" userID={1} />, container);\n// props.userID == 1\n// props.locale == \"en-US\"\nReactDOM.render(<App userID={2} />, container);\n// props.userID == 2\n// props.locale == undefined ??!?
\n

In object-oriented programming, all state lives on each object instance and you apply changes incrementally by mutating that state, one piece at a time. If you are using React within an app that expects an object oriented API (for instance, if you are building a custom web component using React), it might be surprising/confusing to a user that setting a single property would wipe out all the other properties on your component.

\n

We used to have a helper function called setProps which allowed you to update only a few properties at a time. Unfortunately this API lived on a component instance, required React to keep this state internally and wasn’t very natural anyway. Therefore, we’re deprecating it and suggest that you build it into your own wrapper instead.

\n

Here’s some boilerplate to get you started. It is a 0.14 migration path for codebases using setProps and replaceProps.

\n
class ReactComponentRenderer {\n  constructor(klass, container) {\n    this.klass = klass;\n    this.container = container;\n    this.props = {};\n    this.component = null;\n  }\n\n  replaceProps(props, callback) {\n    this.props = {};\n    this.setProps(props, callback);\n  }\n\n  setProps(partialProps, callback) {\n    if (this.klass == null) {\n      console.warn(\n        'setProps(...): Can only update a mounted or ' +\n        'mounting component. This usually means you called setProps() on ' +\n        'an unmounted component. This is a no-op.'\n      );\n      return;\n    }\n    Object.assign(this.props, partialProps);\n    var element = React.createElement(this.klass, this.props);\n    this.component = ReactDOM.render(element, this.container, callback);\n  }\n\n  unmount() {\n    ReactDOM.unmountComponentAtNode(this.container);\n    this.klass = null;\n  }\n}
\n

Object-oriented APIs don’t look like that though. They use setters and methods. I think we can do better. If you know more about the component API that you’re rendering, you can create a more natural object-oriented API around your React component.

\n
class ReactVideoPlayer {\n  constructor(url, container) {\n    this._container = container;\n    this._url = url;\n    this._isPlaying = false;\n    this._render();\n  }\n\n  _render() {\n    ReactDOM.render(\n      <VideoPlayer url={this._url} playing={this._isPlaying} />,\n      this._container\n    );\n  }\n\n  get url() {\n    return this._url;\n  }\n\n  set url(value) {\n    this._url = value;\n    this._render();\n  }\n\n  play() {\n    this._isPlaying = true;\n    this._render();\n  }\n\n  pause() {\n    this._isPlaying = false;\n    this._render();\n  }\n\n  destroy() {\n    ReactDOM.unmountComponentAtNode(this._container);\n  }\n}
\n

This example shows how to provide an imperative API on top of a declarative one. Similarly, the reverse can be done, and a declarative wrapper can be used when exposing a Web Component as a React component.

","excerpt":"When you’re in React’s world you are just building components that fit into other components. Everything is a component. Unfortunately not everything around you is built using React. At the root of your tree you still have to write some plumbing code to connect the outer world into React. The primary API for rendering into the DOM looks like this: To update the properties of an existing component, you call render again with a new element. If you are rendering React components within a single…","frontmatter":{"title":"ReactDOM.render and the Top Level React API","next":null,"prev":null,"author":[{"frontmatter":{"name":"Jim Sproch","url":"http://www.jimsproch.com"}},{"frontmatter":{"name":"Sebastian Markbåge","url":"https://twitter.com/sebmarkbage"}}]},"fields":{"date":"October 01, 2015","path":"content/blog/2015-10-01-react-render-and-top-level-api.md","slug":"/blog/2015/10/01/react-render-and-top-level-api.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/2015/10/01/react-render-and-top-level-api.html"}},"staticQueryHashes":[]}