I wonder how controlled components (e.g an input box) can be implemented, if the data of an app is build upon immutable data and the app uses "===" equality operators in shouldComponentUpdate() for fast re-rendering.
Let's assume deeply nested data and a controlled component somewhere deep in the hierarchy:
When local component state is used (setState()) as one would implement this normally, the changes are not seen by react as the component hierarchy rendering process might skip branches, because the immutable data has not changed. To avoid this, all local component state has to live in the application state, and every event on the controlled component (e.g. typing in an input box) has to result in changing the immutable data.
Although this should work, is this the (only) way controlled components are implemented when immutable data is used??? Doing this all with flux (fire an action, fetch the store data...) might be a lot of overhead/round-trips for something simple as typing into an input box.
A component's state is a great place to put data you don't need to persist or access from multiple places. A common example of this, is an unsubmitted form. When the user does submit the form, you can then pass the local state upwards (callbacks in props) or horizontally (actions, event emitters, apis, etc.).
Also, about not updating, the only time calling setState won't trigger an update in the same component is if you have a overly negative shouldComponentUpdate. If you need local state, the shouldComponentUpdate should take that into account.