diff --git a/beta/package.json b/beta/package.json index 5fdec38465..199b710806 100644 --- a/beta/package.json +++ b/beta/package.json @@ -17,7 +17,7 @@ "start": "next start" }, "dependencies": { - "@codesandbox/sandpack-react": "^0.1.15", + "@codesandbox/sandpack-react": "^0.1.16", "@docsearch/react": "3.0.0-alpha.41", "@docsearch/css": "3.0.0-alpha.41", "@headlessui/react": "^1.3.0", @@ -75,7 +75,7 @@ "reading-time": "^1.2.0", "remark": "^12.0.1", "remark-external-links": "^7.0.0", - "remark-html": "^12.0.0", + "remark-html": "^13.0.2", "remark-images": "^2.0.0", "remark-unwrap-images": "^2.0.0", "retext": "^7.0.1", diff --git a/beta/src/pages/learn/choosing-the-state-structure.md b/beta/src/pages/learn/choosing-the-state-structure.md index d0f3d1d993..a452c97c12 100644 --- a/beta/src/pages/learn/choosing-the-state-structure.md +++ b/beta/src/pages/learn/choosing-the-state-structure.md @@ -26,7 +26,7 @@ When you write a component that holds some state, you'll have to make choices ab 4. **Avoid duplication in state.** When the same data is duplicated between multiple state variables, or within nested objects, it is difficult to keep them in sync. Reduce duplication when you can. 5. **Avoid deeply nested state.** Deeply hierarchical state is not very convenient to update. When possible, prefer to structure state in a flat way. -The goal behind these principles is to *make state easy to update without introducing mistakes*. Removing redundant and duplicate data from state helps ensure that different pieces of it don't get out of sync. This is similar to how a database engineer might want to ["normalize" the database structure](https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) to reduce the chance of bugs. To paraphrase Albert Einstein, **"Make your state as simple as it can be--but no simpler."** +The goal behind these principles is to *make state easy to update without introducing mistakes*. Removing redundant and duplicate data from state helps ensure that all its pieces stay in sync. This is similar to how a database engineer might want to ["normalize" the database structure](https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description) to reduce the chance of bugs. To paraphrase Albert Einstein, **"Make your state as simple as it can be--but no simpler."** Now let's see how these principles apply in action. @@ -47,7 +47,7 @@ Or this? const [position, setPosition] = useState({ x: 0, y: 0 }); ``` -Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable**. Then you won't forget to always keep them in sync, like in this example where hovering updates both of the red dot's coordinates: +Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable**. Then you won't forget to always keep them in sync, like in this example where moving the cursor updates both coordinates of the red dot: @@ -96,20 +96,20 @@ Another case where you'll group data into an object or an array is when you don' -If your state variable is an object, remember that you can't update only one field in it without explicitly copying the other fields. For example, you can't do `setPosition({ x: 100 })` in the above example because it would not have the `y` property at all! Instead, if you wanted to set `x` alone, you would either do `setPosition({ ...position, x: 100 })` or you would need to split them into two state variables, and do `setX(100)`. +If your state variable is an object, remember that [you can't update only one field in it](/learn/updating-objects-in-state) without explicitly copying the other fields. For example, you can't do `setPosition({ x: 100 })` in the above example because it would not have the `y` property at all! Instead, if you wanted to set `x` alone, you would either do `setPosition({ ...position, x: 100 })`, or split them into two state variables and do `setX(100)`. ## Avoid contradictions in state -Here is a form with `isSending` and `isSent` state variables: +Here is a hotel feedback form with `isSending` and `isSent` state variables: ```js import { useState } from 'react'; -export default function Chat() { +export default function FeedbackForm() { const [text, setText] = useState(''); const [isSending, setIsSending] = useState(false); const [isSent, setIsSent] = useState(false); @@ -123,16 +123,18 @@ export default function Chat() { } if (isSent) { - return

Sent!

+ return

Thanks for feedback!

} return (
- How was your stay at The Prancing Pony?

+ -
+
-

Thank you!

+

That's right!

+ + ``` -Manipulating the UI works well enough for isolated examples, but it gets exponentially more difficult to manage in more complex systems. Imagine updating a page full of different forms like this one. Adding a new UI element or a new interaction would require carefully checking all existing code to make sure you haven't introduced a bug (for example, forgetting to show or hide something). +Manipulating the UI imperatively works well enough for isolated examples, but it gets exponentially more difficult to manage in more complex systems. Imagine updating a page full of different forms like this one. Adding a new UI element or a new interaction would require carefully checking all existing code to make sure you haven't introduced a bug (for example, forgetting to show or hide something). React was built to solve this problem. -In React, you don't directly manipulate the UI--meaning you don't enable, disable, show, or hide components directly. Instead, you **declare what you want to show**, and React figures out how to update the UI. Think of getting into a taxi and telling the driver where you want to go instead of telling them exactly where to turn. It's the driver's job to get you there, and they might even know some shortcuts you hadn't considered! +In React, you don't directly manipulate the UI--meaning you don't enable, disable, show, or hide components directly. Instead, you **declare what you want to show**, and React figures out how to update the UI. Think of getting into a taxi and telling the driver where you want to go instead of telling them exactly where to turn. It's the driver's job to get you there, and they might even know some shortcuts you haven't considered! @@ -141,7 +151,7 @@ You've seen how to implement a form imperatively above. To better understand how ### Step 1: Identify your component's different visual states -In computer science, you may hear about a ["state machine"](https://en.wikipedia.org/wiki/Finite-state_machine) being in one of several “states”. If you work with a designer, you may have seen visual mockups for different states. Designers work with visual states all the time. React stands at the intersection of design and computer science, so both of these ideas are sources of inspiration. +In computer science, you may hear about a ["state machine"](https://en.wikipedia.org/wiki/Finite-state_machine) being in one of several “states”. If you work with a designer, you may have seen mockups for different "visual states". React stands at the intersection of design and computer science, so both of these ideas are sources of inspiration. First, you need to visualize all the different "states" of the UI the user might see: @@ -156,58 +166,68 @@ Just like a designer, you'll want to "mock up" or create "mocks" for the differe ```js -export default function FeedbackForm({ +export default function Form({ status = 'empty' }) { if (status === 'success') { - return

Thank you!

+ return

That's right!

} return ( -
-