From 71cc6be6182418dec43b72f2a9ef464619cb7025 Mon Sep 17 00:00:00 2001 From: Sophie Alpert Date: Sat, 12 Feb 2022 16:54:41 -0800 Subject: [PATCH] [beta] Reword "action = what happened" advice for useReducer (#4331) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * [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 --- beta/src/pages/learn/extracting-state-logic-into-a-reducer.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/beta/src/pages/learn/extracting-state-logic-into-a-reducer.md b/beta/src/pages/learn/extracting-state-logic-into-a-reducer.md index 3fe153b7..a8078d03 100644 --- a/beta/src/pages/learn/extracting-state-logic-into-a-reducer.md +++ b/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.