reduxjs/redux

[Docs Rewrite] Meta-Issue: Understanding Redux section

markerikson opened this issue · 6 comments

markerikson commented

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 commented

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

markerikson commented

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:

  • 👍3
markerikson commented

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

markerikson commented

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 commented

More bookmarks that could be useful:

markerikson commented

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