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.
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.
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.
[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[1] https://facebook.github.io/flux/docs/in-depth-overview#actio...
[2] https://github.com/reduxjs/redux/issues/891#issuecomment-147...
[3] https://redux.js.org/style-guide/style-guide#model-actions-a...
[4] https://redux.js.org/style-guide/style-guide#structure-files...
[5] https://redux.js.org/style-guide/style-guide#use-static-typi...
[6] https://redux-toolkit.js.org
[7] https://redux.js.org/recipes/structuring-reducers/beyond-com...
> 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.
That's cool though.
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.)
Try Redux; acemarke has been evangelizing Redux Toolkit [1] recently and it looks great for a beginner not familiar to the Redux ecosystem.
But also - if Redux just isn't clicking for you, or if it is but you feel like writing it is unnatural - know that you're not alone.
Learn MobX, learn how to manage state with context and hooks [2], learn Apollo Client.
Yes it's a lot of up-front work, but you really do need to find a state management approach that works for you if you want to write non-trivial apps, in my opinion.
[1] https://redux-toolkit.js.org/ [2] https://kentcdodds.com/blog/application-state-management-wit...
Redux seems to be very polarizing about whether it increases or reduces complexity. As a back-end weenie who finds virtually everything about the front end confusing, I found Redux to be a breath of fresh air. Finally something straightforward that made sense and where the complexity of the code never seemed to exceed the complexity of the problem it was solving. But I was working with people who could run rings around me in the big React codebase we were working on who said Redux was a total mindfuck for them and they would never use it again if they had a choice.
Redux is great when needed, but can easily over-complicate something that can easily be solved by Context.
You may be interested in my suggested resources for learning React and Redux:
https://blog.isquaredsoftware.com/2017/12/blogged-answers-le...
https://blog.isquaredsoftware.com/2017/12/blogged-answers-le...
https://github.com/markerikson/react-redux-links
Also, please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. It's our recommended way to write Redux logic:
Meanwhile, we're working on a major rewrite of the Redux core docs. I'm hoping to put together a new "Quick Start" tutorial page that will show how to use Redux Toolkit and React-Redux in a "top-down" approach as a fast way to get productive. The current tutorials take a "bottom-up" approach, teaching how Redux works from first principles. I also want to rewrite those, keeping the same teaching flow, but updating the content to be easier to understand and to teach patterns that result in simpler code.
It's really easy to work with, and the concept of hierarchical state store is something that I haven't seen in any other library. If there was I probably wouldn't end up writing Statium in the first place. :)
Redux also has a reputation for being annoying to write because people cargo cult it into any project regardless of scope and because utilities like the excellent `redux-toolkit` weren't and still aren't as widespread as they should be.
hey, I'm trying to broadcast it as much as I can :)
fwiw, the adoption curve is definitely going up:
https://npm-stat.com/charts.html?package=%40reduxjs%2Ftoolki...
And the growth of the RTK package is especially impressive given that we renamed it from "Redux Starter Kit" to "Redux Toolkit" _after_ we'd released RSK 1.0.
We'll emphasize RTK even more as part of the ongoing Redux core docs rewrite. My goal is that it ultimately becomes the default way to write Redux logic, in much the way that the Apollo folks tell you to use `apollo-boost` and React devs default to use Create-React-App.