From 125bd2b52efc70b8a3b46ceeb82c3ee7eb2b75b0 Mon Sep 17 00:00:00 2001 From: Brian Vaughn Date: Thu, 7 Jun 2018 17:31:30 -0400 Subject: [PATCH] Bullet point organization --- .../blog/2018-06-07-you-probably-dont-need-derived-state.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/blog/2018-06-07-you-probably-dont-need-derived-state.md b/content/blog/2018-06-07-you-probably-dont-need-derived-state.md index 86f5223c..70ea5bda 100644 --- a/content/blog/2018-06-07-you-probably-dont-need-derived-state.md +++ b/content/blog/2018-06-07-you-probably-dont-need-derived-state.md @@ -213,9 +213,9 @@ To recap, when designing a component, it is important to decide whether its data Instead of trying to **"mirror" a prop value in state**, make the component **controlled**, and consolidate the two diverging values in the state of some parent component. For example, rather than a child accepting a "committed" `props.value` and tracking a "draft" `state.value`, have the parent manage both `state.draftValue` and `state.committedValue` and control the child's value directly. This makes the data flow more explicit and predictable. For **uncontrolled** components, if you're trying to reset state when a particular prop (usually an ID) changes, you have a few options: -1. **To reset _all internal state_, use the `key` attribute (preferred).** -2. To reset _only certain state fields_, watch for changes in a special property (e.g. `props.userID`). -3. You can also consider fall back to an imperative instance method using refs. +* **Recomendation: To reset _all internal state_, use the `key` attribute.** +* Alternative 1: To reset _only certain state fields_, watch for changes in a special property (e.g. `props.userID`). +* Alternative 2: You can also consider fall back to an imperative instance method using refs. ## What about memoization?