[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

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>