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.
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 .
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?
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.
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.
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.
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.
Edit: No really, I'd like to hear why you think this would make React a "clusterfuck mess" rather than... simpler.
https://github.com/facebook/react/pulls?q=is%3Apr+is%3Aclose...
Even the developers have no idea WTF is going on.