When we started the migration to React we faced an interesting problem. Most of the resources explained data structures in React on very simple examples. Our data model was far more complex. Also, we had to combine React with other stacks, like GridLayout (based on jQuery) and leave the ability to shift to any other codebase in the future.
Like explained in previous article we decided to extract our data layer from the actual app and maintain in the form of SDK. Using observables together with Redux made all more powerful, yet easier to maintain on that scale. Still, we encountered issues with implementation as React (as it was the bottleneck here) fits perfectly to Redux and quite simple stores. Adding reactive patterns to it wasn’t as obvious and as we found it was very easy to overcomplicate it.
React components are basically lifecycle wrappers around render functions. Those functions should take props and state without any side influences. Without it React just don’t work, but with it, it’s bloody effective.
We had to subscribe our components to reactive data sources, without a need to do too many re-renders or keeping too many subscriptions handing.
Receipt tuned out to be:
- Subscriptions are created just before mounting and removed before unmounting.
- Subscriptions update state, react decide if re-render is needed.
- Component manages own sub-state, that should contain only latest known version data that is essential for this specific component. Any additional information should be ignored/discarded, so never stored in the component.
- Props should be kept only for injecting initial configuration (like telling which observable to watch) and not used to push new values.
To reiterate: render is always a function of
The component is given some observable (that can come via
global) depending what you want to achieve.
Also, I use interfaces to enforce types in the state.
What did not work
Hope it helps. We did some trials and fails before finding it all out.