Comment by rhacker | Hacker News Reader

Comment by rhacker | Hacker News Reader

Parent Full thread

I feel like Redux was a clusterfuck mess and this is the cleanup. Excuse the language.

Edit:

Expanding on this and why (I think) this solution is cleaner:

* In redux you ended up with pointless constant piles of strings that are the named actions. Totally useless in a JS world where a function that IS an action can take up that mantle.

* While reducers are a good way to make state consistent, using redux for state management when you actually don't have 17 different producers and 1 consumer it's major overkill. Most of the time you actually have 1 or 2 event (and value changing) producers and MANY consumers on the screen at one time.

* When you DO need a reducer, instead of making that the norm, this new hook library does provide a useReducer function that works exactly like that- and guess what? NO STRING CONSTANTS YAY.

I think the only downside I can think of is TTDebugging might be complicated to create under this dome, but was the same issue for stateful classes. That being said, it might be more possible now that the control is placed in a single feature area.

People use Redux way too often and think of features like time travel as nice-to-haves, when in reality they're the main reason why you'd want to use Redux in the first place.

Using Redux just to simply set and get data on every page is an overkill.

For the majority of applications making API calls directly from the component and storing data in the comp state is the way to go.

This is coming from someone who used redux excessively in the past.

What do you do when you want to update state in other places in response to a change in a component? How about if you want to make your component's state persistent (particularly when the component is external to your project)? Also, what do you do to generate state dumps for error reporting?

> What do you do when you want to update state in other places in response to a change in a component?

In 90% of the cases one of the parent components. Sometimes redux when the component tree goes super deep, or for things such as currentUser.

> How about if you want to make your component's state persistent (particularly when the component is external to your project)

What do you mean? Give me an example.

> Also, what do you do to generate state dumps for error reporting?

I don't generate state dumps for error reporting.

I'll point out that Ryan's demo _did_ show using string constants with `useReducer()`.

Also, our new `redux-starter-kit` library auto-generates action types and action creators for you, _and_ modifies the action creators so they can be used for the `case someAction` comparisons: https://github.com/reduxjs/redux-starter-kit .

What is the downside to changing the example here:

https://reactjs.org/docs/hooks-reference.html#usereducer

To something without strings and hard-coding the actual "reduction code" to something like

export const increment = (state) => ({count: state.count + 1});

And give modern JS languages like typescript import the increment function and use it directly?

Why are we so attached to these action type strings?

Redux is based on the Flux Architecture. In particular, it carries on the idea of describing events or state update requests as plain objects. One of the key insights of Redux is that you can then write additional logic to act on those actions as they progress through a centralized pipeline (ie, middleware).

I've seen lots of Redux-alikes that are "Redux, but without reducers/actions/etc". They mostly claim that they're making things simpler, and in some ways, maybe they do. But, what they're also doing is throwing away the ability to act on those actions as they get dispatched. If I "dispatch a function", I can't programmatically inspect its contents, modify it, log it, attach additional info to it, or all the other myriad of useful things you can do with a plain object.

As for the type strings, you need some kind of useful identifier to distinguish different action objects. You could use Symbols, but those don't serialize well. You could use numbers, but those aren't very meaningful when viewed in an action history log. Ultimately, you want your app's reducer logic, middleware, and the action history itself to be readable and semantically meaningful.

I think then perhaps redux may simply not be for me. I do feel like unfortunately a lot of teams use it anyway, giving React and a few other things a complex feel. When you suddenly take it out of React, at least for simple use-cases, you suddenly feel like React is incredibly simple.

If more teams had been more selective about Redux or to simply use it JUST for global state things like color themes, logged in user, and probably a half dozen other things it might have fewer people burned on it.

I'm definitely not in your shoes - you're a redux maintainer and I do apologize for my "clusterfuck" comment. But I think fewer people would be burned if architects at the top didn't mis-use and abuse. I've been in projects where just about every tiny little input, checkbox, on 30 or so forms had to go through a convoluted redux action. Then when I finally got into my own React usage, without redux, it was like a super-genius baby landed in my lap dancing like it was 1999.

Reply on news.ycombinator.com