3 ms·
> think about having multiple contexts and derived state - there would be scenarios where your view layer would be unnecessarily coupled Can you expand on this
by nawgz 6y ago
> think about having multiple contexts and derived state - there would be scenarios where your view layer would be unnecessarily coupled
Can you expand on this?
I have created entire applications which are operating off of a single React context, and then also created some generic components which themselves expose a provider to their managed subtree. I have not faced any issues or "coupling" between these layers; I just pass props from the top-level context to the top of another subtree / component, and it works as I would expect.
I don't rely super heavily on derived state, but I find useEffect and useMemo to both be quite simple and effective when I need side effects or to memoize a piece of derived state to prevent throttling.
What situations am I missing that introduce these issues you talk about? How does Redux solve them more cleanly?
- veidelis 6y agoI'm just speaking from my own experience where we had an redux app with 30-40 reducers operating on quite a lot (100-200) of dynamic attributes in those objects and approximately the same amount of attributes that are initialized just once and don't change over the lifespan. I can't imagine using a single context for it all. We used thunks heavily, of course. I would prefer to look at the code to better understand how we approached problem solving in each case. Also, have you ever had to invest a good chunk of time to solve performance issues in any of those projects? We did.