3 ms·

Wait.. no. There is enough information out there that suggests that React's Context should not be considered a replacement for Redux. Just think about having mu

Wait.. no. There is enough information out there that suggests that React's Context should not be considered a replacement for Redux. Just think about having multiple contexts and derived state - there would be scenarios where your view layer would be unnecessarily coupled with stateful logic or other undesired patterns.

nawgz 5y 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 5y ago
  I'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.

3 ms·

Wait.. no. There is enough information out there that suggests that React's Context should not be considered a replacement for Redux. Just think about having mu

by veidelis 5y ago

nawgz 5y 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 5y ago
  I'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.