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

<comment><USER3> What do people use instead of Redux these days?

<comment><USER4> useReducer hook, MobX

<comment><USER5> 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.

<comment><USER6> 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.

<comment><USER5> 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.

<comment><USER6> Ah, gotcha.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> 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?

<comment><USER6> 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/)

<comment><USER8> 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)

<comment><USER6> Thanks, I'd missed a relative path for that link. Just pushed a fix.

</comment></comment></comment></comment><comment><USER6> 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)

<comment><USER9> 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.

<comment><USER6> 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.

</comment></comment></comment><comment><USER10> The last part "Performance and Normalizing Data" is great. Thanks for writing this!

<comment><USER6> 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?

<comment><USER10> 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.

<comment><USER6> > 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/)

</comment></comment></comment></comment><comment><USER11> 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.</comment>


Ask HN: Is there a hackable web browser? - <AUTHOR> Is there a browser, that allows us to change DOM on the fly, without all the restrictions of chrome extensions ( even mozilla is doing web extensions ) like saving to hard disk, script injection, and being more developer friendly ? <comment><USER2> Vivaldi might be your best bet: [https://vivaldi.com](https://vivaldi.com)

Interacting with disk isn't easy with Chrome, but using something like Styler or GreaseMonkey (or whatever it's called now) lets you mess with a page however you want.

The overhead of an extension is pretty small, once you actually build it and set your browser to developer mode.

<comment><AUTHOR> does vivaldi, have a plugin framework, that help us interact and save dom nodes ?

</comment></comment><comment><USER3> It doesn't seem to be actively developed, and may not work well out of the box, but [https://www.uzbl.org/](https://www.uzbl.org/) may be an option, or at least give some inspiration.

<comment><AUTHOR> Thank you for the reference. Seems promising, but let me use and see !

</comment></comment><comment><USER4> Electron?

<comment><AUTHOR> SO electron is again chrome. Doesn't it shield DOM and allow access only through content scripts. SO isn't the same model available in Electron ?</comment></comment>