diff --git a/beta/src/content/learn/reacting-to-input-with-state.md b/beta/src/content/learn/reacting-to-input-with-state.md index 58bda220d6..11ec0f889c 100644 --- a/beta/src/content/learn/reacting-to-input-with-state.md +++ b/beta/src/content/learn/reacting-to-input-with-state.md @@ -1,37 +1,41 @@ --- -title: Reacting to Input with State +title: 用 State 响应输入 +translators: + - BBboy01 + - KimYangOfCat + - TinaaaaP --- -React uses a declarative way to manipulate the UI. Instead of manipulating individual pieces of the UI directly, you describe the different states that your component can be in, and switch between them in response to the user input. This is similar to how designers think about the UI. +React 控制 UI 的方式是声明式的。你不必直接控制 UI 的各个部分，只需要声明组件可以处于的不同状态，并根据用户的输入在它们之间切换。这与设计师对 UI 的思考方式很相似。 -* How declarative UI programming differs from imperative UI programming -* How to enumerate the different visual states your component can be in -* How to trigger the changes between the different visual states from code +* 了解声明式 UI 编程与命令式 UI 编程有何不同 +* 了解如何列举组件可能处于的不同视图状态 +* 了解如何在代码中触发不同视图状态的变化 -## How declarative UI compares to imperative {/*how-declarative-ui-compares-to-imperative*/} +## 声明式 UI 与命令式 UI 的比较 {/*how-declarative-ui-compares-to-imperative*/} -When you design UI interactions, you probably think about how the UI *changes* in response to user actions. Consider a form that lets the user submit an answer: +当你设计 UI 交互时，可能会去思考 UI 如何根据用户的操作而响应**变化**。想象一个允许用户提交一个答案的表单： -* When you type something into a form, the "Submit" button **becomes enabled.** -* When you press "Submit", both form and the button **become disabled,** and a spinner **appears.** -* If the network request succeeds, the form **gets hidden,** and the "Thank you" message **appears.** -* If the network request fails, an error message **appears,** and the form **becomes enabled** again. +* 当你向表单输入数据时，“提交”按钮会随之变成**可用状态** +* 当你点击“提交”后，表单和提交按钮都会随之变成**不可用状态**，并且会加载动画会随之**出现** +* 如果网络请求成功，表单会随之**隐藏**，同时“提交成功”的信息会随之**出现** +* 如果网络请求失败，错误信息会随之**出现**，同时表单又变为**可用状态** -In **imperative programming,** the above corresponds directly to how you implement interaction. You have to write the exact instructions to manipulate the UI depending on what just happened. Here's another way to think about this: imagine riding next to someone in a car and telling them turn by turn where to go. +在 **命令式编程** 中，以上的过程直接告诉你如何去实现交互。你必须去根据要发生的事情写一些明确的命令去操作 UI。对此有另一种理解方式，想象一下，当你坐在车里的某个人旁边，然后一步一步地告诉他该去哪。 - + -They don't know where you want to go, they just follow your commands. (And if you get the directions wrong, you end up in the wrong place!) It's called *imperative* because you have to "command" each element, from the spinner to the button, telling the computer *how* to update the UI. +他并不知道你想去哪，只想跟着命令行动。（并且如果你发出了错误的命令，那么你就会到达错误的地方）正因为你必须从加载动画到按钮地“命令”每个元素，所以这种告诉计算机*如何*去更新 UI 的编程方式被称为*命令式编程* -In this example of imperative UI programming, the form is built *without* React. It uses the built-in browser [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model): +在这个命令式 UI 编程的例子中，表单**没有使用** React 生成，而是使用原生的 [DOM](https://developer.mozilla.org/zh-CN/docs/Web/API/Document_Object_Model): @@ -131,37 +135,37 @@ body { font-family: sans-serif; margin: 20px; padding: 0; } -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). +对于独立系统来说，命令式地控制用户界面的效果也不错，但是当处于更加复杂的系统中时，这会造成管理的困难程度指数级地增长。如同示例一样，想象一下，当你想更新这样一个包含着不同表单的页面时，你想要添加一个新 UI 元素或一个新的交互，为了保证不会因此产生新的 bug（例如忘记去显示或隐藏一些东西），你必须十分小心地去检查所有已经写好的代码。 -React was built to solve this problem. +React 正是为了解决这样的问题而诞生的。 -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! +在 React 中，你不必直接去操作 UI —— 你不必直接启用、关闭、显示或隐藏组件。相反，你只需要 **声明你想要显示的内容，** React 就会通过计算得出该如何去更新 UI。想象一下，当你上了一辆出租车并且告诉司机你想去哪，而不是事无巨细地告诉他该如何走。将你带到目的地是司机的工作，他们甚至可能知道一些你没有想过并且不知道的捷径！ - + -## Thinking about UI declaratively {/*thinking-about-ui-declaratively*/} +## 声明式地考虑 UI {/*thinking-about-ui-declaratively*/} -You've seen how to implement a form imperatively above. To better understand how to think in React, you'll walk through reimplementing this UI in React below: +你已经从上面的例子看到如何去实现一个表单了，为了更好地理解如何在 React 中思考，接下来你将会学到如何用 React 重新实现这个 UI： -1. **Identify** your component's different visual states -2. **Determine** what triggers those state changes -3. **Represent** the state in memory using `useState` -4. **Remove** any non-essential state variables -5. **Connect** the event handlers to set the state +1. **定位**你的组件中不同的视图状态 +2. **确定**是什么触发了这些 state 的改变 +3. **表示**内存中的 state（需要使用 `useState`） +4. **删除**任何不必要的 state 变量 +5. **连接**事件处理函数去设置 state -### Step 1: Identify your component's different visual states {/*step-1-identify-your-components-different-visual-states*/} +### 步骤 1：定位组件中不同的视图状态 {/*step-1-identify-your-components-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 mockups for different "visual states". React stands at the intersection of design and computer science, so both of these ideas are sources of inspiration. +在计算机科学中，你或许听过可处于多种“状态”之一的 [“状态机”](https://en.wikipedia.org/wiki/Finite-state_machine)。如果你有与设计师一起工作，那么你可能已经见过不同“视图状态”的模拟图。正因为 React 站在设计与计算机科学的交点上，因此这两种思想都是灵感的来源。 -First, you need to visualize all the different "states" of the UI the user might see: +首先，你需要去可视化 UI 界面中用户可能看到的所有不同的“状态”： -* **Empty**: Form has a disabled "Submit" button. -* **Typing**: Form has an enabled "Submit" button. -* **Submitting**: Form is completely disabled. Spinner is shown. -* **Success**: "Thank you" message is shown instead of a form. -* **Error**: Same as Typing state, but with an extra error message. +* **无数据**：表单有一个不可用状态的“提交”按钮。 +* **输入中**：表单有一个可用状态的“提交”按钮。 +* **提交中**：表单完全处于不可用状态，加载动画出现。 +* **成功时**：显示“成功”的消息而非表单。 +* **错误时**：与输入状态类似，但会多错误的消息。 -Just like a designer, you'll want to "mock up" or create "mocks" for the different states before you add logic. For example, here is a mock for just the visual part of the form. This mock is controlled by a prop called `status` with a default value of `'empty'`: +像一个设计师一样，你会想要在你添加逻辑之前去“模拟”不同的状态或创建“模拟状态”。例如下面的例子，这是一个对表单可视部分的模拟。这个模拟被一个 `status` 的属性控制，并且这个属性的默认值为 `empty`。 @@ -192,7 +196,7 @@ export default function Form({ -You could call that prop anything you like, the naming is not important. Try editing `status = 'empty'` to `status = 'success'` to see the success message appear. Mocking lets you quickly iterate on the UI before you wire up any logic. Here is a more fleshed out prototype of the same component, still "controlled" by the `status` prop: +你可以随意命名这个属性，名字并不重要。试着将 `status = 'empty'` 改为 `status = 'success'`，然后你就会看到成功的信息出现。模拟可以让你在书写逻辑前快速迭代 UI。这是同一组件的一个更加充实的原型，仍然由 `status` 属性“控制”： @@ -240,9 +244,9 @@ export default function Form({ -#### Displaying many visual states at once {/*displaying-many-visual-states-at-once*/} +#### 同时展示大量的视图状态 {/*displaying-many-visual-states-at-once*/} -If a component has a lot of visual states, it can be convenient to show them all on one page: +如果一个组件有多个视图状态，你可以很方便地将它们展示在一个页面中： @@ -307,57 +311,58 @@ body { margin: 0; } -Pages like this are often called "living styleguides" or "storybooks". +类似这样的页面通常被称作“living styleguide”或“storybook”。 -### Step 2: Determine what triggers those state changes {/*step-2-determine-what-triggers-those-state-changes*/} +### 步骤 2：确定是什么触发了这些状态的改变 {/*step-2-determine-what-triggers-those-state-changes*/} -You can trigger state updates in response to two kinds of inputs: +你可以触发 state 的更新来响应两种输入： -* **Human inputs,** like clicking a button, typing in a field, navigating a link. -* **Computer inputs,** like a network response arriving, a timeout completing, an image loading. +- **人为**输入。比如点击按钮、在表单中输入内容，或导航到链接。 +- **计算机**输入。比如网络请求得到反馈、定时器被触发，或加载一张图片。 - - - + + + + -In both cases, **you must set [state variables](/learn/state-a-components-memory#anatomy-of-usestate) to update the UI.** For the form you're developing, you will need to change state in response to a few different inputs: +以上两种情况中，**你必须设置 [state 变量](/learn/state-a-components-memory#anatomy-of-usestate) 去更新 UI**。对于正在开发中的表单来说，你需要改变 state 以响应几个不同的输入： -* **Changing the text input** (human) should switch it from the *Empty* state to the *Typing* state or back, depending on whether the text box is empty or not. -* **Clicking the Submit button** (human) should switch it to the *Submitting* state. -* **Successful network response** (computer) should switch it to the *Success* state. -* **Failed network response** (computer) should switch it to the *Error* state with the matching error message. +* **改变输入框中的文本时**（人为）应该根据输入框的内容是否是**空值**，从而决定将表单的状态从空值状态切换到**输入中**或切换回原状态。 +* **点击提交按钮时**（人为）应该将表单的状态切换到**提交中**的状态。 +* **网络请求成功后**（计算机）应该将表单的状态切换到**成功**的状态。 +* **网络请求失败后**（计算机）应该将表单的状态切换到**失败**的状态，与此同时，显示错误信息。 -> Notice that human inputs often require [event handlers](/learn/responding-to-events)! +> 注意，人为输入通常需要 [事件处理函数](/learn/responding-to-events)！ -To help visualize this flow, try drawing each state on paper as a labeled circle, and each change between two states as an arrow. You can sketch out many flows this way and sort out bugs long before implementation. +为了可视化这个流程，请尝试在纸上画出圆形标签以表示每个状态，两个状态之间的改变用箭头表示。你可以像这样画出很多流程并且在写代码前解决许多 bug。 - + -Form states +表单的各种状态 -### Step 3: Represent the state in memory with `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/} +### 步骤 3：通过 `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/} 表示内存中的 state -Next you'll need to represent the visual states of your component in memory with [`useState`.](/reference/react/useState) Simplicity is key: each piece of state is a "moving piece", and **you want as few "moving pieces" as possible.** More complexity leads to more bugs! +接下来你会需要在内存中通过 [`useState`](/reference/react/useState) 表示组件中的视图状态。诀窍很简单：state 的每个部分都是“处于变化中的”，并且**你需要让“变化的部分”尽可能的少**。更复杂的程序会产生更多 bug！ -Start with the state that *absolutely must* be there. For example, you'll need to store the `answer` for the input, and the `error` (if it exists) to store the last error: +先从*绝对必须*存在的状态开始。例如，你需要存储输入的 `answer` 以及用于存储最后一个错误的 `error` （如果存在的话）： ```js const [answer, setAnswer] = useState(''); const [error, setError] = useState(null); ``` -Then, you'll need a state variable representing which one of the visual states described earlier you want to display. There's usually more than a single way to represent that in memory, so you'll need to experiment with it. +之后你需要一个 state 变量来表示你想显示前面描述的哪一种视觉状态。通常不止一种在内存中表示的方法，因此你需要试验一下。 -If you struggle to think of the best way immediately, start by adding enough state that you're *definitely* sure that all the possible visual states are covered: +如果你很难立即想出最好的办法，那就先从添加足够多的 state 开始，*确保*所有可能的视图状态都囊括其中： ```js const [isEmpty, setIsEmpty] = useState(true); @@ -367,19 +372,19 @@ const [isSuccess, setIsSuccess] = useState(false); const [isError, setIsError] = useState(false); ``` -Your first idea likely won't be the best, but that's ok--refactoring state is a part of the process! +你最初的想法或许不是最好的，但是没关系，重构 state 也是步骤中的一部分！ -### Step 4: Remove any non-essential state variables {/*step-4-remove-any-non-essential-state-variables*/} +### 步骤 4：删除任何不必要的 state 变量 {/*step-4-remove-any-non-essential-state-variables*/} -You want to avoid duplication in the state content so you're only tracking what is essential. Spending a little time on refactoring your state structure will make your components easier to understand, reduce duplication, and avoid unintended meanings. Your goal is to **prevent the cases where the state in memory doesn't represent any valid UI that you'd want a user to see.** (For example, you never want to show an error message and disable the input at the same time, or the user won't be able to correct the error!) +你会想要避免 state 内容中的重复，从而只需要关注那些必要的部分。花一点时间来重构你的 state 结构，会让你的组件更容易被理解，减少重复并且避免歧义。你的目的是**防止出现在内存中的 state 不代表任何你希望用户看到的有效 UI 的情况。**（比如你绝对不会想要在展示错误信息的同时禁用掉输入框，导致用户无法纠正错误！） -Here are some questions you can ask about your state variables: +这有一些你可以问自己的， 关于 state 变量的问题： -* **Does this state cause a paradox?** For example, `isTyping` and `isSubmitting` can't both be `true`. A paradox usually means that the state is not constrained enough. There are four possible combinations of two booleans, but only three correspond to valid states. To remove the "impossible" state, you can combine these into a `status` that must be one of three values: `'typing'`, `'submitting'`, or `'success'`. -* **Is the same information available in another state variable already?** Another paradox: `isEmpty` and `isTyping` can't be `true` at the same time. By making them separate state variables, you risk them going out of sync and causing bugs. Fortunately, you can remove `isEmpty` and instead check `answer.length === 0`. -* **Can you get the same information from the inverse of another state variable?** `isError` is not needed because you can check `error !== null` instead. +* **这个 state 是否会导致矛盾？**例如，`isTyping` 与 `isSubmitting` 的状态不能同时为 `true`。矛盾的产生通常说明了这个 state 没有足够的约束条件。两个布尔值有四种可能的组合，但是只有三种对应有效的状态。为了将“不可能”的状态移除，你可以将 `'typing'`、`'submitting'` 以及 `'success'` 这三个中的其中一个与 `status` 结合。 +* **相同的信息是否已经在另一个 state 变量中存在？**另一个矛盾：`isEmpty` 和 `isTyping` 不能同时为 `true`。通过使它们成为独立的 state 变量，可能会导致它们不同步并导致 bug。幸运的是，你可以移除 `isEmpty` 转而用 `message.length === 0`。 +* **你是否可以通过另一个 state 变量的相反值得到相同的信息？**`isError` 是多余的，因为你可以检查 `error !== null`。 -After this clean-up, you're left with 3 (down from 7!) *essential* state variables: +在清理之后，你只剩下 3 个（从原本的 7 个！）*必要*的 state 变量： ```js const [answer, setAnswer] = useState(''); @@ -387,19 +392,19 @@ const [error, setError] = useState(null); const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success' ``` -You know they are essential, because you can't remove any of them without breaking the functionality. +正是因为你不能在不破坏功能的情况下删除其中任何一个状态变量，因此你可以确定这些都是必要的。 -#### Eliminating “impossible” states with a reducer {/*eliminating-impossible-states-with-a-reducer*/} +#### 通过 reducer 来减少“不可能” state {/*eliminating-impossible-states-with-a-reducer*/} -These three variables are a good enough representation of this form's state. However, there are still some intermediate states that don't fully make sense. For example, a non-null `error` doesn't make sense when `status` is `'success'`. To model the state more precisely, you can [extract it into a reducer.](/learn/extracting-state-logic-into-a-reducer) Reducers let you unify multiple state variables into a single object and consolidate all the related logic! +尽管这三个变量对于表示这个表单的状态来说已经足够好了，仍然是有一些中间状态并不是完全有意义的。例如一个非空的 `error` 当 `status` 的值为 `success` 时没有意义。为了更精确地模块化状态，你可以 [将状态提取到一个 reducer 中](/learn/extracting-state-logic-into-a-reducer)。Reducer 可以让您合并多个状态变量到一个对象中并巩固所有相关的逻辑！ -### Step 5: Connect the event handlers to set state {/*step-5-connect-the-event-handlers-to-set-state*/} +### 步骤 5：连接事件处理函数以设置 state {/*step-5-connect-the-event-handlers-to-set-state*/} -Lastly, create event handlers to set the state variables. Below is the final form, with all event handlers wired up: +最后，创建事件处理函数去设置 state 变量。下面是绑定好事件的最终表单： @@ -481,17 +486,17 @@ function submitForm(answer) { -Although this code is longer than the original imperative example, it is much less fragile. Expressing all interactions as state changes lets you later introduce new visual states without breaking existing ones. It also lets you change what should be displayed in each state without changing the logic of the interaction itself. +尽管这些代码相对与最初的命令式的例子来说更长，但是却更加健壮。将所有的交互变为 state 的改变，可以让你避免之后引入新的视图状态后导致现有 state 被破坏。同时也使你在不必改变交互逻辑的情况下，更改每个状态对应的 UI。 -* Declarative programming means describing the UI for each visual state rather than micromanaging the UI (imperative). -* When developing a component: - 1. Identify all its visual states. - 2. Determine the human and computer triggers for state changes. - 3. Model the state with `useState`. - 4. Remove non-essential state to avoid bugs and paradoxes. - 5. Connect the event handlers to set state. +* 声明式编程意味着为每个视图状态声明 UI 而非细致地控制 UI（命令式）。 +* 当开发一个组件时： + 1. 写出你的组件中所有的视图状态。 + 2. 确定是什么触发了这些 state 的改变。 + 3. 通过 `useState` 模块化内存中的 state。 + 4. 删除任何不必要的 state 变量。 + 5. 连接事件处理函数去设置 state。 @@ -499,11 +504,11 @@ Although this code is longer than the original imperative example, it is much le -#### Add and remove a CSS class {/*add-and-remove-a-css-class*/} +#### 添加和删除一个 CSS class {/*add-and-remove-a-css-class*/} -Make it so that clicking on the picture *removes* the `background--active` CSS class from the outer `
`, but *adds* the `picture--active` class to the ``. Clicking the background again should restore the original CSS classes. +尝试实现当点击图片时*删除*外部 `
` 的 CSS class `background--active`，并将 `picture--active` 的 CSS class 添加到 `` 上。当再次点击背景图片时将恢复最开始的 CSS class。 -Visually, you should expect that clicking on the picture removes the purple background and highlights the picture border. Clicking outside the picture highlights the background, but removes the picture border highlight. +视觉上，你应该期望当点击图片时会移除紫色的背景，并且高亮图片的边框。点击图片外面时高亮背景并且删除图片边框的高亮效果。 @@ -552,14 +557,14 @@ body { margin: 0; padding: 0; height: 250px; } -This component has two visual states: when the image is active, and when the image is inactive: +这个组件有两个视图状态：当图片处于激活状态时以及当图片处于非激活状态时： -* When the image is active, the CSS classes are `background` and `picture picture--active`. -* When the image is inactive, the CSS classes are `background background--active` and `picture`. +* 当图片处于激活状态时，CSS class 是 `background` 和 `picture picture--active`。 +* 当图片处于非激活状态时，CSS class 是 `background background--active` 和 `picture`。 -A single boolean state variable is enough to remember whether the image is active. The original task was to remove or add CSS classes. However, in React you need to *describe* what you want to see rather than *manipulate* the UI elements. So you need to calculate both CSS classes based on the current state. You also need to [stop the propagation](/learn/responding-to-events#stopping-propagation) so that clicking the image doesn't register as a click on the background. +一个布尔类型的 state 已经足够表示图片是否处于激活状态。最初的工作仅仅是移除或添加 CSS class。然而在 React 中你需要去*描述*什么是你想要看到的而非*操作* UI 元素。因此你需要基于当前 state 去计算这两个 CSS class。同时你需要去 [阻止冒泡行为](/learn/responding-to-events#stopping-propagation)，只有这样点击图片的时候不会触发点击背景的回调。 -Verify that this version works by clicking the image and then outside of it: +通过点击图片然后点击图片外围来确定这个版本可用： @@ -626,7 +631,7 @@ body { margin: 0; padding: 0; height: 250px; } -Alternatively, you could return two separate chunks of JSX: +或者，你可以返回两个单独的 JSX 代码块： @@ -693,13 +698,13 @@ body { margin: 0; padding: 0; height: 250px; } -Keep in mind that if two different JSX chunks describe the same tree, their nesting (first `
` → first ``) has to line up. Otherwise, toggling `isActive` would recreate the whole tree below and [reset its state.](/learn/preserving-and-resetting-state) This is why, if a similar JSX tree gets returned in both cases, it is better to write them as a single piece of JSX. +请记住，如果两个不同的 JSX 代码块描述着相同的树结构，它们的嵌套（第一个 `
` → 第一个 ``）必须对齐。否则切换 `isActive` 会再次在后面创建整个树结构并且 [重置 state](/learn/preserving-and-resetting-state)。这也就是为什么当一个相似的 JSX 树结构在两个情况下都返回的时候，最好将它们写成一个单独的 JSX。 -#### Profile editor {/*profile-editor*/} +#### 个人信息编辑器 {/*profile-editor*/} -Here is a small form implemented with plain JavaScript and DOM. Play with it to understand its behavior: +这是一个通过纯 JavaScript 和 DOM 实现的小型表单。先来随便使用一下来看看它有什么功能吧： @@ -796,11 +801,11 @@ label { display: block; margin-bottom: 20px; } -This form switches between two modes: in the editing mode, you see the inputs, and in the viewing mode, you only see the result. The button label changes between "Edit" and "Save" depending on the mode you're in. When you change the inputs, the welcome message at the bottom updates in real time. +这个表单在两种模式间切换：编辑模式，你可以看到输入框；查看模式，你只能看到结果。按钮的标签会根据你所处的模式在“编辑”和“保存”两者中切换。当你改变输入框的内容时，欢迎信息会最下面实时更新。 -Your task is to reimplement it in React in the sandbox below. For your convenience, the markup was already converted to JSX, but you'll need to make it show and hide the inputs like the original does. +你的任务是在下方的沙盒中用 React 再次实现它。为了方便，标记已经转换为 JSX，但是你需要让它像原版那样显示和隐藏输入框。 -Make sure that it updates the text at the bottom, too! +也要确保它在底下更新文本内容！ @@ -835,9 +840,9 @@ label { display: block; margin-bottom: 20px; } -You will need two state variables to hold the input values: `firstName` and `lastName`. You're also going to need an `isEditing` state variable that holds whether to display the inputs or not. You should _not_ need a `fullName` variable because the full name can always be calculated from the `firstName` and the `lastName`. +你需要两个 state 变量来保存输入框中的内容：`firstName` 和 `lastName`。同时你还会需要一个 `isEditing` 的 state 变量来保存是否显示输入框的状态。你应该*不*需要 `fullName` 变量，因为全名可以由`firstName` 和 `lastName` 组合而成。 -Finally, you should use [conditional rendering](/learn/conditional-rendering) to show or hide the inputs depending on `isEditing`. +最终，你应该根据 `isEditing` 的值使用 [条件渲染](/learn/conditional-rendering) 来决定显示还是隐藏输入框。 @@ -895,13 +900,13 @@ label { display: block; margin-bottom: 20px; } -Compare this solution to the original imperative code. How are they different? +这个解决方案与最初命令式的代码相比，它们有什么不同？ -#### Refactor the imperative solution without React {/*refactor-the-imperative-solution-without-react*/} +#### 不使用 React 去重构命令式的解决方案 {/*refactor-the-imperative-solution-without-react*/} -Here is the original sandbox from the previous challenge, written imperatively without React: +这是之前的挑战中的没有使用 React 而写的命令式代码： @@ -998,9 +1003,9 @@ label { display: block; margin-bottom: 20px; } -Imagine React didn't exist. Can you refactor this code in a way that makes the logic less fragile and more similar to the React version? What would it look like if the state was explicit, like in React? +如果不用 React，你能否将这段代码重构得像 React 版本一样健壮？如果要让它的 state 像 React 版本一样清晰且明确，那么这段代码又会写成怎样的呢？ -If you're struggling to think where to start, the stub below already has most of the structure in place. If you start here, fill in the missing logic in the `updateDOM` function. (Refer to the original code where needed.) +如果你不知道该从哪里入手，下面的代码已经有了大部分的结构。如果你从这里开始的话，只需要在 `updateDOM` 函数中补充缺失的逻辑即可。（需要时请参考原始代码） @@ -1107,7 +1112,7 @@ label { display: block; margin-bottom: 20px; } -The missing logic included toggling the display of inputs and content, and updating the labels: +缺失的逻辑包括切换输入框和内容的显示以及更新标签的内容： @@ -1224,7 +1229,7 @@ label { display: block; margin-bottom: 20px; } -The `updateDOM` function you wrote shows what React does under the hood when you set the state. (However, React also avoids touching the DOM for properties that have not changed since the last time they were set.) +你所写的 `updateDOM` 函数展示了当你设置 state 时，React 在幕后都做了什么。（而且 React 不会修改对应 state 没改变的 DOM）