Hierarchical state and being able to update "my own" state is definitely where things get tricky in these virtual-dom. As a rule of thumb, anything that wants

Hierarchical state and being able to update "my own" state is definitely where things get tricky in these virtual-dom. As a rule of thumb, anything that wants to reference and mutate "its own" state should go in its own component and that state should live in the state, not in the props (props want to be immutable). If something doesn't need to keep a hierarchical chunk of state then it doesnt need to be split up into a component class. Perhaps a `function render_row()` that returns virtual dom nodes is enough. In your case, it might be simpler to keep all your state in the parent Table instead of splitting it into Rows. ----- > Does rows do something like this.props.updateRowName(this.props.row.id, newName), then the statemanager "queries" the rows and somehow replaces the entire dataset tree with a new one where that specific row's name has been changed? At one point of the other, you are going to call setState() on some react component. In this example, this component could be the row itself the parent table or something higher up, depending on how you structured your app (there are pros and cons to each alternative here). Once you call setState() on that component, react will redraw the virtual DOM for that point down. Then, React detects where the virtual dom changed and emits real DOM mutations to update the screen. In your question, if the parent table gets its state mutated, then it won't query the rows - it will just redraw all of them. This is not a big of a deal: redrawing virtual DOM is supposed to be cheap and you can use shouldComponentUpdate as a performance hint if you know that a certain subtree wont need to be updated. ----- Finally, there are design patterns that deal with mutating immutable data structures (lenses, cursors, etc) but its a bit of an orthogonal issue. When you use this the idea is that you have a single mutable state thing at the root instead of a hierarchical set of state components (or at least thats how I understand it goes - I dont know Om in depth)