5 ms·

I ask myself this a lot, are all the boiler plating you have to do for Redux “really” necessary just to have state management? Can we try combine the actions,

I ask myself this a lot, are all the boiler plating you have to do for Redux “really” necessary just to have state management? Can we try combine the actions, types, and reducers into a single domain so they aren’t seemingly repeated in 3-4 different locations. Maybe an option to combine or separate as needed. I know there are alternatives like Mobx and even the newer React Hooks so this seem to affirm my thinking that it might not be all necessary. And I personally haven’t seen any benefits from all the separations you do in Redux at least from projects I’ve worked on, all it led to was verbosity and more typing. It tend to make code more prone to mistakes and harder to follow. If I see the benefits, I wouldn’t mind but either I don’t see it or haven’t seen it yet. It just feels a bit like pre-mature optimization or over-abstraction.

nemothekid 7y ago
In my experience what ends up happening is that for 85% of application functionality you end up using a library that "manages" the boilerplate for you. For example, is you are writing an application that communicates with a REST API I use something like github.com/klis87/redux-saga-requests - and the store, actions, and reducers are taken care off in just a few lines and I get loading states, collections, and errors in return. For the other 15% you write your own reducers because you need some one-off functionality. I like this because I get to opt in to widely used and understood state management framework - I don't have to teach other engineers whats going on or how to debug the app, and next I have a tried and tested framework that doesn't get too unwieldily on complex components, like query builders. However, at the end of the day, the projects I've used Redux were all enterprise-y SaaS web apps with several bells and whistles. I can definitely see Redux being a chore on other applications that don't have a crazy scope.
leshow 7y ago
> It tend to make code more prone to mistakes and harder to follow. What mistakes are you encountering with Redux that you aren't seeing in a vanilla React app? IMO, redux makes your code uncomplicated and super easy to follow, but you pay for it with making code less portable via the context api/with global state.
- jaequery 7y ago
  It’s just how it is with coding (and probably anything else), the more of X there are, the more chance of mistakes you can have. Can I ask what other state management libraries you have used? If Redux is super easy, how do you feel about MobX or even VueX.
deleted 7y ago
[deleted]
bradhe 7y ago
> are all the boiler plating you have to do for Redux “really” necessary just to have state management? You can actually take this pretty far with regard to React in general. You can get in to some pretty funky situations with "proper" React boilerplate.
ng12 7y ago
> Can we try combine the actions, types, and reducers into a single domain so they aren’t seemingly repeated in 3-4 different locations. This is what the "duck" pattern is for: https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux
- ddoolin 7y ago
  +1, this is what we do in many of our tens-of-thousands of LoC codebases where I work and it works out great. I can't think of a single downside since we switched, actually.
_bxg1 7y ago
We use MobX and I highly recommend it. It basically turns pub/sub into a non-issue, while remaining unopinionated about the plain JS patterns you use to actually manage your data. Using it as intended requires some build configuration, but there's zero boilerplate. It can even be more performant than Redux under certain circumstances: it allows components to update without having to traverse the tree above them first.
acemarke 7y ago
It's definitely _not_ necessary, and that's exactly what our Redux Starter Kit package can help with! See the `createSlice` function in particular: https://redux-starter-kit.js.org/api/createSlice https://redux-starter-kit.js.org/api/createSlice https://redux-starter-kit.js.org/usage/usage-guide https://redux-starter-kit.js.org/usage/usage-guide
- jaequery 7y ago
  Thank you! I didn't know you guys were even attempting to tackle this problem. Looking forward to seeing more improvements in this area.
krzepah 7y ago
Unistore
kerkeslager 7y ago
Every answer to your post seems to suggest a new JavaScript library to fix this problem. But I have to ask: is another library really the answer when the problem is caused by a library in the first place? Are we supposed to believe that the complexity of Redux is reduced because it's hidden? The JavaScript community seems intent on repeating all the mistakes the C community made decades ago. Global state? Let's do it!
- robto 7y ago
  There's a huge difference between global state in C and redux, though - redux state is immutable and updated atomically. And immutable state really is a game changer in reducing complexity. When you're just dealing with functions and data, I don't know how it could get more simple. I know that it has made my code much more readable, testable, and organized.
  - kerkeslager 7y ago
    > redux state is immutable and updated atomically. Immutability certainly makes it less harmful, but it still means that a function in one area of the codebase can modify the global state and affect a completely different area of the codebase. Atomicity is basically a meaningless buzzword in this situation, given JavaScript doesn't have parallelism.[1] > When you're just dealing with functions and data When you're just dealing with functions and data, you aren't using Redux, so really anything you have to say after that isn't relevant. At the end of the day, you can make all these mistakes yourself if you want, but you'd be better served by listening to the programmers of the past and learning from their mistakes instead. [1] What you're actually talking about is the fact that the entire transition is executed in the same event, which isn't the same thing as atomicity, but is actually somewhat useful because it works around the horrible things JS programmers often do that make it difficult to tell what order state transitions will be executed in, despite being in a single-threaded environment. However, the fact that it enables inserting state transitions into utterly untraceable code is hardly a point in Redux's favor if you want your code to be traceable in the first place.
    - 7y ago

nemothekid 7y ago

In my experience what ends up happening is that for 85% of application functionality you end up using a library that "manages" the boilerplate for you. For example, is you are writing an application that communicates with a REST API I use something like github.com/klis87/redux-saga-requests - and the store, actions, and reducers are taken care off in just a few lines and I get loading states, collections, and errors in return. For the other 15% you write your own reducers because you need some one-off functionality. I like this because I get to opt in to widely used and understood state management framework - I don't have to teach other engineers whats going on or how to debug the app, and next I have a tried and tested framework that doesn't get too unwieldily on complex components, like query builders. However, at the end of the day, the projects I've used Redux were all enterprise-y SaaS web apps with several bells and whistles. I can definitely see Redux being a chore on other applications that don't have a crazy scope.

leshow 7y ago

> It tend to make code more prone to mistakes and harder to follow. What mistakes are you encountering with Redux that you aren't seeing in a vanilla React app? IMO, redux makes your code uncomplicated and super easy to follow, but you pay for it with making code less portable via the context api/with global state.

jaequery 7y ago
It’s just how it is with coding (and probably anything else), the more of X there are, the more chance of mistakes you can have. Can I ask what other state management libraries you have used? If Redux is super easy, how do you feel about MobX or even VueX.

deleted 7y ago

[deleted]

bradhe 7y ago

> are all the boiler plating you have to do for Redux “really” necessary just to have state management? You can actually take this pretty far with regard to React in general. You can get in to some pretty funky situations with "proper" React boilerplate.

ng12 7y ago

> Can we try combine the actions, types, and reducers into a single domain so they aren’t seemingly repeated in 3-4 different locations. This is what the "duck" pattern is for: https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux

ddoolin 7y ago
+1, this is what we do in many of our tens-of-thousands of LoC codebases where I work and it works out great. I can't think of a single downside since we switched, actually.

_bxg1 7y ago

We use MobX and I highly recommend it. It basically turns pub/sub into a non-issue, while remaining unopinionated about the plain JS patterns you use to actually manage your data. Using it as intended requires some build configuration, but there's zero boilerplate. It can even be more performant than Redux under certain circumstances: it allows components to update without having to traverse the tree above them first.

acemarke 7y ago

It's definitely _not_ necessary, and that's exactly what our Redux Starter Kit package can help with! See the `createSlice` function in particular: https://redux-starter-kit.js.org/api/createSlice https://redux-starter-kit.js.org/api/createSlice https://redux-starter-kit.js.org/usage/usage-guide https://redux-starter-kit.js.org/usage/usage-guide

jaequery 7y ago
Thank you! I didn't know you guys were even attempting to tackle this problem. Looking forward to seeing more improvements in this area.

krzepah 7y ago

Unistore

kerkeslager 7y ago

Every answer to your post seems to suggest a new JavaScript library to fix this problem. But I have to ask: is another library really the answer when the problem is caused by a library in the first place? Are we supposed to believe that the complexity of Redux is reduced because it's hidden? The JavaScript community seems intent on repeating all the mistakes the C community made decades ago. Global state? Let's do it!

robto 7y ago
There's a huge difference between global state in C and redux, though - redux state is immutable and updated atomically. And immutable state really is a game changer in reducing complexity. When you're just dealing with functions and data, I don't know how it could get more simple. I know that it has made my code much more readable, testable, and organized.
- kerkeslager 7y ago
  > redux state is immutable and updated atomically. Immutability certainly makes it less harmful, but it still means that a function in one area of the codebase can modify the global state and affect a completely different area of the codebase. Atomicity is basically a meaningless buzzword in this situation, given JavaScript doesn't have parallelism.[1] > When you're just dealing with functions and data When you're just dealing with functions and data, you aren't using Redux, so really anything you have to say after that isn't relevant. At the end of the day, you can make all these mistakes yourself if you want, but you'd be better served by listening to the programmers of the past and learning from their mistakes instead. [1] What you're actually talking about is the fact that the entire transition is executed in the same event, which isn't the same thing as atomicity, but is actually somewhat useful because it works around the horrible things JS programmers often do that make it difficult to tell what order state transitions will be executed in, despite being in a single-threaded environment. However, the fact that it enables inserting state transitions into utterly untraceable code is hardly a point in Redux's favor if you want your code to be traceable in the first place.
  - 7y ago