React.js Conf 2015 - Making your app fast with high-performance components
Why Stack Overflow recommends it
Stack Overflow users link it when explaining the container/presentational component split and why wrapping views in data-aware containers cuts re-renders and keeps components reusable.
Recommended by 6 people across 6 different months, 2015 to 2017.
What it is
A 2015 React.js Conf talk by Jason Bonta of Facebook's Ads Interfaces team on keeping large React apps fast and maintainable. It covers component hierarchy, separating data concerns into container components, and passing data efficiently, based on a year spent building one of the biggest React applications.
What people said
Recommends Raman · 2015-07 · Stack Overflow · on “Passing store state as props, or each component accessing global stores?”
Jason Bonta from Facebook explained [this video] the concept of "Containers" in his React.js Conf 2015 talk. To summarize: containers are simply components that wrap other components, and take care of any data-related concerns such as talking to stores, while the underlying component is focused solely on the view (markup/styles/etc.) and doesn't care where the data comes from. This makes the component highly re-usable because it can be wrapped with a different container when data needs to come from a different place, not contain irrelevant state, therefore easier to implement and optimize shouldComponentUpdate , and using composition rather than mixins for this aligns with what is likely the futu
Recommends Jeff Diederiks · 2016-02 · Stack Overflow · on “Access parent context when using this.props.children in React”
I do not know about the first part of your question, but since you commented about dynamically creating components, here's how I do it: You can set a state variable in the constructor of the class and its parent: if (typeof this.state == 'undefined') { this.state = { componentsToRender: <div></div> }; } Then in the parent component, in the componentDidMount() function: var componentsToRender = []; if ([conditional]) { // some logic so you know which component to render componentsToRender.push(<customChildComponentToRender key={} />); } else { componentsToRender.push(<otherComponentToRender key={} />); } this.setState({ componentsToRender: <div>{componentsToRender}</div> }); Make sure to put
Recommends Jacob Lamont · 2016-03 · Stack Overflow · on “Multiple Components Using One Store”
For any other readers, the following three links help flesh out what @mattclemens suggests above. Thanks again for pointing me in this direction. Container and Presentational Components by Dan Abramov [LINK] , chantastic's gist on container components [LINK] , and Jason Bonta's talk at React.js Conf 2015 [this video] .
Recommends Mike Tronic · 2016-06 · Stack Overflow · on “(Curious) - Better to have a top-level smart component or small connected components?”
small connected components cause it reduces on unnecessary re-renders each part of the app updates its own state. good solution: REACT CONF [this video] .
Recommends Cory Danielson · 2016-07 · Stack Overflow · on “listening a store vs forceUpdate()”
You can use forceUpdate, but you shouldn't . Your current approach is correct (not using forceUpdate). If you have a common parent of these 5 listen for changes and pass data down to the children, the parent code will become bloated and you'll have 6 components (parent, 5 children) render when the store changes. Having more of these "container" components that listen to the store creates more isolation between components ("independent children") and is more performant because less components re-render when the store updates. Make sure you use shouldComponentUpdate, too. If you'd like to learn more about "independent children" and higher-performance react, watch: [this video]
Recommends Oliver · 2017-03 · Stack Overflow · on “React Redux element not updating”
Then you have to further break down your containers and components. Maybe you should take a look at this video [this video] or this component [LINK] .
Cites pnmn · 2015-03 · Stack Overflow · on “Creating a reusable React.js component with internal events in the Flux architecture”
I'm following the "containers and components" approach in the following video to build a reusable component in the Flux architecture. React.js Conf 2015 (22m 50s): [this video] For example, I'm building an image slider with the 'next' button. ImageSliderContainer Listens to ImageSliderStore and maintains states (e.g., currentIndex) Renders ImageSlider with props ImageSlider Stateless component, just rendering based on props Has a child component NextButton NextButton Stateless component, just rendering based on props Has onClick event In the Flux architecture, clicking NextButton will send an action to a store. Then, a store will update "currentIndex" and emit a change event. It seems to me that
Cites Kevin Lee · 2017-05 · Stack Overflow · on “How can a unique instance of a React component respond to the result of an async action using Flux?”
It looks like my first solution mirrors Fluxxor's (old?) way of handling this issue [LINK] , whereas the second method is the standard container-component strategy that Facebook recommends 1 [LINK] 2 [this video]