A lot of people have dismissed Redux and even roll their eyes when it's mentioned these days. I'm still a big fan after all these years. The recent improvements such as the toolkit, slices and integration of ImmerJS make Redux much smoother and reduce the boilerplate a lot. For apps that have lots of state, I've yet to find a pattern I like better.
Crap library, even sourcing without process manager? (saga is an after thought) doco does not even bother to teach users about command/event distinction. The library works I guess, just like code i wrote in my junior years.
Redux is quite misleading using the term events for command/action, which drives coder to use Redux's action as in-app events, tightly coupling Redux's synchronous store with asynchronous nature of events.
my impression is, if you going choose a paradigm like MobX, you might as well use Angular, which is conceptually pretty similar, just with different opinions on library vs framework.
All I meant was they're a bit similar in how one often centralizes logic into services based on observables which also cause globally visible mutable state changes.
no, you are making an argument that is React must be used a certain way (that is incompatible with MobX). I'm not sure what makes you think you're someone who can make gatekeeping statements like that if the react team never said such thing. MobX adds reactivity to your object oriented domain code and React allows you to write functional view component, what's wrong with that?
And no using MobX and using Angular are 2 vastly different things. One can like MVVM (MobX) and dislike string template and other convoluted mechanisms Angular.
The biggest improvement IMO is the toolkit, which gives you an off the shelf packaged Redux implementation. The toolkit has support for slices and Immer out of the box.
We have a new official "Redux Toolkit" package [0], which is now our recommended way to write Redux logic. 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. We've also recently added APIs for basic async data fetching via thunks, and reusable functions for managing normalized entity state.
Meanwhile, we now recommend the React-Redux hooks API [1] as the default way to interact with the Redux store in your components. It provides `useSelector` and `useDispatch` hooks, which are lighter-weight and generally easier to understand and work with than `connect` is. They're also much easier to use with TypeScript.
The Redux docs have always been very unopinionated, and just said "here's 3 different ways to do this task" (such as describing the typical "folder-by-type" / "feature folder" / "ducks" folder structures, but not giving an actual suggestion on which approach to use). We now have a "Style Guide" docs page [2] that gives our actual recommendations on how to use Redux the right way, such as "put more logic in Reducers", "model actions as 'events' instead of 'setters' ", and "use the 'ducks' pattern for single-file logic".
So, while the actual Redux core hasn't changed, the way you'd write your Redux code now would be significantly different than what you might have seen a couple years ago, and the new "Redux Essentials" tutorial linked in this HN thread is intended to teach these latest practices.
What I'm really missing here is the "When not to use Redux" part. Can somebody help with that? So far I've been using context only and it was fine. Why should I switch to Redux?
That's actually covered directly in the linked tutorial page [0], as well as in our Redux FAQ section [1]
Note that one of the weaknesses of the React context API is that it currently has significant limitations in how components using it re-render, because you can't bail out of re-renders caused by context or only selectively depend on certain pieces of a context value. In contrast, React-Redux lets you select specific pieces of data from the Redux store, and your components only re-render when the data they need changes. For more details, see my extensive post "A (Mostly) Complete Guide to React Rendering Behavior" [2].
My post "Redux - Not Dead Yet!" [3] also addresses some of the differences in use cases for Redux and Context, and how they're very different tools that solve different problems.
Personally, I learned Redux, then as soon as possible found different (simpler) ways to achieve the same pattern. I love the concepts of Redux, but not the boilerplate (nor the ecosystem, if I'm being honest).
Hey, I wrote this! Neat to see that someone else submitted here.
I spent a _lot_ of time and effort trying to put this together [0]. The existing tutorial sequence has been read by a lot of people over the years, but it takes a "bottom-up" approach: it teaches how each of the Redux pieces work in isolation, and builds up from there. That tutorial is also one of the oldest parts of our docs, and it was written in a much different era for a different audience: when "Flux" was still a thing, and people were looking at migrating away from Backbone.
This new "Redux Essentials" tutorial has several goals:
- It takes a "top-down" approach, with a focus on "how to use Redux, the right way", rather than "how it works".
- It teaches our latest recommended patterns and practices, like using our official Redux Toolkit package [1] for writing your Redux logic, and using the React-Redux hooks API [2] instead of the earlier `connect` API.
- It shows how to build a somewhat more realistic example app, and explains various Redux concepts and APIs as we add new features.
- Improve explanations and make it more clear how Redux integrates into a typical React app, and how data flows through a Redux application.
I'm hopeful that this new tutorial will make it easier for people to jump right into learning Redux and building something useful with it, and they can look more into "how does it work inside?" later.
The new tutorial is part of my ongoing effort to rewrite most of the Redux docs [3]. I'd previously written the new "Redux Style Guide" docs page [4], which lists our recommended best practices.
My next task is to rewrite the existing "Basics/Advanced" tutorial sequence [5]. My plans for that section are:
- Drop all outdated references ("Flux", "containers", etc)
- Show simpler patterns (inline action types like `{type: "todos/addTodo"}` vs `const ADD_TODO = "ADD_TODO"`, single-file Redux logic)
- CodeSandbox examples
- Show React-Redux hooks
- Improve explanation flow
If anyone's got any feedback, suggestions, or questions, let me know!
Thank you for doing this! When I was first learning React/Redux, I found the Redux documentation to be pretty much useless for trying to understand how it fit into the bigger picture of my application. 3rd party tutorials saved my bacon on that front. This, on the other hand, looks like a very clear walkthrough of how to use Redux. So again, thanks and kudos.
Yeah. We've had a lot of very positive compliments about the Redux docs over the years, but at the same time I also see a lot of weaknesses and ways they can be improved (hence the docs rewrite effort).
One of the biggest gaps has been info on real world usage. Thus far, it's kinda been "here's a todo app, here's some basic data fetching... go have fun!". The "Recipes" section has some useful info, but it's not a coherent larger walkthrough.
If you look at that "docs rewrite overview" issue, I want to specifically add a new "Real World Usage" section that contains both some of the existing "Recipes" material with better organization, and new material with practical advice on app structure and practices.
Of course, since it's _only_ me working on the docs atm, this could take a while :) I'd really appreciate other folks from the community jumping in to help out with the docs work.
Hello again @acemarke, My feedback last month on HN [0] ended up in the original issue thread about this doc rewrite.
Thank you for taking the time to build out this documentation! I'm going to send it along to my team for their review and comments.
Sure! I definitely remember your comment. Not sure if I fully addressed all the concerns you were listing there, but hopefully it's an improvement, and I'd appreciate any further feedback on it.
Still not sure how to split the explanations between the RTK docs and the Redux core docs, tbh.
The React ecosystem has a whole has moved towards a more "integration"-ish approach towards testing components. There's multiple reasons for this:
- Kent C Dodds is a strong proponent of that approach, and teaches it in his materials on how to write tests. He also created the React Testing Library lib, which has picked up a lot of adoption in the community. (Enzyme has struggled to keep up with some of the newer features in React, which has led to a number of folks switching to RTL as well.)
- Hooks in general push you towards a different set of tradeoffs for how your components read data. Related to that, the concept of "container components" isn't completely useless, but the community always over-obsessed about that idea.
I specifically talked about some of the differences in mental models and tradeoffs in my post "Thoughts on React Hooks, Redux, and Separation of Concerns" [0], and my ReactBoston 2019 talk on "Hooks, HOCs, and Tradeoffs" [1].
So, the RTL docs suggest that you should test Redux-using components by writing a reusable function to "render components with a Redux store + Provider wrapped around them" [2], and we just merged a PR to the Redux docs that shows that same approach [3].
It's actually just a bit sad to look at the page hit stats, and see that the readership drops off dramatically after Part 1. Looks like Part 6 has <10% of the hits that Part 1 does. Not surprising when you think about it, I guess.
Out of curiosity, anything specific in that page you found particularly helpful?
I've been using Redux for many years so I just skipped to the last part (I'll probably read the rest tho, I'll surely learn something). Strangely, I've never normalized the data in my apps. I knew the technique but it has never been a performance bottleneck for us. But I can see how convenient it could be anyway (looking up a specific item instead of finding it). Also, we have been writings selectors but very few actually, we should definitely make it the norm. We write a lot of collection filtering, mapping and reducing directly in our connects.
> Out of curiosity, anything specific in that page you found particularly helpful?
I liked how you demonstrated rerendering issues (illustrated with the profiler tool) and applied those techniques (selectors, normalization) to fix them.
-
Just for the anecdote, slightly off-topic, I wrote like 3 years ago some Redux helper functions very similar to what you did with React Toolkit. We have 3 functions createResourcesActions, createResourcesReducers and createResourcesSagas, which take an array of strings describing our resources and return the corresponding actions, reducers and sagas (we fetch about 50 different types of resources). Something like
> I liked how you demonstrated rerendering issues (illustrated with the profiler tool) and applied those techniques (selectors, normalization) to fix them.
Great, that's _exactly_ what I was trying to accomplish!
> It was funny to see you release something very similar
It's actually not surprising at all :)
Redux Toolkit was specifically designed to solve the most common problems that people were experiencing while using Redux, and we've taken inspiration from many of the third-party libraries that the community had already created (because those libs were created to solve the same kinds of problems, and gave us ideas for what kinds of APIs people were writing).
For more background, see my post "Redux Toolkit 1.0", which talks about the discussions, issues, and ideas that inspired Redux Toolkit, how we evolved and designed its APIs, and the vision and goals behind its design:
Content-wise: Part 1 is Redux terms/concepts/"why would I use this?", while Part 2 is a walkthrough of a Redux Toolkit "counter" example to illustrate all the pieces of a typical React+Redux app.
Thank you for putting this together. I love redux and have built several products with it. I find that every time I've added team members that are not familiar with the concepts, it is very hard to on board them and use it correctly. I've seen this both for junior team members and for very experienced developers coming from extensive Java backend development.
