Hacker News Reader

Comment by jaequery | Hacker News Reader

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.

View on HN

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.

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.

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/usage/usage-guide

Thank you! I didn't know you guys were even attempting to tackle this problem.

Looking forward to seeing more improvements in this area.

> 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

+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.

> 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.

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.

> 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.

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!

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.

> 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.

One of the core points of Redux is that all the state update logic gets combined into a single reducer function. How you choose to split the reducer logic into multiple files is up to you, so it may be separated in _that_ sense, but it's ultimately all getting pulled into one spot. So no, you don't have random "functions modifying global state and affecting different areas".

And no, it's not "untraceable code". Redux is explicitly meant to make it much easier to trace when, where, why, and how your state has been updated. All state changes happen via reducer functions (not random pieces of code somewhere in your UI logic), and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action).

> All state changes happen via reducer functions

Which are called where?

> and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action).

So now we've added a second tool to fix the problem caused by the first tool.

You don't seem to actually understand how Redux works.

All interactions revolve around "dispatching" an action to the store. The root reducer function is called as part of that `dispatch()` sequence. This gives a central point that allows tracing the resulting state changes:

    store.dispatch({type: "INCREMENT"})

The store can be configured on app startup to enable the Redux DevTools browser extension to automatically log all dispatched actions, including showing the action types and viewing the results of each dispatched actions (action contents, resulting state, and state diff vs the previous state).

This isn't "fixing a problem" with Redux, this is a core designed capability to allow you to understand how your app is behaving.

Again, I'm going to ask, where are you calling `store.dispatch({type: 'INCREMENT'})`?

You're saying I can't modify global state and have effects on a completely different area of the code, but I'm saying, yes, you can. All you're doing is telling me about the fairly-pointless layers of indirection Redux adds. Adding a layer of indirection doesn't solve the problem.

Unistore

Reply on news.ycombinator.com