|
Not OP, but my day to day job is helping teams with their migration onto React (often for big sites you've used or have at least heard of). Here goes, although these probably aren't anything new to you: – As far as I understand, Redux was intentionally made to be low-level and unopinionated, with the idea that other libraries would build on top of it. That has not really borne out and it actively makes adoption extremely painful. Everyone just uses Redux directly in their apps. As a result, adopting Redux on every team I've ever been on has been a painful process of figuring out how to fill in the blanks that Redux left out. Like how to handle async actions and side effects, how to name action creators, where to put connect()ed components, etc. And the result never feels great. – Related to the above: it's extremely telling that I can't name a single library of reusable Redux actions/reducers/etc. Despite attempts to define things like "ducks", and there being hundreds/thousands of reusable React components published, there are none for Redux that anyone has ever paid any attention to. Because of the batteries-not-included philosophy, you pretty much just can't share your Redux code, because different apps might be building on vanilla Redux in too disparate a fashion with whatever middleware they chose. That's why I'm expecting the new Context API to displace a fair amount of Redux usage: because publishing reusable Context libraries is going to be brain-dead simple compared to reusable Redux. – Developers just don't get what they should connect() and how to design their components, and Redux doesn't really offer them much guidance. As an example, every single day I have to mention in code reviews that something like a "loadProducts" prop does not make any sense on something like a "SearchButton" component, just because our Redux action happens to be named "loadProducts" – an "onClick" prop that just happens to be mapped to "loadProducts" in connect() makes much more sense. But devs are lazy and just end up giving components a bad design with a bunch of props that wouldn't make sense if Redux were not involved. Most of my code reviews contain the words "design your component's API without even thinking about Redux yet!" There are more, but those are the main issues. btw, thanks for all the hard work you do! |
FWIW, there _are_ a lot of chunks of reusable Redux-based logic out there (which I have listed in my Redux addons catalog [0]), but I'd agree that there does tend to be enough variation in people's use of Redux that sharing larger chunks can be difficult. I've seen quite a few experiments with various forms of Redux "modules", but yeah, none of them have fully taken off. There _are_ several very interesting higher-level wrappers around Redux that look like they offer potential solutions to the reuse / structure question, like Kea, Rematch, and redux-bundler.
While I sort of understand the concern in your last paragraph, I'm again not sure what sort of "guidance Redux could offer" in this case. If you've got suggestions for improving the docs, please file an issue, or even better, a PR, and we can work to get something in.