react-redux

I mildly disagree. componentWillMount() is slightly superior to the constructor, though only for very specific situations[0]. I would agree that for the vast majority of people who use ES6, the difference basically doesn't exist, but there is a real reason to use componentWillMount instead of the constructor. 0: https://github.com/reactjs/react-redux/issues/129 Edit: You might call dispatching in a constructor an anti-pattern (or having any side-effects at all), but quite a few people do it and it can cause very subtle bugs that aren't entirely reproducible.

A lot of people seem to be re-discovering and re-inventing this approach, due to the recent discussions in the React community about the use of "render props" as an alternative to Higher-Order Components. It's interesting to note that this is actually how React-Redux worked originally [0], but it was changed to be a HOC later. There's other recent examples at [1] and [2]. Dan Abramov's tweet at [3] describes why React-Redux changed from a render prop to a HOC in the first place, and there's another good Twitter discussion thread at [4] (where Michael Jackson points out that this is suddenly a really popular thing to try). Glancing at the source code for this implementation, I'm actually rather concerned about its performance. It looks like it calls `connect()` _inside_ of a functional component. That means that every time React re-ren

My point isn't so much loading data from a remote endpoint, but setting state. As the doc you quote says: componentWillMount should not trigger rerendering, and should have the newest state in the render function. But when you use Redux this isn't true! The first render will see the old state of the store even if you did changes to it right befofe. And then you immediately get a new rerender with the correct state. This cannot be fixed with how react-redux is currently implemented, and leads to subtle bugs, especially when unmounting and remounting stuff that tries to clear some state. Edit: more details https://github.com/reactjs/react-redux/issues/210

There are two ways to make them more loosely coupled: 1. declare your connect's in a separate file that import your component and live alongside your containers, actions, reducers, etc. 2. write your own connect HOC that brings in redux. If you read the connect source[0] you'll find that it is actually really simple at it's core - but it is over complicated by having to account for so many use cases - your own HOC could/should be ~30 lines I now use 2. because it produces proper separation and makes it easy to swap out components later on (or use more than one). [0] https://github.com/reactjs/react-redux/blob/master/src/conne...

On the surface, the rax-redux implementation appears to be a lot simpler. For example, react-redux's connect spans all these files https://github.com/reactjs/react-redux/tree/75658dab18f7fe3e... and includes "connectAdvanced": https://github.com/reactjs/react-redux/blob/75658dab18f7fe3e... While the rax-redux equivalent seems to be contained in a single file: https://github.com/alibaba/rax/blob/07e20908e4e17b182873db09... The simpler implementation might indicate that the rax developers are trimming overcomplicated bloat, or culling features that don't align with specific needs of Alibaba. Or maybe they're just removing code they don't yet understand the necessity for. It's not immediately clear what tradeoffs each are making, but having rax audit what's really necessary could be a good thing for everyone.