[Docs Rewrite] Meta-Issue: Understanding Redux section

[markerikson]

This is a tracking issue for all work related to creating a new "Understanding Redux" section

Goal

Pasting from my original writeup in #3313 :

This section has several objectives:

• Teach the "prerequisites" needed for Redux, including JS array methods, immutability, etc
• Teach people how to "think in Redux" (multiple reducers listening to one action, treating actions more as events than "setters", etc)
• Some details on how Redux works internally
• Info on when you should use Redux, and why Redux patterns exist. (This should mostly be cribbed from Dan's "You Might Not Need Redux", my "Idiomatic Redux: The Tao of Redux" posts, and Justin Falcone's "What's So Great About Redux?").

Tasks

• "Background Concepts" section
  • Outline content
  • Move material from "Structuring Reducers"
• "Thinking in Redux" section
  • Outline content
• "How does Redux Work?" section
  • Outline content
• "History and Design" section
  • Outline content

[wgao19]

Would love to work on these also. But I feel these sections are more subjective than others so maybe will work on them later. Putting up a few resource links first

• Getting Started with Redux
• Building React Applications with Idiomatic Redux
• Idiomatic Redux: The History and Implementation of React-Redux
• Dan's twitter thread on preferring how to “think in it” over explaining it in terms of API

[markerikson]

Two great resources on how and why to model actions as events:

• Dillon Mulroy - "Event Driven Redux": video / slides
• Yazan Alaboudi - Our Redux Anti-Pattern: A Guide to Scalability: video / slides

Also:

• https://engineering.tableau.com/redux-command-bus-or-event-store-2c4c044cd481
• https://event-driven.io/en/clickbait_event/

[markerikson]

Totally can't forget @modernserf 's great post on What's So Great about Redux?.

[markerikson]

A very good summary of the "business logic" approach:

https://twitter.com/FwardPhoenix/status/952972062058074112

"Can it be done with just dispatch arguments?" -> action creator.
"Can it be done with previous state and action?" -> reducer
"Can it be done from just state?" -> probably a component.

So "where does the business logic lives" -> everywhere.

Thoughts on teaching the "multiple reducers responding" pattern:

https://twitter.com/dai_shi/status/1184230104613810177

When I teach Redux, I find many beginners misunderstand that pattern. They are surprised when I tell that pattern is possible and even recommended.
One of the reasons why this happens, I think, is combineReducers. It's in core and almost all examples use it

[markerikson]

More bookmarks that could be useful:

• Might be interesting to reference this bit of "Redux history" I wrote up here: https://www.reddit.com/r/reactjs/comments/mm43cn/would_redux_survive_without_its_maintainers_high/
• Discussions about boilerplate, thunks, complexity, etc: https://www.reddit.com/r/reactjs/comments/njy5ld/redux_boilerplate_was_never_the_problem/
• How well do the docs explain immutability: https://twitter.com/acemarke/status/1448696463496605697
• Some "Why RTK" stuff: https://www.reddit.com/r/reactjs/comments/qdiagp/stepping_up_your_redux_game_with_redux_toolkit/
• My comment on how Dan hasn't been involved with Redux in years, and Lenz chiming in on how we designed RTKQ to use standard Redux patterns (actions, thunks): https://www.reddit.com/r/reactjs/comments/r7cklo/coding_interview_with_dan_abramov/hmyt9sn/
• Why "put all the logic in a custom middleware" and "having reducers blindly set data" is a bad idea (race conditions, etc): https://mobile.twitter.com/phry/status/1467419844777857025
• "Pure reducers" is more than just a restriction - it's a design philosophy: https://twitter.com/acemarke/status/1482396019417620480

[markerikson]

"Modeling actions as events":

https://www.reddit.com/r/reactjs/comments/oa5pwe/why_is_it_so_difficult_to_modify_a_deeply_nested/h3ip5gj/

When we say "model actions as events", it implies a few different things:

• Naming: "somethingHappened", vs "setThing"
• Mindset: it's not "setters at a distance", it's "broadcast this info, any code that cares can do something with that info"
• Code layout: having more logic in a reducer, vs always calculating the entire state first -> sticking it in the action -> doing return action.payload or state.someValue = action.payload
• Handling logic: it's fine for many reducers to update themselves independently in response

None of that goes away with RTK - it's more about a mental model than specific syntax.

These aren't absolutes, and in some ways it's a hard mindset shift to grasp. And, tbh, most Redux actions will only ever be handled by one slice reducer in practice. But, I've seen folks writing separate setFieldX, setFieldY actions for every individual field in some slice, and that's definitely not the right mental approach.