5 ms·

I feel this way about React but Redux seems awkward and worthy of replacement. Am I in the minority on this?

by txsh 8y ago

beefalo 8y ago
You are not alone. After trying out GraphQL with Apollo, going back to Redux is painful.
rozenmd 8y ago
There are tons of options for State Management before you even need Redux. Check out: Context API: https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html Unstated: https://github.com/jamiebuilds/unstated https://github.com/jamiebuilds/unstated MobX: https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx
- fouc 8y ago
  Meiosis is a simple state pattern, a very elegant approach to handling state: http://meiosis.js.org http://meiosis.js.org
- egeozcan 8y ago
  There's also Baobab: https://github.com/Yomguithereal/baobab https://github.com/Yomguithereal/baobab https://github.com/Yomguithereal/baobab-react https://github.com/Yomguithereal/baobab-react
acemarke 8y ago
I'm a Redux maintainer. Any particular pain points you're concerned about?
- exogen 8y ago
  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!
  - acemarke 8y ago
    I'll be honest and say that a lot of those concerns seem like things that Redux couldn't possibly have any solutions for. How can the core library tell you "what to name action creators" or "where to put connected components"? Those are style guide / app architecture concerns that are going to be specific to each team. 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.
    - exogen 8y ago
      > Those are style guide / app architecture concerns that are going to be specific to each team. Exactly, but it's Redux's fault that it actively adds like 5 new styleguide/app architecture concerns to worry about in your project! That is a bad thing about its fundamental design. For crying out loud, just put redux-thunk back in the core library. Nobody doesn't have async actions! One less thing to make a decision about. > 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. I find that response pretty obtuse. I just told you what I told my developers in their code reviews, how about some language like that? Developers don't realize that connect() is just dependency injection for props, and those props should at least make sense from a dumb-component standpoint before Redux is involved. Or how about including a render-prop version of connect in the library, so developers don't go making a bunch of useless props in the first place? The HOC version is what is leading them towards poor design decisions. If your library is too easy for average devs to use poorly and my biggest headache during code reviews, to me that points to some issue with the library. This is why there is often "backlash" type sentiments around Redux being so popular.
- txsh 8y ago
  I am new to React and Redux so I might not have a well informed opinion. Also, I see the value of Redux and I use it in my projects. But it's awkward setting up a global event handler with switch statements. And it seems like adding new functionality should require one step instead of three (updating a reducer file, updating an action file, and updating mapStateToProps). It's like Redux operates on a different paradigm than Javascript and React. I do not think I'm knowledgeable enough to suggest any solutions.
  - acemarke 8y ago
    You might want to read Dan Abramov's post "You Might Not Need Redux" [0] and my own post "The Tao of Redux, Part 1 - Implementation and Intent" [1] to better understand the tradeoffs involved. [0] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... [1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
keithnz 8y ago
I find conceptually Redux is straightforward enough, just really wordy. I think perhaps if I got to choose again I might consider Mobx. I still use it for my react stuff but most new stuff I'm using Vue.
- molloy 8y ago
  Mobx and Redux have slightly different use cases, IMO. I prefer Redux for larger projects and Mobx for smaller ones, though I've only used Redux in production so far.
Bizarro 8y ago
No, you're probably in the majority. The problem isn't really the core concept of Redux, but needing to integrate the whole ecosystem around it - thunks, sagas, selector library, various other middleware. Standard redux is just too low-level. Take a look at Mobx State Tree https://github.com/mobxjs/mobx-state-tree https://github.com/mobxjs/mobx-state-tree
gunn 8y ago
I created my own library after finding redux boilerplate heavy. I haven't publicized it yet, but you can see it here - https://github.com/gunn/pure-store https://github.com/gunn/pure-store It supports full typescript typing, and uses Immer to allow very direct store updates with immutability.
- jamesiscool 8y ago
  Wow that look amazing, how can I subscribe react to the store? Will each component need something like mobx observer?
jetako 8y ago
I've been using redux-zero on my latest projects with reasonable success. It does away with the distinction between actions and reducers, so you're basically just calling functions that update the app state. This eliminates almost all boilerplate-ish code compared to redux, but it comes with its own caveats. I think it's a solid choice for small to medium size applications. https://github.com/concretesolutions/redux-zero https://github.com/concretesolutions/redux-zero
hesarenu 8y ago
Mobx. I went from redux fanboy to using mobx exclusively.

I feel this way about React but Redux seems awkward and worthy of replacement. Am I in the minority on this?

by txsh 8y ago

I feel this way about React but Redux seems awkward and worthy of replacement. Am I in the minority on this?

beefalo 8y ago

You are not alone. After trying out GraphQL with Apollo, going back to Redux is painful.

rozenmd 8y ago

There are tons of options for State Management before you even need Redux. Check out: Context API: https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html Unstated: https://github.com/jamiebuilds/unstated https://github.com/jamiebuilds/unstated MobX: https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx

fouc 8y ago
Meiosis is a simple state pattern, a very elegant approach to handling state: http://meiosis.js.org http://meiosis.js.org
egeozcan 8y ago
There's also Baobab: https://github.com/Yomguithereal/baobab https://github.com/Yomguithereal/baobab https://github.com/Yomguithereal/baobab-react https://github.com/Yomguithereal/baobab-react

acemarke 8y ago

I'm a Redux maintainer. Any particular pain points you're concerned about?

exogen 8y ago
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!
- acemarke 8y ago
  I'll be honest and say that a lot of those concerns seem like things that Redux couldn't possibly have any solutions for. How can the core library tell you "what to name action creators" or "where to put connected components"? Those are style guide / app architecture concerns that are going to be specific to each team. 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.
  - exogen 8y ago
    > Those are style guide / app architecture concerns that are going to be specific to each team. Exactly, but it's Redux's fault that it actively adds like 5 new styleguide/app architecture concerns to worry about in your project! That is a bad thing about its fundamental design. For crying out loud, just put redux-thunk back in the core library. Nobody doesn't have async actions! One less thing to make a decision about. > 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. I find that response pretty obtuse. I just told you what I told my developers in their code reviews, how about some language like that? Developers don't realize that connect() is just dependency injection for props, and those props should at least make sense from a dumb-component standpoint before Redux is involved. Or how about including a render-prop version of connect in the library, so developers don't go making a bunch of useless props in the first place? The HOC version is what is leading them towards poor design decisions. If your library is too easy for average devs to use poorly and my biggest headache during code reviews, to me that points to some issue with the library. This is why there is often "backlash" type sentiments around Redux being so popular.
txsh 8y ago
I am new to React and Redux so I might not have a well informed opinion. Also, I see the value of Redux and I use it in my projects. But it's awkward setting up a global event handler with switch statements. And it seems like adding new functionality should require one step instead of three (updating a reducer file, updating an action file, and updating mapStateToProps). It's like Redux operates on a different paradigm than Javascript and React. I do not think I'm knowledgeable enough to suggest any solutions.
- acemarke 8y ago
  You might want to read Dan Abramov's post "You Might Not Need Redux" [0] and my own post "The Tao of Redux, Part 1 - Implementation and Intent" [1] to better understand the tradeoffs involved. [0] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... [1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

keithnz 8y ago

I find conceptually Redux is straightforward enough, just really wordy. I think perhaps if I got to choose again I might consider Mobx. I still use it for my react stuff but most new stuff I'm using Vue.

molloy 8y ago
Mobx and Redux have slightly different use cases, IMO. I prefer Redux for larger projects and Mobx for smaller ones, though I've only used Redux in production so far.

Bizarro 8y ago

No, you're probably in the majority. The problem isn't really the core concept of Redux, but needing to integrate the whole ecosystem around it - thunks, sagas, selector library, various other middleware. Standard redux is just too low-level. Take a look at Mobx State Tree https://github.com/mobxjs/mobx-state-tree https://github.com/mobxjs/mobx-state-tree

gunn 8y ago

I created my own library after finding redux boilerplate heavy. I haven't publicized it yet, but you can see it here - https://github.com/gunn/pure-store https://github.com/gunn/pure-store It supports full typescript typing, and uses Immer to allow very direct store updates with immutability.

jamesiscool 8y ago
Wow that look amazing, how can I subscribe react to the store? Will each component need something like mobx observer?

jetako 8y ago

I've been using redux-zero on my latest projects with reasonable success. It does away with the distinction between actions and reducers, so you're basically just calling functions that update the app state. This eliminates almost all boilerplate-ish code compared to redux, but it comes with its own caveats. I think it's a solid choice for small to medium size applications. https://github.com/concretesolutions/redux-zero https://github.com/concretesolutions/redux-zero

hesarenu 8y ago

Mobx. I went from redux fanboy to using mobx exclusively.