1) Redux is pretty simple, but some of the terminology is obtuse for no good reason and makes it harder to get a grip on than it should be. "Action" = event, "Action Creator" = any function that emits an event, it's basically... not even a real thing worth discussing with its own special term. There, problem mostly solved.
2) TypeScript is the only sane way to use it. The bouncing between files and "wait, what was the shape of my state here?" crap is intolerable without it. I mean that's broadly true of all Javascript but it's very noticeable with Redux. This is doubly true if you're working on a team.
3) I've had a lot of luck abstracting Redux behind a broader client library of some sort. You can expose the redux store itself and let the using code "compose" it as usual, but stick most of the "action creator" stuff behind the wall of the library, minimizing and moving to a more suitable level of abstraction the surface area the calling code is exposed to. This is especially nice if you may use the code in some environments where you don't want to or can't practically use React—you can still easily re-use the Redux portions, which is wonderful. Also tends to leave you with state code that's easier to test in isolation.
4) One of the big limitations of it is that you can't reference one part of your state from another. You have to copy, because of how Redux automagically detects changes to the state tree. This has been a lot more annoying and limiting than I thought it would be at first—turns out I need/want to do that more often than I thought I did, and the more complex the app the more I want to do it—but you've either got to learn to live with it or have some kind of external, supplemental state management alongside Redux.
Nailed it. Not only do I share the same sentiments, I have also had a very similar experience with 3.
Specifically, I like to be able to interact/test with my application as I build it in the console. I have had much success with wrapping my "Action Creators" in a API of sorts and mounting it to the `window`. This saves me from having to either create some sort of one-off component to "get at" some piece of functionality or hand-rolling actions in redux dev tools.
I've done similar things, and yeah, it's great for making quick-n-dirty utilities to poke around with your data & state handling code. You can even throw ugly non-React GUIs on top, trivially, including in something like Electron (if, say, your application needs access to functionality or modules not available on the Web, as could be the case for certain Javascript deployment targets like mobile, set-top boxes, desktop, server, and so on).
Understanding the original context and intent of a tool is important. Back in 2017, I wrote a post that covered the overall intent behind Redux's design [0], as I was already seeing that folks didn't know the background. That lack of understanding behind Redux's history has become more apparent over time.
The terminology exists because Redux was originally designed as "just" another implementation of the Flux Architecture. Both "actions" and "action creators" were terms that had already been introduced by Flux [1]. There was considerable debate during the initial design phase about what terms to use, and the conclusion was to stick with Flux terminology to match the target audience of the time [2].
Note that the new Redux Style Guide docs page specifically recommends "modeling actions as 'events'" [3], using the "ducks" pattern for single-file Redux logic [4], and writing Redux logic using TypeScript [5].
In addition, our new official Redux Toolkit package [6] is our recommended approach for writing Redux logic. It has several utilities for common use cases like setting up the store, writing immutable updates, and creating slices of state, and it's written in TypeScript with an API designed to minimize the amount of type declarations you have to write. (In fact, I've even used its `createSlice()` function to write some fairly complex reducer logic that I used with React's `useReducer` hook.)
Finally, you _can_ reference multiple parts of the state tree in your reducer logic, but you have to explicitly set that up yourself [7]. The `combineReducers` utility is meant for the standard use case of defining update logic by domain "slices", and it's up to you to write custom logic if you need more specific behavior than that.
Yeah, I know the history of the terms, I just find them so entirely unhelpful for (harmful to, in fact) understanding Redux, no matter what reason they're there, that providing a translation is pretty much the first thing I do when introducing someone to it. Figuring out what the terms actually meant was the moment I went from "what... what is this thing doing?" to "oh it's a couple very simple things I already understand, no big deal, got it now".
> Finally, you _can_ reference multiple parts of the state tree in your reducer logic, but you have to explicitly set that up yourself [6]. The `combineReducers` utility is meant for the standard use case of defining update logic by domain "slices", and it's up to you to write custom logic if you need more specific behavior than that.
As I've already said in this thread, we're currently working on a docs rewrite to try to update things for today's target audience: https://github.com/reduxjs/redux/issues/3592 .
As part of that, we'll be adding better explanations of terminology.
(and by "we" I mostly mean "me", since I'm not getting a lot of help from the community with this task atm.)
Thanks for your work on it. Seriously. I've enjoyed my time with Redux, more or less, and was in no way trying to shit on it with my comments—I hope it didn't come across that way.
2) TypeScript is the only sane way to use it. The bouncing between files and "wait, what was the shape of my state here?" crap is intolerable without it. I mean that's broadly true of all Javascript but it's very noticeable with Redux. This is doubly true if you're working on a team.
3) I've had a lot of luck abstracting Redux behind a broader client library of some sort. You can expose the redux store itself and let the using code "compose" it as usual, but stick most of the "action creator" stuff behind the wall of the library, minimizing and moving to a more suitable level of abstraction the surface area the calling code is exposed to. This is especially nice if you may use the code in some environments where you don't want to or can't practically use React—you can still easily re-use the Redux portions, which is wonderful. Also tends to leave you with state code that's easier to test in isolation.
4) One of the big limitations of it is that you can't reference one part of your state from another. You have to copy, because of how Redux automagically detects changes to the state tree. This has been a lot more annoying and limiting than I thought it would be at first—turns out I need/want to do that more often than I thought I did, and the more complex the app the more I want to do it—but you've either got to learn to live with it or have some kind of external, supplemental state management alongside Redux.