Acemarke, I know you're fighting the good fight with Redux Toolkit. I personally use it for truly global state with React Native. It's unfortunate the Redux name has a bad connotation for some as RTK is really good. And for some reason Context became something that developers thought was actually usable. Not sure what happened.

Eh, there was entirely valid reasons for the backlash :)

Redux _was_ overused in the first couple years. The original patterns _were_ very boilerplate-y. There _are_ a lot of other good tools for varying use cases that overlap with things that people have used Redux for: Context for prop drilling, React Query / Apollo for data fetching, Zustand/Jotai/Mobx/five-million-other-libs for state management.

Redux will never be the "must use this" lib again the way it was there for a couple years.

And that's a _good_ thing, because folks should take time to think about what problems they actually need to solve in their apps and pick the tools that work best for those problems.

But it's also true that Redux _is_ still a useful tool, and that RTK has addressed the pain points in using Redux. So, still very much a viable choice today, and the positive feedback we get on RTK daily shows that.

Really, the bigger issue today is that a lot of folks don't seem to understand the technical differences, tradeoffs, and intended use cases between a lot of these tools.

I wrote an extensive post describing the differences between Context and Redux to try to help with that:

- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

I've also been trying to start up a community-driven site to list common tools for various use cases (state management, styling, build tools, data fetching, etc), to act as a resource to help clarify this sort of confusion:

- https://github.com/markerikson/react-community-tools-practic...

Sadly I haven't had time to push it forward myself due to all the other responsibilities and tasks on my todo list, but hopefully at some point we can get enough info filled in for it to be a real resources that we can point people to.

I appreciate this - some I've seen, some I'm a bit behind on.

Cursory glance indicates some of this is convenience wrapping of some normal react patterns instead of a refactor of redux. Is that fair?

No, RTK is a wrapper around just Redux patterns, not React.

- store setup: `configureStore` creates a store with a good default config in one function call

- Reducers: `createSlice` lets you define case reducers as functions in an object, write "mutating" syntax for immutable updates with Immer, and auto-generates the action creators for each reducer

- Data fetching: `createAsyncThunk` abstracts the standard "dispatch actions before and after an async request" pattern

- RTK Query: completely abstracts the _entire_ data fetching and caching process, adds cache entry lifecycles, auto-generates React hooks for use in components

The only React-related bits in RTK are the auto-generated React hooks for RTK Query endpoints. Everything else is "here's all the same kinds of logic you've always written for Redux, but with 1/4 the code and good default behaviors".

See https://redux.js.org/tutorials/fundamentals/part-8-modern-re... and https://blog.isquaredsoftware.com/2022/06/presentations-mode... for overviews of what changes from legacy "hand-written" Redux to RTK and how to use the RTK APIs.