5 ms·

Redux contains a number of different ideas/solutions, and I think it's maybe more fair to view them independently. Redux solves prop drilling via the connect fu

Redux contains a number of different ideas/solutions, and I think it's maybe more fair to view them independently. Redux solves prop drilling via the connect function (technically in react-redux, not core redux), and you might say that Context competes with that aspect. Other aspects of Redux are completely unrelated to Context and also good to understand: a unified immutable state tree transformed via composable pure functions in response to a well-defined set of actions represented as objects. Not that you can't do that with Context, but I think it's maybe unfair to view Context as a replacement for Redux.

dceddia 8y ago
> I think it's maybe unfair to view Context as a replacement for Redux. That pretty much sums up why I wrote this article :) After the new Context API came out, a lot of people started saying that it would replace Redux, and like you said, they only really overlap in that they can help avoid prop drilling. Redux is more powerful, out of the box anyway.
bhj 8y ago
Definitely, the power of redux middleware should not be underestimated, e.g. redux-throttle[0], redux-optimistic-ui[1], redux-persist[2] [0]: https://github.com/mathieudutour/redux-throttle https://github.com/mathieudutour/redux-throttle [1]: https://github.com/mattkrick/redux-optimistic-ui https://github.com/mattkrick/redux-optimistic-ui [2]: https://github.com/rt2zz/redux-persist https://github.com/rt2zz/redux-persist (to be pedantic, some of these are not solely middleware)
WalterSear 8y ago
Funny, I vastly prefer the simplicity of passing down props over HOC spagetti - even when heavily nested. It is a simple matter to keep things organized and out of your way, and change detection is taken care of by selectors. I used to think props were good for dynamic components, but with portals available, I rarelyconsider them a good pattern for anything but components shared between applications. I use context to pass down actions. IMHO, mapping those into state should be deprecated.
- williamdclt 8y ago
  I have a very different point of view: HOC are core to my way of doing things, as I try to make each component as self-contained and easy to use (fewer props) as possible. Why would I give a user object to my component when it could get it by itself? It means that components are more coupled to the state, but way way less coupled between them. Which I find to be easier to work with!
  - WalterSear 8y ago
    So why use redux at all then? Why not just subscribe to a bunch of selectors? The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :)
    - williamdclt 8y ago
      > So why use redux at all then? Why not just subscribe to a bunch of selectors? Not exactly sure what you mean by that? Selectors are a redux thing for me, I don't understand what you mean by not using redux but subscribing to selectors > The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :) I don't see how that's a problem. Just because you render a bunch of wrapper components (one for each HOC)? React is extremely efficient at rendering this kind of components having only one child
      - WalterSear 8y ago
        Not sure I follow. Selectors don't need redux. I use them everywhere. https://github.com/reduxjs/reselect https://github.com/reduxjs/reselect > Just because you render a bunch of wrapper components (one for each HOC)? Efficient rendering would involve >not< re-rendering the child on every prop render, but only when the relevant props have changed. Connect does a shallow comparison, so all the props need to be immutable for it to work. You can use immutablejs to make your object props immutable, but this gets messy fast. I have found it easier to use selectors, and have changes land when an actual change happens, rather than checking for them or organizing your data to facilitate change detection (rather than organizing your data to make it easier to think about).
deleted 8y ago
[deleted]

dceddia 8y ago

> I think it's maybe unfair to view Context as a replacement for Redux. That pretty much sums up why I wrote this article :) After the new Context API came out, a lot of people started saying that it would replace Redux, and like you said, they only really overlap in that they can help avoid prop drilling. Redux is more powerful, out of the box anyway.

bhj 8y ago

Definitely, the power of redux middleware should not be underestimated, e.g. redux-throttle[0], redux-optimistic-ui[1], redux-persist[2] [0]: https://github.com/mathieudutour/redux-throttle https://github.com/mathieudutour/redux-throttle [1]: https://github.com/mattkrick/redux-optimistic-ui https://github.com/mattkrick/redux-optimistic-ui [2]: https://github.com/rt2zz/redux-persist https://github.com/rt2zz/redux-persist (to be pedantic, some of these are not solely middleware)

WalterSear 8y ago

Funny, I vastly prefer the simplicity of passing down props over HOC spagetti - even when heavily nested. It is a simple matter to keep things organized and out of your way, and change detection is taken care of by selectors. I used to think props were good for dynamic components, but with portals available, I rarelyconsider them a good pattern for anything but components shared between applications. I use context to pass down actions. IMHO, mapping those into state should be deprecated.

williamdclt 8y ago
I have a very different point of view: HOC are core to my way of doing things, as I try to make each component as self-contained and easy to use (fewer props) as possible. Why would I give a user object to my component when it could get it by itself? It means that components are more coupled to the state, but way way less coupled between them. Which I find to be easier to work with!
- WalterSear 8y ago
  So why use redux at all then? Why not just subscribe to a bunch of selectors? The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :)
  - williamdclt 8y ago
    > So why use redux at all then? Why not just subscribe to a bunch of selectors? Not exactly sure what you mean by that? Selectors are a redux thing for me, I don't understand what you mean by not using redux but subscribing to selectors > The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :) I don't see how that's a problem. Just because you render a bunch of wrapper components (one for each HOC)? React is extremely efficient at rendering this kind of components having only one child
    - WalterSear 8y ago
      Not sure I follow. Selectors don't need redux. I use them everywhere. https://github.com/reduxjs/reselect https://github.com/reduxjs/reselect > Just because you render a bunch of wrapper components (one for each HOC)? Efficient rendering would involve >not< re-rendering the child on every prop render, but only when the relevant props have changed. Connect does a shallow comparison, so all the props need to be immutable for it to work. You can use immutablejs to make your object props immutable, but this gets messy fast. I have found it easier to use selectors, and have changes land when an actual change happens, rather than checking for them or organizing your data to facilitate change detection (rather than organizing your data to make it easier to think about).

deleted 8y ago

[deleted]