From 942f80af9e068902cedec075023069da04c1c727 Mon Sep 17 00:00:00 2001
From: BBboy01 <1156678002@qq.com>
Date: Sat, 11 Dec 2021 21:20:28 +0800
Subject: [PATCH 01/11] docs(cn): reacting-to-input-with-state

---
 .../learn/reacting-to-input-with-state.md     | 273 +++++++++---------
 1 file changed, 138 insertions(+), 135 deletions(-)

diff --git a/beta/src/pages/learn/reacting-to-input-with-state.md b/beta/src/pages/learn/reacting-to-input-with-state.md
index ead3ea5639..f17b368e95 100644
--- a/beta/src/pages/learn/reacting-to-input-with-state.md
+++ b/beta/src/pages/learn/reacting-to-input-with-state.md
@@ -1,37 +1,39 @@
 ---
-title: Reacting to Input with State
+title: 状态响应输入
+translators:
+  - BBboy01
 ---
 
 <Intro>
 
-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 很相似。
 
 </Intro>
 
 <YouWillLearn>
 
-* 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 编程有何不同
+* 了解如何列举你的组件可以处于的视图状态的不同
+* 了解如何在代码中触发不同视图状态的变化
 
 </YouWillLearn>
 
-## 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。有这样一个场景去理解这些，当你坐在车里的某个人旁边，然后一步一步地告诉他该去哪。
 
-<Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="In a car driven by an anxious-looking person representing JavaScript, a passenger orders the driver to execute a sequence of complicated turn by turn navigations." />
+<Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="看起来很焦急的司机代表 JavaScript，乘客命令司机执行一系列复杂的转弯导航。" />
 
-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/en-US/docs/Web/API/Document_Object_Model):
 
 <Sandpack>
 
@@ -81,7 +83,7 @@ function disable(el) {
 }
 
 function submitForm(answer) {
-  // Pretend it's hitting the network.
+  // 假设正在进行网络请求
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       if (answer.toLowerCase() == 'istanbul') {
@@ -111,17 +113,17 @@ textarea.oninput = handleTextareaChange;
 
 ```html public/index.html
 <form id="form">
-  <h2>City quiz</h2>
+  <h2>城市测验</h2>
   <p>
-    What city is located on two continents?
+    哪个城市位于两个大陆上？
   </p>
   <textarea id="textarea"></textarea>
   <br />
-  <button id="button" disabled>Submit</button>
-  <p id="loading" style="display: none">Loading...</p>
+  <button id="button" disabled>提交</button>
+  <p id="loading" style="display: none">加载中...</p>
   <p id="error" style="display: none; color: red;"></p>
 </form>
-<h1 id="success" style="display: none">That's right!</h1>
+<h1 id="success" style="display: none">回答正确！</h1>
 
 <style>
 * { box-sizing: border-box; }
@@ -131,37 +133,37 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
 
 </Sandpack>
 
-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 的工作十分方便，但是当处于更加复杂的系统中时，这会造成在困难程度指数级地增长。想象一下，当你更新一个充满着不同的类似这个例子中的表单的页面时，添加一个新 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。想象一下当你上了一辆出租车并且告诉司机你想去哪，而不是事无巨细地告诉他该如何走，将你带到目的地是司机的工作，他们甚至可能知道一些你没有想过并且不知道的捷径！
 
-<Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="In a car driven by React, a passenger asks to be taken to a specific place on the map. React figures out how to do that." />
+<Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="React 开着车，一个乘客想要去一个地图上的一个明确的地方。React 会思考如何带你到目的地。" />
 
-## 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. **确定**是什么触发了这些状态的改变
+3. **表示**内存中的状态，通过 `useState`
+4. **删除**任何不必要的状态变量
+5.  **连接**事件处理函数去设置状态
 
-### 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`。
 
 <Sandpack>
 
@@ -170,19 +172,19 @@ export default function Form({
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>回答正确！</h1>
   }
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>城市测验</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        哪个城市有把空气转化为饮用水的广告牌？
       </p>
       <form>
         <textarea />
         <br />
         <button>
-          Submit
+          提交
         </button>
       </form>
     </>
@@ -192,23 +194,23 @@ export default function Form({
 
 </Sandpack>
 
-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` 属性“控制”：
 
 <Sandpack>
 
 ```js
 export default function Form({
-  // Try 'submitting', 'error', 'success':
+  // 试一下 'submitting', 'error', 'success'：
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>回答正确！</h1>
   }
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>城市测验</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        哪个城市有把空气转化为饮用水的广告牌？
       </p>
       <form>
         <textarea disabled={
@@ -219,11 +221,11 @@ export default function Form({
           status === 'empty' ||
           status === 'submitting'
         }>
-          Submit
+          提交
         </button>
         {status === 'error' &&
           <p className="Error">
-            Good guess but a wrong answer. Try again!
+            猜得好，但答案是错的。再试一次！
           </p>
         }
       </form>
@@ -238,9 +240,9 @@ export default function Form({
 
 </Sandpack>
 
-<DeepDive title="Displaying many visual states at once">
+<DeepDive title="同时展示大量的视图状态">
 
-If a component has a lot of visual states, it can be convenient to show them all on one page:
+如果一个组件有许多视图数据，你可以很方便地将它们展示在一个页面中：
 
 <Sandpack>
 
@@ -260,7 +262,7 @@ export default function App() {
     <>
       {statuses.map(status => (
         <section key={status}>
-          <h4>Form ({status}):</h4>
+          <h4>表单 ({status}):</h4>
           <Form status={status} />
         </section>
       ))}
@@ -272,7 +274,7 @@ export default function App() {
 ```js Form.js
 export default function Form({ status }) {
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>回答正确！</h1>
   }
   return (
     <form>
@@ -288,7 +290,7 @@ export default function Form({ status }) {
       </button>
       {status === 'error' &&
         <p className="Error">
-          Good guess but a wrong answer. Try again!
+          猜得好，但答案是错的。再试一次!
         </p>
       }
     </form>
@@ -305,49 +307,49 @@ body { margin: 0; }
 
 </Sandpack>
 
-Pages like this are often called "living styleguides" or "storybooks."
+类似这样的页面通常以“实时样式参考”或“故事书”的名字被人们熟知。
 
 </DeepDive>
 
-### 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*/}
 
-<IllustrationBlock title="Types of inputs">
-  <Illustration caption="Human inputs" alt="A finger." src="/images/docs/illustrations/i_inputs1.png" />
-  <Illustration caption="Computer inputs" alt="Ones and zeroes." src="/images/docs/illustrations/i_inputs2.png" />
+<IllustrationBlock title="输入的类型">
+  <Illustration caption="人为输入" alt="一个手指。" src="/images/docs/illustrations/i_inputs1.png" />
+  <Illustration caption="计算机输入" alt="许多的 0 和 1。" src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>
 
-You can trigger state updates in response to two kinds of inputs:
+你可以触发状态更新来响应两种输入：
 
-* **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:
+以上两种情况中，**你必须设置 [状态变量](/learn/state-a-components-memory#anatomy-of-usestate)去更新 UI**。对于正在开发中的表单来说，你需要改变状态以响应几个不同的输入：
 
-* **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。
 
-<img alt="A flow chart showing states and transitions between them" src="/images/docs/sketches/s_flow-chart.jpg" />
+<img alt="显示状态和状态之间转换的流程图" src="/images/docs/sketches/s_flow-chart.jpg" />
 
-### 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*/}
 
-Next you'll need to represent the visual states of your component in memory with [`useState`](/reference/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/usestate) 表示组件中的视图状态。诀窍就是简单：状态每个部分都是“移动中的部分”，并且**你想要“移动中的部分”尽可能的少**。太复杂的话会产生更多 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:
+先从*绝对必须*存在的状态开始。例如，你需要存储输入的 `message` 以及存储最后一个错误的 `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.
+之后你需要一个变量来表示你之前声明过想要展示的视图状态中的一个。这有不止一种方法在可以在内存中将之表示，因此你需要来体验一下。
 
-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:
+如果你很难立即想出最好的办法，那就先从添加足够多的你*十分*确定所有可能的视图数据都被包括在其中开始：
 
 ```js
 const [isEmpty, setIsEmpty] = useState(true);
@@ -357,19 +359,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!
+你最初的想法或许不是最好的，但是没关系，重构状态也是步骤中的一部分！
 
-### Step 4: Remove any non-essential state variables {/*step-4-remove-any-non-essential-state-variables*/}
+### 步骤 4：删除任何不必要的状态变量 {/*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!)
+你会想要避免状态内容中的重复，因此你只需要关注那些必要的部分。花费一点时间在重构你的状态结构上，这会让你的组件更容易理解，减少重复并且避免意料之外的意义。你的目的是**避免在内存中的状态不表示任何你想让用户看到的有效的 UI 的情况。**（比如你绝对不会想要在展示错误信息的时候同时禁用掉输入框，导致用户无法纠正错误！）
 
-Here are some questions you can ask about your state variables:
+这有一些问题让你可以批判性地审视自己声明的状态变量：
 
-* **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 `message.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.
+* **这个状态是否会导致矛盾？**例如，`isTyping` 与 `isSubmitting` 的状态不能同时为 `true`。当有矛盾产生的同时也就说明了这个状态没有足够的约束条件。两个布尔值有四种可能的组合，但是只有三种对应有效的状态。为了将“不可能”的状态移除，你可以将 `'typing'`、`'submitting'` 以及 `'success'` 这三个中的其中一个与 `status` 结合。
+* **相同的信息是否已经在另一个状态变量中存在？**另一个矛盾：`isEmpty` 和 `isTyping` 不能同时为 `true`。通过使它们成为独立的状态变量，可能会导致它们不同步并导致 bug。幸运的是，你可以移除 `isEmpty` 转而用 `message.length === 0`。
+* **你是否可以在另一个相反的状态变量中得到相同的信息？**`isError` 是多余的，因为你可以检查 `error !== null`。
 
-After this clean-up, you're left with 3 (down from 7!) *essential* state variables:
+在清理之后，你只剩下 3 个（从原本的 7 个！）*必要*的状态变量：
 
 ```js
 const [answer, setAnswer] = useState('');
@@ -377,17 +379,17 @@ 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.
+正是因为你不能在不破坏功能的情况下删除其中任何一个状态变量，因此你可以确定这些都是必要的。
 
-<DeepDive title="Eliminating “impossible” states with a reducer">
+<DeepDive title="通过 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)。Reducers 可以让您合并多个状态变量到一个对象中并巩固所有相关的逻辑！
 
 </DeepDive>
 
-### Step 5: Connect the event handlers to set state {/*step-5-connect-the-event-handlers-to-set-state*/}
+### 步骤 5：连接事件处理函数去设置状态 {/*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:
+最后，创建事件处理函数去设置状态变量。下方的是在 React 中表单的最终形式，所有的事件处理函数都相关联起来了：
 
 <Sandpack>
 
@@ -400,7 +402,7 @@ export default function Form() {
   const [status, setStatus] = useState('typing');
 
   if (status === 'success') {
-    return <h1>That's right!</h1>
+    return <h1>回答正确！</h1>
   }
 
   async function handleSubmit(e) {
@@ -421,9 +423,9 @@ export default function Form() {
 
   return (
     <>
-      <h2>City quiz</h2>
+      <h2>城市测验</h2>
       <p>
-        In which city is there a billboard that turns air into drinkable water?
+        哪个城市有把空气转化为饮用水的广告牌？
       </p>
       <form onSubmit={handleSubmit}>
         <textarea
@@ -436,7 +438,7 @@ export default function Form() {
           answer.length === 0 ||
           status === 'submitting'
         }>
-          Submit
+          提交
         </button>
         {error !== null &&
           <p className="Error">
@@ -449,12 +451,12 @@ export default function Form() {
 }
 
 function submitForm(answer) {
-  // Pretend it's hitting the network.
+  // 假设正在进行网络请求
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       let shouldError = answer.toLowerCase() !== 'lima'
       if (shouldError) {
-        reject(new Error('Good guess but a wrong answer. Try again!'));
+        reject(new Error('猜得好，但答案是错的。再试一次！'));
       } else {
         resolve();
       }
@@ -469,17 +471,17 @@ function submitForm(answer) {
 
 </Sandpack>
 
-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.
+尽管这些代码相对与最初的命令式的例子来说更长，但是却更健壮。将所有的交互变为状态的改变，可以让你避免之后引入新的视图状态后导致现有状态被破坏。同时也使你在不必改变交互逻辑本身的情况下，更改每个状态中应该显示的内容。
 
 <Recap>
 
-* 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. 确定是什么触发了这些状态的改变
+  3. 通过 `useState` 模块化内存中的状态
+  4. 删除任何不必要的状态变量
+  5. 连接事件处理函数去设置状态
 
 </Recap>
 
@@ -487,11 +489,11 @@ Although this code is longer than the original imperative example, it is much le
 
 <Challenges>
 
-### Add and remove a CSS class {/*add-and-remove-a-css-class*/}
+### 添加和删除一个 CSS 类名 {/*add-and-remove-a-css-class*/}
 
-Make it so that clicking on the picture *removes* the `background--active` CSS class from the outer `<div>`, but *adds* the `picture--active` class to the `<img>`. Clicking the background again should restore the original CSS classes.
+试试当点击图片时*删除*外面 `<div>` 的类名 `background--active`，但是将 `picture--active` 的类名添加到 `<img>` 上。当再次点击背景图片时恢复最开始的 CSS 类名。
 
-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.
+视觉上，你应该期望当点击图片时会移除紫色的背景，并且高亮图片的边框。点击图片外面时高亮背景并且删除图片边框的高亮效果。
 
 <Sandpack>
 
@@ -501,7 +503,7 @@ export default function Picture() {
     <div className="background background--active">
       <img
         className="picture"
-        alt="Rainbow houses in Kampung Pelangi, Indonesia"
+        alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
         src="https://i.imgur.com/5qwVYb1.jpeg"
       />
     </div>
@@ -540,14 +542,14 @@ body { margin: 0; padding: 0; height: 250px; }
 
 <Solution>
 
-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 类名是 `background` 和 `picture picture--active`。
+* 当图片处于非激活状态时，CSS 类名是 `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.
+一个布尔类型的状态已经足够表示图片是否处于激活状态。最初的工作仅仅是移除或添加 CSS 类名。然而在 React 中你需要去*描述*什么是你想要看到的而非*操作* UI 元素。因此你需要基于当前状态去计算这两个 CSS 类名。同时你需要去 [阻止冒泡行为](/learn/responding-to-events#stopping-propagation)，只有这样点击图片的时候不会触发点击背景的回调。
 
-Verify that this version works by clicking the image and then outside of it:
+检验这个通过点击图片然后点击图片的外面：
 
 <Sandpack>
 
@@ -576,7 +578,7 @@ export default function Picture() {
           setIsActive(true);
         }}
         className={pictureClassName}
-        alt="Rainbow houses in Kampung Pelangi, Indonesia"
+        alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
         src="https://i.imgur.com/5qwVYb1.jpeg"
       />
     </div>
@@ -614,7 +616,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-Alternatively, you could return two separate chunks of JSX:
+或者，你可以返回两个单独的 JSX 代码块：
 
 <Sandpack>
 
@@ -631,7 +633,7 @@ export default function Picture() {
       >
         <img
           className="picture picture--active"
-          alt="Rainbow houses in Kampung Pelangi, Indonesia"
+          alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
           src="https://i.imgur.com/5qwVYb1.jpeg"
           onClick={e => e.stopPropagation()}
         />
@@ -642,7 +644,7 @@ export default function Picture() {
     <div className="background background--active">
       <img
         className="picture"
-        alt="Rainbow houses in Kampung Pelangi, Indonesia"
+        alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
         src="https://i.imgur.com/5qwVYb1.jpeg"
         onClick={() => setIsActive(true)}
       />
@@ -681,13 +683,13 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-Keep in mind that if two different JSX chunks describe the same tree, their nesting (first `<div>` → first `<img>`) 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 代码块描述着相同的树结构，它们的嵌套（第一个 `<div>` → 第一个 `<img>`）必须对齐。否则切换 `isActive` 会再次在后面创建整个树结构并且 [重置状态](/learn/preserving-and-resetting-state)。这也就是为什么当一个相似的 JSX 树结构在两个情况下都返回的时候，最好将它们写成单独的 JSX。
 
 </Solution>
 
-### 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 实现的小型表单。通过与它交互来理解它的行为表现：
 
 <Sandpack>
 
@@ -784,11 +786,11 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-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!
+也要确保它会在按钮中更新文本内容！
 
 <Sandpack>
 
@@ -823,9 +825,9 @@ label { display: block; margin-bottom: 20px; }
 
 <Solution>
 
-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`.
+你需要两个状态变量来保存输入框中的内容：`firstName` 和 `lastName`。同时你还会需要一个 `isEditing` 的状态变量来保存是否显示输入框的状态。你应该*不*需要 `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) 来决定显示还是隐藏输入框。 
 
 <Sandpack>
 
@@ -883,13 +885,13 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-Compare this solution to the original imperative code. How are they different?
+这个解决方案与最初命令式的代码相比，它们有什么不同？
 
 </Solution>
 
-### 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 而写的命令式原始沙盒：
 
 <Sandpack>
 
@@ -986,9 +988,10 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-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 的版本十分相似地重构这个代码吗？像 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` 函数中补充缺失的逻辑即可。（需要时请参考原始代码）
 
 <Sandpack>
 
@@ -1028,12 +1031,12 @@ function setIsEditing(value) {
 function updateDOM() {
   if (isEditing) {
     button.textContent = 'Save Profile';
-    // TODO: show inputs, hide content
+    // TODO: 显示输入框，隐藏文本
   } else {
     button.textContent = 'Edit Profile';
-    // TODO: hide inputs, show content
+    // TODO: 显示文本，隐藏输入框
   }
-  // TODO: update text labels
+  // TODO: 更新标签文本
 }
 
 function hide(el) {
@@ -1095,7 +1098,7 @@ label { display: block; margin-bottom: 20px; }
 
 <Solution>
 
-The missing logic included toggling the display of inputs and content, and updating the labels:
+缺失的逻辑包括切换输入框和内容的显示以及更新标签的内容：
 
 <Sandpack>
 
@@ -1212,7 +1215,7 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-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` 函数展示了当你设置状态时，React 在幕后都做了什么。（然而，React 同样为了那些自上次设置状态后未改变的属性避免接触 DOM。）
 
 </Solution>
 

From 224b606b30cd5d97d0680d5e7fec13d09f2515a2 Mon Sep 17 00:00:00 2001
From: BBboy01 <1156678002@qq.com>
Date: Thu, 6 Jan 2022 20:53:51 +0800
Subject: [PATCH 02/11] docs: solved the porblem of comments

---
 .../learn/reacting-to-input-with-state.md     | 144 +++++++++---------
 1 file changed, 72 insertions(+), 72 deletions(-)

diff --git a/beta/src/pages/learn/reacting-to-input-with-state.md b/beta/src/pages/learn/reacting-to-input-with-state.md
index f17b368e95..ad5baf08bf 100644
--- a/beta/src/pages/learn/reacting-to-input-with-state.md
+++ b/beta/src/pages/learn/reacting-to-input-with-state.md
@@ -1,12 +1,13 @@
 ---
-title: 状态响应输入
+title: State 驱动输入
 translators:
   - BBboy01
+  - KimYangOfCat
 ---
 
 <Intro>
 
-React 使用声明式模式控制 UI，也就是说，当你声明不同的状态时，你的组件可以根据不同的输入来相应输入，而不是去控制 UI 的各个部分。这与设计师如何去思考 UI 很相似。
+React 使用声明式模式控制 UI。你不必直接控制 UI 的各个部分，而应该声明你的组件可以处于的不同 state，并根据用户的输入在它们之间切换。这与设计师对 UI 的思考方式很相似。
 
 </Intro>
 
@@ -20,20 +21,20 @@ React 使用声明式模式控制 UI，也就是说，当你声明不同的状
 
 ## 声明式 UI 与 命令式 UI 的比较 {/*how-declarative-ui-compares-to-imperative*/}
 
-当你设计 UI 交互时，可能会去思考 UI 如何根据用户的操作而响应*变化*。想象一个允许用户提交一个答案的表单：
+当你设计 UI 交互时，可能会去思考 UI 如何根据用户的操作而响应**变化**。想象一个允许用户提交一个答案的表单：
 
-* 当你输入向表单数据时，“提交”按钮会随之变成**可用状态**
+* 当你向表单输入数据时，“提交”按钮会随之变成**可用状态**
 * 当你点击“提交”后，表单和提交按钮都会随之变成**不可用状态**，并且会加载动画会随之**出现**
 * 如果网络请求成功，表单会随之**隐藏**，同时“提交成功”的信息会随之**出现**
 * 如果网络请求失败，错误信息会随之**出现**，同时表单又变为**可用状态**
 
-在 **命令式编程** 中，以上的过程直接告诉你如何去实现交互。你必须去根据要发生的事情写一些明确的命令去操作 UI。有这样一个场景去理解这些，当你坐在车里的某个人旁边，然后一步一步地告诉他该去哪。
+在 **命令式编程** 中，以上的过程直接告诉你如何去实现交互。你必须去根据要发生的事情写一些明确的命令去操作 UI。对此有另一种理解方式，想象一下，当你坐在车里的某个人旁边，然后一步一步地告诉他该去哪。
 
 <Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="看起来很焦急的司机代表 JavaScript，乘客命令司机执行一系列复杂的转弯导航。" />
 
 他并不知道你想去哪，只想跟着命令行动。（并且如果你发出了错误的命令，那么你就会到达错误的地方）正因为你必须从加载动画到按钮地“命令”每个元素，所以这种告诉计算机*如何*去更新 UI 的编程方式被称为*命令式编程*
 
-在这个命令式 UI 编程的例子中，表单没有使用 React 生成，而是使用原生的 [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):
 
 <Sandpack>
 
@@ -83,7 +84,7 @@ function disable(el) {
 }
 
 function submitForm(answer) {
-  // 假设正在进行网络请求
+  // Pretend it's hitting the network.
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       if (answer.toLowerCase() == 'istanbul') {
@@ -113,17 +114,17 @@ textarea.oninput = handleTextareaChange;
 
 ```html public/index.html
 <form id="form">
-  <h2>城市测验</h2>
+  <h2>City quiz</h2>
   <p>
-    哪个城市位于两个大陆上？
+    What city is located on two continents?
   </p>
   <textarea id="textarea"></textarea>
   <br />
-  <button id="button" disabled>提交</button>
-  <p id="loading" style="display: none">加载中...</p>
+  <button id="button" disabled>Submit</button>
+  <p id="loading" style="display: none">Loading...</p>
   <p id="error" style="display: none; color: red;"></p>
 </form>
-<h1 id="success" style="display: none">回答正确！</h1>
+<h1 id="success" style="display: none">That's right!</h1>
 
 <style>
 * { box-sizing: border-box; }
@@ -133,11 +134,11 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
 
 </Sandpack>
 
-对于单独的例子来说，操作 UI 的工作十分方便，但是当处于更加复杂的系统中时，这会造成在困难程度指数级地增长。想象一下，当你更新一个充满着不同的类似这个例子中的表单的页面时，添加一个新 UI 元素或一个新的交互，为了保证不会因此产生新的 bug，你必须十分小心地去检查所有已经写好的代码（例如忘记去显示或隐藏一些东西）。
+对于独立系统来说，命令式地控制用户界面的效果也不错，但是当处于更加复杂的系统中时，这会造成管理的困难程度指数级地增长。如同示例一样，想象一下，当你想更新这样一个包含着不同表单的页面时，你想要添加一个新 UI 元素或一个新的交互，为了保证不会因此产生新的 bug，你必须十分小心地去检查所有已经写好的代码（例如忘记去显示或隐藏一些东西）。
 
 React 正是为了解决这样的问题而诞生的。
 
-在 React 中，你不必直接去操作 UI —— 你不必直接去让组件变得可用、不可用、显示或隐藏。相反，你只需要 **声明你想要去显示**，React 就会通过计算得出该如何去更新 UI。想象一下当你上了一辆出租车并且告诉司机你想去哪，而不是事无巨细地告诉他该如何走，将你带到目的地是司机的工作，他们甚至可能知道一些你没有想过并且不知道的捷径！
+在 React 中，你不必直接去操作 UI —— 你不必直接启用、关闭、显示或隐藏组件。相反，你只需要 **声明你想要显示的内容**，React 就会通过计算得出该如何去更新 UI。想象一下，当你上了一辆出租车并且告诉司机你想去哪，而不是事无巨细地告诉他该如何走。将你带到目的地是司机的工作，他们甚至可能知道一些你没有想过并且不知道的捷径！
 
 <Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="React 开着车，一个乘客想要去一个地图上的一个明确的地方。React 会思考如何带你到目的地。" />
 
@@ -146,14 +147,14 @@ React 正是为了解决这样的问题而诞生的。
 你已经从上面的例子看到如何去实现一个表单了，为了更好地理解如何在 React 中思考，你将会在下面用 React 重新实现操作 UI：
 
 1. **定位**你的组件中不同的视图状态
-2. **确定**是什么触发了这些状态的改变
-3. **表示**内存中的状态，通过 `useState`
-4. **删除**任何不必要的状态变量
-5.  **连接**事件处理函数去设置状态
+2. **确定**是什么触发了这些 state 的改变
+3. **表示**内存中的 state，通过 `useState`
+4. **删除**任何不必要的 state 变量
+5.  **连接**事件处理函数去设置 state
 
 ### 步骤 1：定位你的组件中不同的视图状态 {/*step-1-identify-your-components-different-visual-states*/}
 
-在计算机科学中，你或许听过一个处在多种状态中的的其中一种状态的 [“状态机”](https://en.wikipedia.org/wiki/Finite-state_machine)。如果你有与设计师一起工作，那么你可能已经见过为不同的“视图状态”进行模拟。正因为 React 站在设计与计算机科学的交点上，因此这两种思想都是灵感的来源。
+在计算机科学中，你或许听过可处于多种“状态”之一的 [“状态机”](https://en.wikipedia.org/wiki/Finite-state_machine)。如果你有与设计师一起工作，那么你可能已经见过不同“视图状态”的模拟图。正因为 React 站在设计与计算机科学的交点上，因此这两种思想都是灵感的来源。
 
 首先，你需要去可视化 UI 界面中用户可能看到的所有不同的“状态”：
 
@@ -172,19 +173,19 @@ export default function Form({
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>回答正确！</h1>
+    return <h1>That's right!</h1>
   }
   return (
     <>
-      <h2>城市测验</h2>
+      <h2>City quiz</h2>
       <p>
-        哪个城市有把空气转化为饮用水的广告牌？
+        In which city is there a billboard that turns air into drinkable water?
       </p>
       <form>
         <textarea />
         <br />
         <button>
-          提交
+          Submit
         </button>
       </form>
     </>
@@ -200,17 +201,17 @@ export default function Form({
 
 ```js
 export default function Form({
-  // 试一下 'submitting', 'error', 'success'：
+  // Try 'submitting', 'error', 'success'：
   status = 'empty'
 }) {
   if (status === 'success') {
-    return <h1>回答正确！</h1>
+    return <h1>That's right!</h1>
   }
   return (
     <>
-      <h2>城市测验</h2>
+      <h2>City quiz</h2>
       <p>
-        哪个城市有把空气转化为饮用水的广告牌？
+        In which city is there a billboard that turns air into drinkable water?
       </p>
       <form>
         <textarea disabled={
@@ -221,11 +222,11 @@ export default function Form({
           status === 'empty' ||
           status === 'submitting'
         }>
-          提交
+          Submit
         </button>
         {status === 'error' &&
           <p className="Error">
-            猜得好，但答案是错的。再试一次！
+            Good guess but a wrong answer. Try again!
           </p>
         }
       </form>
@@ -242,7 +243,7 @@ export default function Form({
 
 <DeepDive title="同时展示大量的视图状态">
 
-如果一个组件有许多视图数据，你可以很方便地将它们展示在一个页面中：
+如果一个组件有多个视图状态，你可以很方便地将它们展示在一个页面中：
 
 <Sandpack>
 
@@ -262,7 +263,7 @@ export default function App() {
     <>
       {statuses.map(status => (
         <section key={status}>
-          <h4>表单 ({status}):</h4>
+          <h4>Form ({status}):</h4>
           <Form status={status} />
         </section>
       ))}
@@ -274,7 +275,7 @@ export default function App() {
 ```js Form.js
 export default function Form({ status }) {
   if (status === 'success') {
-    return <h1>回答正确！</h1>
+    return <h1>That's right!</h1>
   }
   return (
     <form>
@@ -290,7 +291,7 @@ export default function Form({ status }) {
       </button>
       {status === 'error' &&
         <p className="Error">
-          猜得好，但答案是错的。再试一次!
+          Good guess but a wrong answer. Try again!
         </p>
       }
     </form>
@@ -307,7 +308,7 @@ body { margin: 0; }
 
 </Sandpack>
 
-类似这样的页面通常以“实时样式参考”或“故事书”的名字被人们熟知。
+类似这样的页面通常被称作“实时风格指南”或“故事板”。
 
 </DeepDive>
 
@@ -318,12 +319,12 @@ body { margin: 0; }
   <Illustration caption="计算机输入" alt="许多的 0 和 1。" src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>
 
-你可以触发状态更新来响应两种输入：
+你可以触发 state 的更新来响应两种输入：
 
 - **人为**输入。比如点击按钮、表单字段中输入内容时以及导航链接。
 - **计算机**输入。比如网络请求得到返回、一个定时器触发以及加载一张图片时。
 
-以上两种情况中，**你必须设置 [状态变量](/learn/state-a-components-memory#anatomy-of-usestate)去更新 UI**。对于正在开发中的表单来说，你需要改变状态以响应几个不同的输入：
+以上两种情况中，**你必须设置 [ state 变量](/learn/state-a-components-memory#anatomy-of-usestate)去更新 UI**。对于正在开发中的表单来说，你需要改变 state 以响应几个不同的输入：
 
 * **改变输入框中的文本时**（人为）应该根据输入框的内容是否是**空值**，从而将表单的状态从空值状态切换到**输入中**或返回的状态。
 * **点击提交按钮时**（人为）应该将表单的状态切换到**提交中**的状态。
@@ -336,9 +337,9 @@ body { margin: 0; }
 
 <img alt="显示状态和状态之间转换的流程图" src="/images/docs/sketches/s_flow-chart.jpg" />
 
-### 步骤 3：表示内存中的状态，通过 `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
+### 步骤 3：通过 `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/} 表示内存中的 state
 
-接下来你会需要在内存中通过 [`useState`](/reference/usestate) 表示组件中的视图状态。诀窍就是简单：状态每个部分都是“移动中的部分”，并且**你想要“移动中的部分”尽可能的少**。太复杂的话会产生更多 bug！
+接下来你会需要在内存中通过 [`useState`](/reference/usestate) 表示组件中的视图状态。诀窍很简单：state 的每个部分都是“处于变化中的”，并且**你需要让“变化的部分”尽可能的少**。太复杂的话会产生更多 bug！
 
 先从*绝对必须*存在的状态开始。例如，你需要存储输入的 `message` 以及存储最后一个错误的 `error` （如果存在的话）：
 
@@ -347,9 +348,9 @@ const [answer, setAnswer] = useState('');
 const [error, setError] = useState(null);
 ```
 
-之后你需要一个变量来表示你之前声明过想要展示的视图状态中的一个。这有不止一种方法在可以在内存中将之表示，因此你需要来体验一下。
+之后你需要一个 state 变量来代表你之前声明过的想要展示的视图状态之一。通常不止一种可以在内存中代表的方法，因此你需要试验一下。
 
-如果你很难立即想出最好的办法，那就先从添加足够多的你*十分*确定所有可能的视图数据都被包括在其中开始：
+如果你很难立即想出最好的办法，那就先从添加足够多的 state 开始，“确保”所有可能的视图状态都囊括其中：
 
 ```js
 const [isEmpty, setIsEmpty] = useState(true);
@@ -359,19 +360,19 @@ const [isSuccess, setIsSuccess] = useState(false);
 const [isError, setIsError] = useState(false);
 ```
 
-你最初的想法或许不是最好的，但是没关系，重构状态也是步骤中的一部分！
+你最初的想法或许不是最好的，但是没关系，重构 state 也是步骤中的一部分！
 
-### 步骤 4：删除任何不必要的状态变量 {/*step-4-remove-any-non-essential-state-variables*/}
+### 步骤 4：删除任何不必要的 state 变量 {/*step-4-remove-any-non-essential-state-variables*/}
 
-你会想要避免状态内容中的重复，因此你只需要关注那些必要的部分。花费一点时间在重构你的状态结构上，这会让你的组件更容易理解，减少重复并且避免意料之外的意义。你的目的是**避免在内存中的状态不表示任何你想让用户看到的有效的 UI 的情况。**（比如你绝对不会想要在展示错误信息的时候同时禁用掉输入框，导致用户无法纠正错误！）
+你会想要避免 state 内容中的重复，因此你只需要关注那些必要的部分。花费一点时间在重构你的 state 结构上，这会让你的组件更容易理解，减少重复并且避免意外的含义。你的目的是**防止出现在内存中的 state 不代表任何你希望用户看到的有效 UI 的情况。**（比如你绝对不会想要在展示错误信息的时候同时禁用掉输入框，导致用户无法纠正错误！）
 
-这有一些问题让你可以批判性地审视自己声明的状态变量：
+这有一些问题让你可以批判性地审视自己声明的 state 变量：
 
-* **这个状态是否会导致矛盾？**例如，`isTyping` 与 `isSubmitting` 的状态不能同时为 `true`。当有矛盾产生的同时也就说明了这个状态没有足够的约束条件。两个布尔值有四种可能的组合，但是只有三种对应有效的状态。为了将“不可能”的状态移除，你可以将 `'typing'`、`'submitting'` 以及 `'success'` 这三个中的其中一个与 `status` 结合。
-* **相同的信息是否已经在另一个状态变量中存在？**另一个矛盾：`isEmpty` 和 `isTyping` 不能同时为 `true`。通过使它们成为独立的状态变量，可能会导致它们不同步并导致 bug。幸运的是，你可以移除 `isEmpty` 转而用 `message.length === 0`。
-* **你是否可以在另一个相反的状态变量中得到相同的信息？**`isError` 是多余的，因为你可以检查 `error !== null`。
+* **这个 state 是否会导致矛盾？**例如，`isTyping` 与 `isSubmitting` 的状态不能同时为 `true`。当有矛盾产生的同时也就说明了这个 state 没有足够的约束条件。两个布尔值有四种可能的组合，但是只有三种对应有效的状态。为了将“不可能”的状态移除，你可以将 `'typing'`、`'submitting'` 以及 `'success'` 这三个中的其中一个与 `status` 结合。
+* **相同的信息是否已经在另一个 state 变量中存在？**另一个矛盾：`isEmpty` 和 `isTyping` 不能同时为 `true`。通过使它们成为独立的 state 变量，可能会导致它们不同步并导致 bug。幸运的是，你可以移除 `isEmpty` 转而用 `message.length === 0`。
+* **你是否可以在另一个相反的 state 变量中得到相同的信息？**`isError` 是多余的，因为你可以检查 `error !== null`。
 
-在清理之后，你只剩下 3 个（从原本的 7 个！）*必要*的状态变量：
+在清理之后，你只剩下 3 个（从原本的 7 个！）*必要*的 state 变量：
 
 ```js
 const [answer, setAnswer] = useState('');
@@ -381,15 +382,15 @@ const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 's
 
 正是因为你不能在不破坏功能的情况下删除其中任何一个状态变量，因此你可以确定这些都是必要的。
 
-<DeepDive title="通过 reducer 来减少“不可能”状态">
+<DeepDive title="通过 reducer 来减少“不可能” state">
 
 尽管这三个变量对于表示这个表单的状态来说已经足够好了，仍然是有一些中间状态并不是完全有意义的。例如一个非空的 `error` 当 `status` 的值为 `success` 时没有意义。为了更精确地模块化状态，你可以 [将状态提取到一个 reducer 中](/learn/extracting-state-logic-into-a-reducer)。Reducers 可以让您合并多个状态变量到一个对象中并巩固所有相关的逻辑！
 
 </DeepDive>
 
-### 步骤 5：连接事件处理函数去设置状态 {/*step-5-connect-the-event-handlers-to-set-state*/}
+### 步骤 5：连接事件处理函数以设置 state {/*step-5-connect-the-event-handlers-to-set-state*/}
 
-最后，创建事件处理函数去设置状态变量。下方的是在 React 中表单的最终形式，所有的事件处理函数都相关联起来了：
+最后，创建事件处理函数去设置 state 变量。下方的是在 React 中表单的最终形式，所有的事件处理函数都相关联起来了：
 
 <Sandpack>
 
@@ -402,7 +403,7 @@ export default function Form() {
   const [status, setStatus] = useState('typing');
 
   if (status === 'success') {
-    return <h1>回答正确！</h1>
+    return <h1>That's right!</h1>
   }
 
   async function handleSubmit(e) {
@@ -423,9 +424,9 @@ export default function Form() {
 
   return (
     <>
-      <h2>城市测验</h2>
+      <h2>City quiz</h2>
       <p>
-        哪个城市有把空气转化为饮用水的广告牌？
+        In which city is there a billboard that turns air into drinkable water?
       </p>
       <form onSubmit={handleSubmit}>
         <textarea
@@ -438,7 +439,7 @@ export default function Form() {
           answer.length === 0 ||
           status === 'submitting'
         }>
-          提交
+          Submit
         </button>
         {error !== null &&
           <p className="Error">
@@ -451,12 +452,12 @@ export default function Form() {
 }
 
 function submitForm(answer) {
-  // 假设正在进行网络请求
+  // Pretend it's hitting the network.
   return new Promise((resolve, reject) => {
     setTimeout(() => {
       let shouldError = answer.toLowerCase() !== 'lima'
       if (shouldError) {
-        reject(new Error('猜得好，但答案是错的。再试一次！'));
+        reject(new Error('Good guess but a wrong answer. Try again!'));
       } else {
         resolve();
       }
@@ -471,17 +472,17 @@ function submitForm(answer) {
 
 </Sandpack>
 
-尽管这些代码相对与最初的命令式的例子来说更长，但是却更健壮。将所有的交互变为状态的改变，可以让你避免之后引入新的视图状态后导致现有状态被破坏。同时也使你在不必改变交互逻辑本身的情况下，更改每个状态中应该显示的内容。
+尽管这些代码相对与最初的命令式的例子来说更长，但是却更健壮。将所有的交互变为 state 的改变，可以让你避免之后引入新的视图状态后导致现有 state 被破坏。同时也使你在不必改变交互逻辑本身的情况下，更改每个状态中应该显示的内容。
 
 <Recap>
 
 * 声明式编程意味着为每个视图状态声明 UI 而非细致地控制 UI（命令式）。
 * 当开发一个组件时：
   1. 定位你的组件中不同的视图状态
-  2. 确定是什么触发了这些状态的改变
-  3. 通过 `useState` 模块化内存中的状态
-  4. 删除任何不必要的状态变量
-  5. 连接事件处理函数去设置状态
+  2. 确定是什么触发了这些 state 的改变
+  3. 通过 `useState` 模块化内存中的 state
+  4. 删除任何不必要的 state 变量
+  5. 连接事件处理函数去设置 state
 
 </Recap>
 
@@ -491,7 +492,7 @@ function submitForm(answer) {
 
 ### 添加和删除一个 CSS 类名 {/*add-and-remove-a-css-class*/}
 
-试试当点击图片时*删除*外面 `<div>` 的类名 `background--active`，但是将 `picture--active` 的类名添加到 `<img>` 上。当再次点击背景图片时恢复最开始的 CSS 类名。
+试试当点击图片时*删除*外部 `<div>` 的类名 `background--active`，但是将 `picture--active` 的类名添加到 `<img>` 上。当再次点击背景图片时恢复最开始的 CSS 类名。
 
 视觉上，你应该期望当点击图片时会移除紫色的背景，并且高亮图片的边框。点击图片外面时高亮背景并且删除图片边框的高亮效果。
 
@@ -547,7 +548,7 @@ body { margin: 0; padding: 0; height: 250px; }
 * 当图片处于激活状态时，CSS 类名是 `background` 和 `picture picture--active`。
 * 当图片处于非激活状态时，CSS 类名是 `background background--active` 和 `picture`。
 
-一个布尔类型的状态已经足够表示图片是否处于激活状态。最初的工作仅仅是移除或添加 CSS 类名。然而在 React 中你需要去*描述*什么是你想要看到的而非*操作* UI 元素。因此你需要基于当前状态去计算这两个 CSS 类名。同时你需要去 [阻止冒泡行为](/learn/responding-to-events#stopping-propagation)，只有这样点击图片的时候不会触发点击背景的回调。
+一个布尔类型的 state 已经足够表示图片是否处于激活状态。最初的工作仅仅是移除或添加 CSS 类名。然而在 React 中你需要去*描述*什么是你想要看到的而非*操作* UI 元素。因此你需要基于当前 state 去计算这两个 CSS 类名。同时你需要去 [阻止冒泡行为](/learn/responding-to-events#stopping-propagation)，只有这样点击图片的时候不会触发点击背景的回调。
 
 检验这个通过点击图片然后点击图片的外面：
 
@@ -683,7 +684,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-请记住，如果两个不同的 JSX 代码块描述着相同的树结构，它们的嵌套（第一个 `<div>` → 第一个 `<img>`）必须对齐。否则切换 `isActive` 会再次在后面创建整个树结构并且 [重置状态](/learn/preserving-and-resetting-state)。这也就是为什么当一个相似的 JSX 树结构在两个情况下都返回的时候，最好将它们写成单独的 JSX。
+请记住，如果两个不同的 JSX 代码块描述着相同的树结构，它们的嵌套（第一个 `<div>` → 第一个 `<img>`）必须对齐。否则切换 `isActive` 会再次在后面创建整个树结构并且 [重置 state](/learn/preserving-and-resetting-state)。这也就是为什么当一个相似的 JSX 树结构在两个情况下都返回的时候，最好将它们写成单独的 JSX。
 
 </Solution>
 
@@ -825,7 +826,7 @@ label { display: block; margin-bottom: 20px; }
 
 <Solution>
 
-你需要两个状态变量来保存输入框中的内容：`firstName` 和 `lastName`。同时你还会需要一个 `isEditing` 的状态变量来保存是否显示输入框的状态。你应该*不*需要 `fullName` 变量，因为全名可以由`firstName` 和 `lastName` 组合而成。
+你需要两个 state 变量来保存输入框中的内容：`firstName` 和 `lastName`。同时你还会需要一个 `isEditing` 的 state 变量来保存是否显示输入框的状态。你应该*不*需要 `fullName` 变量，因为全名可以由`firstName` 和 `lastName` 组合而成。
 
 最终，你应该根据 `isEditing` 的值使用 [条件渲染](/learn/conditional-rendering) 来决定显示还是隐藏输入框。 
 
@@ -988,9 +989,8 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-如果没有 React，你可以十分健壮地并且使其与 React 的版本十分相似地重构这个代码吗？像 React 那样，如果状态是明确地，这个重构的代码会是什么样的？
+如果没有 React，你可以十分健壮地并且使其与 React 的版本十分相似地重构这个代码吗？像 React 那样，如果 state 是明确的，这个重构的代码会是什么样的？
 
-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` 函数中补充缺失的逻辑即可。（需要时请参考原始代码）
 
 <Sandpack>
@@ -1031,12 +1031,12 @@ function setIsEditing(value) {
 function updateDOM() {
   if (isEditing) {
     button.textContent = 'Save Profile';
-    // TODO: 显示输入框，隐藏文本
+    // TODO: show inputs, hide content
   } else {
     button.textContent = 'Edit Profile';
-    // TODO: 显示文本，隐藏输入框
+    // TODO: hide inputs, show content
   }
-  // TODO: 更新标签文本
+  // TODO: update text labels
 }
 
 function hide(el) {
@@ -1215,7 +1215,7 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-你所写的 `updateDOM` 函数展示了当你设置状态时，React 在幕后都做了什么。（然而，React 同样为了那些自上次设置状态后未改变的属性避免接触 DOM。）
+你所写的 `updateDOM` 函数展示了当你设置 state 时，React 在幕后都做了什么。（然而，为了那些自上次设置 state 后未改变的属性，React 同样避免修改 DOM。）
 
 </Solution>
 

From a25dbf7bc3a72384b7e118345223957d54788eaa Mon Sep 17 00:00:00 2001
From: BBboy01 <1156678002@qq.com>
Date: Thu, 20 Jan 2022 20:52:18 +0800
Subject: [PATCH 03/11] docs: better docs with TinaaaaP

---
 .../learn/reacting-to-input-with-state.md     | 49 ++++++++++---------
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/beta/src/pages/learn/reacting-to-input-with-state.md b/beta/src/pages/learn/reacting-to-input-with-state.md
index ad5baf08bf..38d2cf6028 100644
--- a/beta/src/pages/learn/reacting-to-input-with-state.md
+++ b/beta/src/pages/learn/reacting-to-input-with-state.md
@@ -3,6 +3,7 @@ title: State 驱动输入
 translators:
   - BBboy01
   - KimYangOfCat
+  - TinaaaaP
 ---
 
 <Intro>
@@ -14,7 +15,7 @@ React 使用声明式模式控制 UI。你不必直接控制 UI 的各个部分
 <YouWillLearn>
 
 * 了解声明式 UI 编程与命令式 UI 编程有何不同
-* 了解如何列举你的组件可以处于的视图状态的不同
+* 了解如何列举你的组件可能处于的不同视图状态
 * 了解如何在代码中触发不同视图状态的变化
 
 </YouWillLearn>
@@ -134,13 +135,13 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
 
 </Sandpack>
 
-对于独立系统来说，命令式地控制用户界面的效果也不错，但是当处于更加复杂的系统中时，这会造成管理的困难程度指数级地增长。如同示例一样，想象一下，当你想更新这样一个包含着不同表单的页面时，你想要添加一个新 UI 元素或一个新的交互，为了保证不会因此产生新的 bug，你必须十分小心地去检查所有已经写好的代码（例如忘记去显示或隐藏一些东西）。
+对于独立系统来说，命令式地控制用户界面的效果也不错，但是当处于更加复杂的系统中时，这会造成管理的困难程度指数级地增长。如同示例一样，想象一下，当你想更新这样一个包含着不同表单的页面时，你想要添加一个新 UI 元素或一个新的交互，为了保证不会因此产生新的 bug（例如忘记去显示或隐藏一些东西），你必须十分小心地去检查所有已经写好的代码。
 
 React 正是为了解决这样的问题而诞生的。
 
 在 React 中，你不必直接去操作 UI —— 你不必直接启用、关闭、显示或隐藏组件。相反，你只需要 **声明你想要显示的内容**，React 就会通过计算得出该如何去更新 UI。想象一下，当你上了一辆出租车并且告诉司机你想去哪，而不是事无巨细地告诉他该如何走。将你带到目的地是司机的工作，他们甚至可能知道一些你没有想过并且不知道的捷径！
 
-<Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="React 开着车，一个乘客想要去一个地图上的一个明确的地方。React 会思考如何带你到目的地。" />
+<Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="React 开着车，一个乘客想要去地图上的一个特定的地方。React 会思考如何带你到目的地。" />
 
 ## 声明式地考虑 UI {/*thinking-about-ui-declaratively*/}
 
@@ -164,7 +165,7 @@ React 正是为了解决这样的问题而诞生的。
 * **成功时**：显示“成功”的消息而非表单
 * **错误时**：与输入状态类似，但会多错误的消息
 
-像一个设计师一样，你会想要在你添加逻辑之前去对不同的状态“模拟”或创建“模拟”。例如下面的例子，正是一个仅仅对表单可视部分的模拟。这个模拟被一个 `status` 的属性控制，并且这个属性的默认值为 `empty`。
+像一个设计师一样，你会想要在你添加逻辑之前去“模拟”不同的状态或创建“模拟状态”。例如下面的例子，这是一个对表单可视部分的模拟。这个模拟被一个 `status` 的属性控制，并且这个属性的默认值为 `empty`。
 
 <Sandpack>
 
@@ -195,7 +196,7 @@ export default function Form({
 
 </Sandpack>
 
-你可以随便命名将这个属性，名字并不重要。试一下将 `status = 'empty'` 改为 `status = 'success'`，然后你就会看到成功的信息出现。模拟可以让你在书写任何 UI 逻辑前快速地找到更好的方法。这是同一组件的一个更加充实的原型，仍然由 `status` 属性“控制”：
+你可以随意命名这个属性，名字并不重要。试着将 `status = 'empty'` 改为 `status = 'success'`，然后你就会看到成功的信息出现。模拟可以让你在书写任何 UI 逻辑前快速地找到更好的方法。这是同一组件的一个更加充实的原型，仍然由 `status` 属性“控制”：
 
 <Sandpack>
 
@@ -321,27 +322,27 @@ body { margin: 0; }
 
 你可以触发 state 的更新来响应两种输入：
 
-- **人为**输入。比如点击按钮、表单字段中输入内容时以及导航链接。
-- **计算机**输入。比如网络请求得到返回、一个定时器触发以及加载一张图片时。
+- **人为**输入。比如点击按钮、在表单中输入内容，或导航到链接。
+- **计算机**输入。比如网络请求得到反馈、定时器被触发，或加载一张图片。
 
 以上两种情况中，**你必须设置 [ state 变量](/learn/state-a-components-memory#anatomy-of-usestate)去更新 UI**。对于正在开发中的表单来说，你需要改变 state 以响应几个不同的输入：
 
-* **改变输入框中的文本时**（人为）应该根据输入框的内容是否是**空值**，从而将表单的状态从空值状态切换到**输入中**或返回的状态。
+* **改变输入框中的文本时**（人为）应该根据输入框的内容是否是**空值**，从而决定将表单的状态从空值状态切换到**输入中**或切换回原状态。
 * **点击提交按钮时**（人为）应该将表单的状态切换到**提交中**的状态。
 * **网络请求成功后**（计算机）应该将表单的状态切换到**成功**的状态。
 * **网络请求失败后**（计算机）应该将表单的状态切换到**失败**的状态，与此同时，显示错误信息。
 
-> 注意，人为输入总是需要 [事件处理函数](/learn/responding-to-events)！
+> 注意，人为输入通常需要 [事件处理函数](/learn/responding-to-events)！
 
-为了可视化这个流程，请尝试在纸上用圆形标签表示每个状态，两个状态的改变用箭头表示。你可以像这样画出很多流程并且在写代码前解决许多 bug。
+为了可视化这个流程，请尝试在纸上画出圆形标签以表示每个状态，两个状态之间的改变用箭头表示。你可以像这样画出很多流程并且在写代码前解决许多 bug。
 
 <img alt="显示状态和状态之间转换的流程图" src="/images/docs/sketches/s_flow-chart.jpg" />
 
 ### 步骤 3：通过 `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/} 表示内存中的 state
 
-接下来你会需要在内存中通过 [`useState`](/reference/usestate) 表示组件中的视图状态。诀窍很简单：state 的每个部分都是“处于变化中的”，并且**你需要让“变化的部分”尽可能的少**。太复杂的话会产生更多 bug！
+接下来你会需要在内存中通过 [`useState`](/reference/usestate) 表示组件中的视图状态。诀窍很简单：state 的每个部分都是“处于变化中的”，并且**你需要让“变化的部分”尽可能的少**。更复杂的程序会产生更多 bug！
 
-先从*绝对必须*存在的状态开始。例如，你需要存储输入的 `message` 以及存储最后一个错误的 `error` （如果存在的话）：
+先从*绝对必须*存在的状态开始。例如，你需要存储输入的 `message` 以及用于存储最后一个错误的 `error` （如果存在的话）：
 
 ```js
 const [answer, setAnswer] = useState('');
@@ -350,7 +351,7 @@ const [error, setError] = useState(null);
 
 之后你需要一个 state 变量来代表你之前声明过的想要展示的视图状态之一。通常不止一种可以在内存中代表的方法，因此你需要试验一下。
 
-如果你很难立即想出最好的办法，那就先从添加足够多的 state 开始，“确保”所有可能的视图状态都囊括其中：
+如果你很难立即想出最好的办法，那就先从添加足够多的 state 开始，*确保*所有可能的视图状态都囊括其中：
 
 ```js
 const [isEmpty, setIsEmpty] = useState(true);
@@ -364,13 +365,13 @@ const [isError, setIsError] = useState(false);
 
 ### 步骤 4：删除任何不必要的 state 变量 {/*step-4-remove-any-non-essential-state-variables*/}
 
-你会想要避免 state 内容中的重复，因此你只需要关注那些必要的部分。花费一点时间在重构你的 state 结构上，这会让你的组件更容易理解，减少重复并且避免意外的含义。你的目的是**防止出现在内存中的 state 不代表任何你希望用户看到的有效 UI 的情况。**（比如你绝对不会想要在展示错误信息的时候同时禁用掉输入框，导致用户无法纠正错误！）
+你会想要避免 state 内容中的重复，从而只需要关注那些必要的部分。花一点时间来重构你的 state 结构，会让你的组件更容易被理解，减少重复并且避免歧义。你的目的是**防止出现在内存中的 state 不代表任何你希望用户看到的有效 UI 的情况。**（比如你绝对不会想要在展示错误信息的时候同时禁用掉输入框，导致用户无法纠正错误！）
 
-这有一些问题让你可以批判性地审视自己声明的 state 变量：
+这有一些你可以问自己的， 关于 state 变量的问题：
 
-* **这个 state 是否会导致矛盾？**例如，`isTyping` 与 `isSubmitting` 的状态不能同时为 `true`。当有矛盾产生的同时也就说明了这个 state 没有足够的约束条件。两个布尔值有四种可能的组合，但是只有三种对应有效的状态。为了将“不可能”的状态移除，你可以将 `'typing'`、`'submitting'` 以及 `'success'` 这三个中的其中一个与 `status` 结合。
+* **这个 state 是否会导致矛盾？**例如，`isTyping` 与 `isSubmitting` 的状态不能同时为 `true`。矛盾的产生通常说明了这个 state 没有足够的约束条件。两个布尔值有四种可能的组合，但是只有三种对应有效的状态。为了将“不可能”的状态移除，你可以将 `'typing'`、`'submitting'` 以及 `'success'` 这三个中的其中一个与 `status` 结合。
 * **相同的信息是否已经在另一个 state 变量中存在？**另一个矛盾：`isEmpty` 和 `isTyping` 不能同时为 `true`。通过使它们成为独立的 state 变量，可能会导致它们不同步并导致 bug。幸运的是，你可以移除 `isEmpty` 转而用 `message.length === 0`。
-* **你是否可以在另一个相反的 state 变量中得到相同的信息？**`isError` 是多余的，因为你可以检查 `error !== null`。
+* **你是否可以通过另一个 state 变量的相反值得到相同的信息？**`isError` 是多余的，因为你可以检查 `error !== null`。
 
 在清理之后，你只剩下 3 个（从原本的 7 个！）*必要*的 state 变量：
 
@@ -472,7 +473,7 @@ function submitForm(answer) {
 
 </Sandpack>
 
-尽管这些代码相对与最初的命令式的例子来说更长，但是却更健壮。将所有的交互变为 state 的改变，可以让你避免之后引入新的视图状态后导致现有 state 被破坏。同时也使你在不必改变交互逻辑本身的情况下，更改每个状态中应该显示的内容。
+尽管这些代码相对与最初的命令式的例子来说更长，但是却更不易损。将所有的交互变为 state 的改变，可以让你避免之后引入新的视图状态后导致现有 state 被破坏。同时也使你在不必改变交互逻辑本身的情况下，更改每个状态中应该显示的内容。
 
 <Recap>
 
@@ -492,7 +493,7 @@ function submitForm(answer) {
 
 ### 添加和删除一个 CSS 类名 {/*add-and-remove-a-css-class*/}
 
-试试当点击图片时*删除*外部 `<div>` 的类名 `background--active`，但是将 `picture--active` 的类名添加到 `<img>` 上。当再次点击背景图片时恢复最开始的 CSS 类名。
+试一试实现当点击图片时*删除*外部 `<div>` 的类名 `background--active`，并将 `picture--active` 的类名添加到 `<img>` 上。当再次点击背景图片时将恢复最开始的 CSS 类名。
 
 视觉上，你应该期望当点击图片时会移除紫色的背景，并且高亮图片的边框。点击图片外面时高亮背景并且删除图片边框的高亮效果。
 
@@ -550,7 +551,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 一个布尔类型的 state 已经足够表示图片是否处于激活状态。最初的工作仅仅是移除或添加 CSS 类名。然而在 React 中你需要去*描述*什么是你想要看到的而非*操作* UI 元素。因此你需要基于当前 state 去计算这两个 CSS 类名。同时你需要去 [阻止冒泡行为](/learn/responding-to-events#stopping-propagation)，只有这样点击图片的时候不会触发点击背景的回调。
 
-检验这个通过点击图片然后点击图片的外面：
+通过点击图片然后点击图片外围来确定这个版本可用：
 
 <Sandpack>
 
@@ -690,7 +691,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 ### 个人信息编辑器 {/*profile-editor*/}
 
-这是一个通过扁平的 JavaScript 和 DOM 实现的小型表单。通过与它交互来理解它的行为表现：
+这是一个通过纯 JavaScript 和 DOM 实现的小型表单。通过与它交互来理解它的行为表现：
 
 <Sandpack>
 
@@ -787,11 +788,11 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-这个表单的模式切换在两个模式中：在编辑中的模式，你可以看到输入框；在查看模式，你只能看到结果。按钮的标签会根据你所处的模式在“编辑”和“保存”两者中切换。当你改变输入框的内容时，欢迎的信息会最下面实时更新。
+这个表单在两种模式间切换：编辑模式，你可以看到输入框；查看模式，你只能看到结果。按钮的标签会根据你所处的模式在“编辑”和“保存”两者中切换。当你改变输入框的内容时，欢迎信息会最下面实时更新。
 
 你的任务是在 下方的沙盒中用 React 再次实现它。为了方便，标记已经转换为 JSX，但是你需要让它像原版那样显示和隐藏输入框。
 
-也要确保它会在按钮中更新文本内容！
+也要确保它在底下更新文本内容！
 
 <Sandpack>
 
@@ -1215,7 +1216,7 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-你所写的 `updateDOM` 函数展示了当你设置 state 时，React 在幕后都做了什么。（然而，为了那些自上次设置 state 后未改变的属性，React 同样避免修改 DOM。）
+你所写的 `updateDOM` 函数展示了当你设置 state 时，React 在幕后都做了什么。（然而，React 同样避免修改那些自上次设置 state 后未改变的属性所相对应的 DOM）
 
 </Solution>
 

From a4dfb3b985e42eabf8e93d1653b17ca855900471 Mon Sep 17 00:00:00 2001
From: HyBer <59885141+BBboy01@users.noreply.github.com>
Date: Sat, 18 Feb 2023 13:27:10 +0800
Subject: [PATCH 04/11] docs(cn): Apply suggestions from code review

---
 .../learn/reacting-to-input-with-state.md     | 42 +++++++++----------
 1 file changed, 21 insertions(+), 21 deletions(-)

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 e71caae83d..ebf94f4830 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -35,7 +35,7 @@ React 使用声明式模式控制 UI。你不必直接控制 UI 的各个部分
 
 他并不知道你想去哪，只想跟着命令行动。（并且如果你发出了错误的命令，那么你就会到达错误的地方）正因为你必须从加载动画到按钮地“命令”每个元素，所以这种告诉计算机*如何*去更新 UI 的编程方式被称为*命令式编程*
 
-在这个命令式 UI 编程的例子中，表单没有使用 React 生成，而是使用原生的 [DOM](https://developer.mozilla.org/zh-CN/docs/Web/API/Document_Object_Model):
+在这个命令式 UI 编程的例子中，表单**没有使用** React 生成，而是使用原生的 [DOM](https://developer.mozilla.org/zh-CN/docs/Web/API/Document_Object_Model):
 
 <Sandpack>
 
@@ -159,11 +159,11 @@ React 正是为了解决这样的问题而诞生的。
 
 首先，你需要去可视化 UI 界面中用户可能看到的所有不同的“状态”：
 
-* **无数据**：表单有一个不可用状态的“提交”按钮
-* **输入中**：表单有一个可用状态的“提交”按钮
-* **提交中**：表单完全处于不可用状态，加载动画出现
-* **成功时**：显示“成功”的消息而非表单
-* **错误时**：与输入状态类似，但会多错误的消息
+* **无数据**：表单有一个不可用状态的“提交”按钮。
+* **输入中**：表单有一个可用状态的“提交”按钮。
+* **提交中**：表单完全处于不可用状态，加载动画出现。
+* **成功时**：显示“成功”的消息而非表单。
+* **错误时**：与输入状态类似，但会多错误的消息。
 
 像一个设计师一样，你会想要在你添加逻辑之前去“模拟”不同的状态或创建“模拟状态”。例如下面的例子，这是一个对表单可视部分的模拟。这个模拟被一个 `status` 的属性控制，并且这个属性的默认值为 `empty`。
 
@@ -202,7 +202,7 @@ export default function Form({
 
 ```js
 export default function Form({
-  // Try 'submitting', 'error', 'success'：
+  // Try 'submitting', 'error', 'success':
   status = 'empty'
 }) {
   if (status === 'success') {
@@ -492,11 +492,11 @@ function submitForm(answer) {
 
 * 声明式编程意味着为每个视图状态声明 UI 而非细致地控制 UI（命令式）。
 * 当开发一个组件时：
-  1. 定位你的组件中不同的视图状态
-  2. 确定是什么触发了这些 state 的改变
-  3. 通过 `useState` 模块化内存中的 state
-  4. 删除任何不必要的 state 变量
-  5. 连接事件处理函数去设置 state
+  1. 定位你的组件中不同的视图状态。
+  2. 确定是什么触发了这些 state 的改变。
+  3. 通过 `useState` 模块化内存中的 state。
+  4. 删除任何不必要的 state 变量。
+  5. 连接事件处理函数去设置 state。
 
 </Recap>
 
@@ -504,9 +504,9 @@ function submitForm(answer) {
 
 <Challenges>
 
-#### 添加和删除一个 CSS 类名 {/*add-and-remove-a-css-class*/}
+#### 添加和删除一个 CSS class {/*add-and-remove-a-css-class*/}
 
-试一试实现当点击图片时*删除*外部 `<div>` 的类名 `background--active`，并将 `picture--active` 的类名添加到 `<img>` 上。当再次点击背景图片时将恢复最开始的 CSS 类名。
+尝试实现当点击图片时*删除*外部 `<div>` 的 CSS class `background--active`，并将 `picture--active` 的 CSS class 添加到 `<img>` 上。当再次点击背景图片时将恢复最开始的 CSS class。
 
 视觉上，你应该期望当点击图片时会移除紫色的背景，并且高亮图片的边框。点击图片外面时高亮背景并且删除图片边框的高亮效果。
 
@@ -518,7 +518,7 @@ export default function Picture() {
     <div className="background background--active">
       <img
         className="picture"
-        alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
+        alt="Rainbow houses in Kampung Pelangi, Indonesia"
         src="https://i.imgur.com/5qwVYb1.jpeg"
       />
     </div>
@@ -559,10 +559,10 @@ body { margin: 0; padding: 0; height: 250px; }
 
 这个组件有两个视图状态：当图片处于激活状态时以及当图片处于非激活状态时：
 
-* 当图片处于激活状态时，CSS 类名是 `background` 和 `picture picture--active`。
-* 当图片处于非激活状态时，CSS 类名是 `background background--active` 和 `picture`。
+* 当图片处于激活状态时，CSS class 是 `background` 和 `picture picture--active`。
+* 当图片处于非激活状态时，CSS class 是 `background background--active` 和 `picture`。
 
-一个布尔类型的 state 已经足够表示图片是否处于激活状态。最初的工作仅仅是移除或添加 CSS 类名。然而在 React 中你需要去*描述*什么是你想要看到的而非*操作* UI 元素。因此你需要基于当前 state 去计算这两个 CSS 类名。同时你需要去 [阻止冒泡行为](/learn/responding-to-events#stopping-propagation)，只有这样点击图片的时候不会触发点击背景的回调。
+一个布尔类型的 state 已经足够表示图片是否处于激活状态。最初的工作仅仅是移除或添加 CSS class。然而在 React 中你需要去*描述*什么是你想要看到的而非*操作* UI 元素。因此你需要基于当前 state 去计算这两个 CSS class。同时你需要去 [阻止冒泡行为](/learn/responding-to-events#stopping-propagation)，只有这样点击图片的时候不会触发点击背景的回调。
 
 通过点击图片然后点击图片外围来确定这个版本可用：
 
@@ -593,7 +593,7 @@ export default function Picture() {
           setIsActive(true);
         }}
         className={pictureClassName}
-        alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
+        alt="Rainbow houses in Kampung Pelangi, Indonesia"
         src="https://i.imgur.com/5qwVYb1.jpeg"
       />
     </div>
@@ -648,7 +648,7 @@ export default function Picture() {
       >
         <img
           className="picture picture--active"
-          alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
+          alt="Rainbow houses in Kampung Pelangi, Indonesia"
           src="https://i.imgur.com/5qwVYb1.jpeg"
           onClick={e => e.stopPropagation()}
         />
@@ -659,7 +659,7 @@ export default function Picture() {
     <div className="background background--active">
       <img
         className="picture"
-        alt="印度尼西亚，Kampung Pelangi 的彩虹屋"
+        alt="Rainbow houses in Kampung Pelangi, Indonesia"
         src="https://i.imgur.com/5qwVYb1.jpeg"
         onClick={() => setIsActive(true)}
       />

From 96657e8c9e9da426c2d1bf6473184cc128bebb4e Mon Sep 17 00:00:00 2001
From: HyBer <59885141+BBboy01@users.noreply.github.com>
Date: Sat, 18 Feb 2023 14:25:28 +0800
Subject: [PATCH 05/11] docs(cn): Apply suggestions from code review for more
 localization translate

Co-authored-by: Xavi Lee <awxiaoxian2020@163.com>
---
 beta/src/content/learn/reacting-to-input-with-state.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

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 ebf94f4830..c29ffc1a69 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -8,19 +8,19 @@ translators:
 
 <Intro>
 
-React 使用声明式模式控制 UI。你不必直接控制 UI 的各个部分，而应该声明你的组件可以处于的不同 state，并根据用户的输入在它们之间切换。这与设计师对 UI 的思考方式很相似。
+React 控制 UI 的方式是声明式的。你不必直接控制 UI 的各个部分，只需要声明组件可以处于的不同状态，并根据用户的输入在它们之间切换。这与设计师对 UI 的思考方式很相似。
 
 </Intro>
 
 <YouWillLearn>
 
 * 了解声明式 UI 编程与命令式 UI 编程有何不同
-* 了解如何列举你的组件可能处于的不同视图状态
+* 了解如何列举组件可能处于的不同视图状态
 * 了解如何在代码中触发不同视图状态的变化
 
 </YouWillLearn>
 
-## 声明式 UI 与 命令式 UI 的比较 {/*how-declarative-ui-compares-to-imperative*/}
+## 声明式 UI 与命令式 UI 的比较 {/*how-declarative-ui-compares-to-imperative*/}
 
 当你设计 UI 交互时，可能会去思考 UI 如何根据用户的操作而响应**变化**。想象一个允许用户提交一个答案的表单：
 
@@ -149,11 +149,11 @@ React 正是为了解决这样的问题而诞生的。
 
 1. **定位**你的组件中不同的视图状态
 2. **确定**是什么触发了这些 state 的改变
-3. **表示**内存中的 state，通过 `useState`
+3. **表示**内存中的 state（需要使用 `useState`）
 4. **删除**任何不必要的 state 变量
 5.  **连接**事件处理函数去设置 state
 
-### 步骤 1：定位你的组件中不同的视图状态 {/*step-1-identify-your-components-different-visual-states*/}
+### 步骤 1：定位组件中不同的视图状态 {/*step-1-identify-your-components-different-visual-states*/}
 
 在计算机科学中，你或许听过可处于多种“状态”之一的 [“状态机”](https://en.wikipedia.org/wiki/Finite-state_machine)。如果你有与设计师一起工作，那么你可能已经见过不同“视图状态”的模拟图。正因为 React 站在设计与计算机科学的交点上，因此这两种思想都是灵感的来源。
 

From 2ffec4cbe184c1d07becc09210ecf020b491c58b Mon Sep 17 00:00:00 2001
From: BBBoy01 <1156678002@qq.com>
Date: Sat, 18 Feb 2023 21:46:39 +0800
Subject: [PATCH 06/11] docs(cn): fix the symbols and keep some word original

---
 beta/src/content/learn/reacting-to-input-with-state.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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 c29ffc1a69..523b9d0c49 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -311,7 +311,7 @@ body { margin: 0; }
 
 </Sandpack>
 
-类似这样的页面通常被称作“实时风格指南”或“故事板”。
+类似这样的页面通常被称作“living styleguides”或“storybooks”。
 
 </DeepDive>
 
@@ -341,7 +341,7 @@ body { margin: 0; }
 
 <DiagramGroup>
 
-<Diagram name="responding_to_input_flow" height={350} width={688} alt="流程图从左到右共有 5 个节点。第一个 ’empty‘ 节点通过 ’start typing‘ 分支与 ’typing‘ 节点相连。‘typing’ 节点则通过 ‘press submit’ 分支与拥有两个分支的 ‘submitting’ 节点相连。其中 ‘submitting’ 节点左侧通过 ’network error‘ 分支与 ’error‘ 节点相连，而右侧则是通过 ’network success‘ 分支与 ’success‘ 节点相连。">
+<Diagram name="responding_to_input_flow" height={350} width={688} alt="流程图从左到右共有 5 个节点。第一个 'empty' 节点通过 'start typing' 分支与 'typing' 节点相连。'typing' 节点则通过 'press submit' 分支与拥有两个分支的 'submitting' 节点相连。其中 'submitting' 节点左侧通过 'network error' 分支与 'error' 节点相连，而右侧则是通过 'network success' 分支与 'success' 节点相连。">
 
 表单的各种状态
 

From d29b4582ff13ca41c79d0cede05a51901eca0f46 Mon Sep 17 00:00:00 2001
From: Xavi Lee <awxiaoxian2020@163.com>
Date: Sat, 18 Feb 2023 21:58:40 +0800
Subject: [PATCH 07/11] Update
 beta/src/content/learn/reacting-to-input-with-state.md

---
 beta/src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 523b9d0c49..b543cf0cb6 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -328,7 +328,7 @@ body { margin: 0; }
   <Illustration caption="计算机输入" alt="许多的 0 和 1。" src="/images/docs/illustrations/i_inputs2.png" />
 </IllustrationBlock>
 
-以上两种情况中，**你必须设置 [ state 变量](/learn/state-a-components-memory#anatomy-of-usestate)去更新 UI**。对于正在开发中的表单来说，你需要改变 state 以响应几个不同的输入：
+以上两种情况中，**你必须设置 [state 变量](/learn/state-a-components-memory#anatomy-of-usestate) 去更新 UI**。对于正在开发中的表单来说，你需要改变 state 以响应几个不同的输入：
 
 * **改变输入框中的文本时**（人为）应该根据输入框的内容是否是**空值**，从而决定将表单的状态从空值状态切换到**输入中**或切换回原状态。
 * **点击提交按钮时**（人为）应该将表单的状态切换到**提交中**的状态。

From d11495437a9945d4b208d859ee4abdf9b84b1158 Mon Sep 17 00:00:00 2001
From: HyBer <59885141+BBboy01@users.noreply.github.com>
Date: Sat, 25 Feb 2023 16:58:56 +0800
Subject: [PATCH 08/11] docs(cn): Apply suggestions from code review

Co-authored-by: TimLi <daochouwangu@gmail.com>
---
 .../learn/reacting-to-input-with-state.md     | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

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 b543cf0cb6..803e7b64d8 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -151,7 +151,7 @@ React 正是为了解决这样的问题而诞生的。
 2. **确定**是什么触发了这些 state 的改变
 3. **表示**内存中的 state（需要使用 `useState`）
 4. **删除**任何不必要的 state 变量
-5.  **连接**事件处理函数去设置 state
+5. **连接**事件处理函数去设置 state
 
 ### 步骤 1：定位组件中不同的视图状态 {/*step-1-identify-your-components-different-visual-states*/}
 
@@ -353,14 +353,14 @@ body { margin: 0; }
 
 接下来你会需要在内存中通过 [`useState`](/reference/react/useState) 表示组件中的视图状态。诀窍很简单：state 的每个部分都是“处于变化中的”，并且**你需要让“变化的部分”尽可能的少**。更复杂的程序会产生更多 bug！
 
-先从*绝对必须*存在的状态开始。例如，你需要存储输入的 `message` 以及用于存储最后一个错误的 `error` （如果存在的话）：
+先从*绝对必须*存在的状态开始。例如，你需要存储输入的 `answer` 以及用于存储最后一个错误的 `error` （如果存在的话）：
 
 ```js
 const [answer, setAnswer] = useState('');
 const [error, setError] = useState(null);
 ```
 
-之后你需要一个 state 变量来代表你之前声明过的想要展示的视图状态之一。通常不止一种可以在内存中代表的方法，因此你需要试验一下。
+之后你需要一个 state 变量来表示你想显示前面描述的哪一种视觉状态。通常不止一种在内存中表示的方法，因此你需要试验一下。
 
 如果你很难立即想出最好的办法，那就先从添加足够多的 state 开始，*确保*所有可能的视图状态都囊括其中：
 
@@ -376,7 +376,7 @@ const [isError, setIsError] = useState(false);
 
 ### 步骤 4：删除任何不必要的 state 变量 {/*step-4-remove-any-non-essential-state-variables*/}
 
-你会想要避免 state 内容中的重复，从而只需要关注那些必要的部分。花一点时间来重构你的 state 结构，会让你的组件更容易被理解，减少重复并且避免歧义。你的目的是**防止出现在内存中的 state 不代表任何你希望用户看到的有效 UI 的情况。**（比如你绝对不会想要在展示错误信息的时候同时禁用掉输入框，导致用户无法纠正错误！）
+你会想要避免 state 内容中的重复，从而只需要关注那些必要的部分。花一点时间来重构你的 state 结构，会让你的组件更容易被理解，减少重复并且避免歧义。你的目的是**防止出现在内存中的 state 不代表任何你希望用户看到的有效 UI 的情况。**（比如你绝对不会想要在展示错误信息的同时禁用掉输入框，导致用户无法纠正错误！）
 
 这有一些你可以问自己的， 关于 state 变量的问题：
 
@@ -398,13 +398,13 @@ const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 's
 
 #### 通过 reducer 来减少“不可能” state {/*eliminating-impossible-states-with-a-reducer*/}
 
-尽管这三个变量对于表示这个表单的状态来说已经足够好了，仍然是有一些中间状态并不是完全有意义的。例如一个非空的 `error` 当 `status` 的值为 `success` 时没有意义。为了更精确地模块化状态，你可以 [将状态提取到一个 reducer 中](/learn/extracting-state-logic-into-a-reducer)。Reducers 可以让您合并多个状态变量到一个对象中并巩固所有相关的逻辑！
+尽管这三个变量对于表示这个表单的状态来说已经足够好了，仍然是有一些中间状态并不是完全有意义的。例如一个非空的 `error` 当 `status` 的值为 `success` 时没有意义。为了更精确地模块化状态，你可以 [将状态提取到一个 reducer 中](/learn/extracting-state-logic-into-a-reducer)。Reducer 可以让您合并多个状态变量到一个对象中并巩固所有相关的逻辑！
 
 </DeepDive>
 
 ### 步骤 5：连接事件处理函数以设置 state {/*step-5-connect-the-event-handlers-to-set-state*/}
 
-最后，创建事件处理函数去设置 state 变量。下方的是在 React 中表单的最终形式，所有的事件处理函数都相关联起来了：
+最后，创建事件处理函数去设置 state 变量。下面是绑定好事件的最终表单：
 
 <Sandpack>
 
@@ -492,7 +492,7 @@ function submitForm(answer) {
 
 * 声明式编程意味着为每个视图状态声明 UI 而非细致地控制 UI（命令式）。
 * 当开发一个组件时：
-  1. 定位你的组件中不同的视图状态。
+  1. 写出你的组件中所有的视图状态。
   2. 确定是什么触发了这些 state 的改变。
   3. 通过 `useState` 模块化内存中的 state。
   4. 删除任何不必要的 state 变量。
@@ -704,7 +704,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 #### 个人信息编辑器 {/*profile-editor*/}
 
-这是一个通过纯 JavaScript 和 DOM 实现的小型表单。通过与它交互来理解它的行为表现：
+这是一个通过纯 JavaScript 和 DOM 实现的小型表单。先来随便使用一下来看看它有什么功能吧：
 
 <Sandpack>
 
@@ -803,7 +803,7 @@ label { display: block; margin-bottom: 20px; }
 
 这个表单在两种模式间切换：编辑模式，你可以看到输入框；查看模式，你只能看到结果。按钮的标签会根据你所处的模式在“编辑”和“保存”两者中切换。当你改变输入框的内容时，欢迎信息会最下面实时更新。
 
-你的任务是在 下方的沙盒中用 React 再次实现它。为了方便，标记已经转换为 JSX，但是你需要让它像原版那样显示和隐藏输入框。
+你的任务是在下方的沙盒中用 React 再次实现它。为了方便，标记已经转换为 JSX，但是你需要让它像原版那样显示和隐藏输入框。
 
 也要确保它在底下更新文本内容！
 
@@ -906,7 +906,7 @@ label { display: block; margin-bottom: 20px; }
 
 #### 不使用 React 去重构命令式的解决方案 {/*refactor-the-imperative-solution-without-react*/}
 
-这是之前的挑战中的没有使用 React 而写的命令式原始沙盒：
+这是之前的挑战中的没有使用 React 而写的命令式代码：
 
 <Sandpack>
 
@@ -1005,7 +1005,7 @@ label { display: block; margin-bottom: 20px; }
 
 如果没有 React，你可以十分健壮地并且使其与 React 的版本十分相似地重构这个代码吗？像 React 那样，如果 state 是明确的，这个重构的代码会是什么样的？
 
-如果你不知道该从哪里入手，下面的部分已经有了大部分的结构。如果你从这里开始的话，只需要在 `updateDOM` 函数中补充缺失的逻辑即可。（需要时请参考原始代码）
+如果你不知道该从哪里入手，下面的代码已经有了大部分的结构。如果你从这里开始的话，只需要在 `updateDOM` 函数中补充缺失的逻辑即可。（需要时请参考原始代码）
 
 <Sandpack>
 
@@ -1229,7 +1229,7 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-你所写的 `updateDOM` 函数展示了当你设置 state 时，React 在幕后都做了什么。（然而，React 同样避免修改那些自上次设置 state 后未改变的属性所相对应的 DOM）
+你所写的 `updateDOM` 函数展示了当你设置 state 时，React 在幕后都做了什么。（而且 React 不会修改对应 state 没改变的 DOM）
 
 </Solution>
 

From de6a844c0e5a5a00973d8c1eec77d5302cbd41f1 Mon Sep 17 00:00:00 2001
From: BBBoy01 <1156678002@qq.com>
Date: Sat, 25 Feb 2023 17:01:56 +0800
Subject: [PATCH 09/11] docs(cn): Apply review suggestions with some modify

---
 beta/src/content/learn/reacting-to-input-with-state.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

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 803e7b64d8..6df601808d 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -145,7 +145,7 @@ React 正是为了解决这样的问题而诞生的。
 
 ## 声明式地考虑 UI {/*thinking-about-ui-declaratively*/}
 
-你已经从上面的例子看到如何去实现一个表单了，为了更好地理解如何在 React 中思考，你将会在下面用 React 重新实现操作 UI：
+你已经从上面的例子看到如何去实现一个表单了，为了更好地理解如何在 React 中思考，接下来你将会学到如何用 React 重新实现这个 UI：
 
 1. **定位**你的组件中不同的视图状态
 2. **确定**是什么触发了这些 state 的改变
@@ -196,7 +196,7 @@ export default function Form({
 
 </Sandpack>
 
-你可以随意命名这个属性，名字并不重要。试着将 `status = 'empty'` 改为 `status = 'success'`，然后你就会看到成功的信息出现。模拟可以让你在书写任何 UI 逻辑前快速地找到更好的方法。这是同一组件的一个更加充实的原型，仍然由 `status` 属性“控制”：
+你可以随意命名这个属性，名字并不重要。试着将 `status = 'empty'` 改为 `status = 'success'`，然后你就会看到成功的信息出现。模拟可以让你在书写逻辑前快速迭代 UI。这是同一组件的一个更加充实的原型，仍然由 `status` 属性“控制”：
 
 <Sandpack>
 
@@ -311,7 +311,7 @@ body { margin: 0; }
 
 </Sandpack>
 
-类似这样的页面通常被称作“living styleguides”或“storybooks”。
+类似这样的页面通常被称作“living styleguide”或“storybook”。
 
 </DeepDive>
 

From b000a6b9e149201686770a9788cae24b10111637 Mon Sep 17 00:00:00 2001
From: BBBoy01 <1156678002@qq.com>
Date: Sat, 25 Feb 2023 17:25:48 +0800
Subject: [PATCH 10/11] docs(cn): Apply review suggestions with some
 re-translate

---
 beta/src/content/learn/reacting-to-input-with-state.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

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 6df601808d..21476e591e 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -486,7 +486,7 @@ function submitForm(answer) {
 
 </Sandpack>
 
-尽管这些代码相对与最初的命令式的例子来说更长，但是却更不易损。将所有的交互变为 state 的改变，可以让你避免之后引入新的视图状态后导致现有 state 被破坏。同时也使你在不必改变交互逻辑本身的情况下，更改每个状态中应该显示的内容。
+尽管这些代码相对与最初的命令式的例子来说更长，但是却更加健壮。将所有的交互变为 state 的改变，可以让你避免之后引入新的视图状态后导致现有 state 被破坏。同时也使你在不必改变交互逻辑的情况下，更改每个状态对应的 UI。
 
 <Recap>
 
@@ -698,7 +698,7 @@ body { margin: 0; padding: 0; height: 250px; }
 
 </Sandpack>
 
-请记住，如果两个不同的 JSX 代码块描述着相同的树结构，它们的嵌套（第一个 `<div>` → 第一个 `<img>`）必须对齐。否则切换 `isActive` 会再次在后面创建整个树结构并且 [重置 state](/learn/preserving-and-resetting-state)。这也就是为什么当一个相似的 JSX 树结构在两个情况下都返回的时候，最好将它们写成单独的 JSX。
+请记住，如果两个不同的 JSX 代码块描述着相同的树结构，它们的嵌套（第一个 `<div>` → 第一个 `<img>`）必须对齐。否则切换 `isActive` 会再次在后面创建整个树结构并且 [重置 state](/learn/preserving-and-resetting-state)。这也就是为什么当一个相似的 JSX 树结构在两个情况下都返回的时候，最好将它们写成一个单独的 JSX。
 
 </Solution>
 
@@ -1003,7 +1003,7 @@ label { display: block; margin-bottom: 20px; }
 
 </Sandpack>
 
-如果没有 React，你可以十分健壮地并且使其与 React 的版本十分相似地重构这个代码吗？像 React 那样，如果 state 是明确的，这个重构的代码会是什么样的？
+如果不用 React，你能否将这段代码重构得像 React 版本一样健壮？如果要让它的 state 像 React 版本一样清晰且明确，那么这段代码又会写成怎样的呢？
 
 如果你不知道该从哪里入手，下面的代码已经有了大部分的结构。如果你从这里开始的话，只需要在 `updateDOM` 函数中补充缺失的逻辑即可。（需要时请参考原始代码）
 

From 03fadb6a1326172190e841c2ad10c7213c8f7eda Mon Sep 17 00:00:00 2001
From: BBBoy01 <1156678002@qq.com>
Date: Mon, 6 Mar 2023 13:32:29 +0800
Subject: [PATCH 11/11] docs(cn): Apply review suggestions for doc Title

---
 beta/src/content/learn/reacting-to-input-with-state.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 21476e591e..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,5 +1,5 @@
 ---
-title: State 驱动输入
+title: 用 State 响应输入
 translators:
   - BBboy01
   - KimYangOfCat