
Redux Overview and Concepts – Reimagined Redux Tutorial - kiyanwang
https://redux.js.org/tutorials/essentials/part-1-overview-concepts
======
city41
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.

~~~
weavie
What do people use instead of Redux these days?

~~~
halfmatthalfcat
useReducer hook, MobX

~~~
platz
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.

~~~
acemarke
That's the first time I've ever heard anyone say that "MobX and React are
conceptually similar".

MobX is technically based on an "observable" paradigm, but it's a completely
different API and mental approach than RxJS is.

Also, while MobX is commonly used with React, it's really a UI-agnostic state
management library (same as Redux).

I really wouldn't compare MobX and Angular at all. To me they look like
completely different tools.

~~~
platz
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.

~~~
acemarke
Ah, gotcha.

------
edem
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?

~~~
acemarke
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.

[0] [https://redux.js.org/tutorials/essentials/part-1-overview-
co...](https://redux.js.org/tutorials/essentials/part-1-overview-
concepts#when-should-i-use-redux)

[1] [https://redux.js.org/faq/general#when-should-i-use-
redux](https://redux.js.org/faq/general#when-should-i-use-redux)

[2] [https://blog.isquaredsoftware.com/2020/05/blogged-
answers-a-...](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-
mostly-complete-guide-to-react-rendering-behavior/)

[3] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead-
yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

~~~
avtar
I'm unable to make a PR at the moment but the first linked page
[https://redux.js.org/tutorials/essentials/part-1-overview-
co...](https://redux.js.org/tutorials/essentials/part-1-overview-
concepts#when-should-i-use-redux) has a broken link
[https://redux.js.org/tutorials/faq/General.md#when-
should-i-...](https://redux.js.org/tutorials/faq/General.md#when-should-i-use-
redux)

I'm assuming the correct link was supposed to be
[https://redux.js.org/faq/general#when-should-i-use-
redux](https://redux.js.org/faq/general#when-should-i-use-redux)

~~~
acemarke
Thanks, I'd missed a relative path for that link. Just pushed a fix.

------
acemarke
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!

[0]
[https://github.com/reduxjs/redux/pull/3740#issuecomment-6508...](https://github.com/reduxjs/redux/pull/3740#issuecomment-650847906)

[1] [https://redux-toolkit.js.org](https://redux-toolkit.js.org)

[2] [https://react-redux.js.org/api/hooks](https://react-
redux.js.org/api/hooks)

[3]
[https://github.com/reduxjs/redux/issues/3592](https://github.com/reduxjs/redux/issues/3592)

[4] [https://redux.js.org/style-guide/style-guide](https://redux.js.org/style-
guide/style-guide)

[5]
[https://github.com/reduxjs/redux/issues/3595#issuecomment-55...](https://github.com/reduxjs/redux/issues/3595#issuecomment-557760741)

~~~
DangitBobby
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.

~~~
acemarke
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.

------
ggregoire
The last part "Performance and Normalizing Data" is great. Thanks for writing
this!

~~~
acemarke
Thank you!

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?

~~~
ggregoire
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

    
    
        const resources = ['users', 'posts', 'comments']
    
        const { usersActions, postsActions, commentsActions } = createResourcesActions(resources)
        const { usersReducer, postsReducer, commentsReducer } = createResourcesReducers(resources)
        const { usersSagas, postsSagas, commentsSagas } = createResourcesSagas(resources)
    
        combineReducers({ users: usersReducer, posts: postsReducer, comments: commentsReducer  })
        sagaMiddleware.run(/* register the sagas */) 
    
        connect(state => ({ posts: state.posts.items }), { fetchPosts: postsActions.fetchResources })(PostsList)
    

It was funny to see you release something very similar. :) It definitely helps
a lot to deal with all the boilerplate.

~~~
acemarke
> 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:

[https://blog.isquaredsoftware.com/2019/10/redux-starter-
kit-...](https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/)

------
sheeeep86
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.

