Browse Source

[beta] Reword "action = what happened" advice for useReducer (#4331)

* [beta] Reword "action = what happened" advice for useReducer

One learner misinterpreted the original text here as meaning instead that it's important that actions are written in past tense – this updated wording is clearer about what this is meant to convey (I think).

* typo
main
Sophie Alpert 3 years ago
committed by GitHub
parent
commit
71cc6be618
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
  1. 4
      beta/src/pages/learn/extracting-state-logic-into-a-reducer.md

4
beta/src/pages/learn/extracting-state-logic-into-a-reducer.md

@ -886,7 +886,7 @@ We recommend using a reducer if you often encounter bugs due to incorrect state
Keep these two tips in mind when writing reducers:
* **Reducers must be pure.** Similar to [state updater functions](/learn/queueing-a-series-of-state-updates), reducers run during rendering! (Actions are queued until the next render.) This means that reducers [must be pure](/learn/keeping-components-pure)—same inputs always result in the same output. They should not send requests, schedule timeouts, or perform any side effects (operations that impact things outside the component). They should update [objects](/learn/updating-objects-in-state) and [arrays](/learn/updating-arrays-in-state) without mutations.
* **Actions describe "what happened," not "what to do."** For example, if a user presses "Reset" on a form with five fields managed by a reducer, it makes more sense to dispatch one `reset_form` action rather than five separate `set_field` actions. If you log every action in a reducer, that log should be clear enough for you to reconstruct what interactions or responses happened in what order. This helps with debugging!
* **Each action describes a single user interaction, even if that leads to multiple changes in the data.** For example, if a user presses "Reset" on a form with five fields managed by a reducer, it makes more sense to dispatch one `reset_form` action rather than five separate `set_field` actions. If you log every action in a reducer, that log should be clear enough for you to reconstruct what interactions or responses happened in what order. This helps with debugging!
## Writing concise reducers with Immer {/*writing-concise-reducers-with-immer*/}
@ -1106,7 +1106,7 @@ Reducers must be pure, so they shouldn't mutate state. But Immer provides you wi
3. Replace `useState` with `useReducer`.
* Reducers require you to write a bit more code, but they help with debugging and testing.
* Reducers must be pure.
* Actions describe "what happened," not "what to do."
* Each action describes a single user interaction.
* Use Immer if you want to write reducers in a mutating style.
</Recap>

Loading…
Cancel
Save