// JSX 是用来描述这些对象的语法糖。 
// <button className="blue" /> 
{ 
  type: 'button', 
  props: { className: 'blue' } 
}  
1.
2.
3.
4.
5.
6.

// JSX 是用来描述这些对象的语法糖。 
// <dialog> 
//   <button className="blue" /> 
//   <button className="red" /> 
// </dialog> 
{ 
  type: 'dialog', 
  props: { 
    children: [{ 
      type: 'button', 
      props: { className: 'blue' } 
    }, { 
      type: 'button', 
      props: { className: 'red' } 
    }] 
  } 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

ReactDOM.render( 
  // { type: 'button', props: { className: 'blue' } } 
  <button className="blue" />, 
  document.getElementById('container') 
);  
1.
2.
3.
4.
5.

// 在 ReactDOM 渲染器内部（简化版） 
function createHostInstance(reactElement) { 
  let domNode = document.createElement(reactElement.type);   
  domNode.className = reactElement.props.className; 
  return domNode; 
}  
1.
2.
3.
4.
5.
6.

let domNode = document.createElement('button'); 
domNode.className = 'blue'; 
domContainer.appendChild(domNode);  
1.
2.
3.

ReactDOM.render( 
  <button className="blue" />,  document.getElementById('container') 
); 
 
// ... 之后 ... 
 
// 应该替换掉 button 宿主实例吗？ 
// 还是在已有的 button 上更新属性？ 
ReactDOM.render( 
  <button className="red" />,  document.getElementById('container') 
);  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

let domContainer = document.getElementById('container'); 
// 清除掉原来的树 
domContainer.innerHTML = ''; 
// 创建新的宿主实例树 
let domNode = document.createElement('button'); 
domNode.className = 'red'; 
domContainer.appendChild(domNode);  
1.
2.
3.
4.
5.
6.
7.

let domNode = domContainer.firstChild; 
// 更新已有的宿主实例 
domNode.className = 'red';  
1.
2.
3.

// let domNode = document.createElement('button'); 
// domNode.className = 'blue'; 
// domContainer.appendChild(domNode); 
ReactDOM.render( 
  <button className="blue" />, 
  document.getElementById('container') 
); 
 
// 能重用宿主实例吗？能！(button → button) 
// domNode.className = 'red'; 
ReactDOM.render( 
  <button className="red" />, 
  document.getElementById('container') 
); 
 
// 能重用宿主实例吗？不能！(button → p) 
// domContainer.removeChild(domNode); 
// domNode = document.createElement('p'); 
// domNode.textContent = 'Hello'; 
// domContainer.appendChild(domNode); 
ReactDOM.render( 
  <p>Hello</p>, 
  document.getElementById('container') 
); 
 
// 能重用宿主实例吗？能！(p → p) 
// domNode.textContent = 'Goodbye'; 
ReactDOM.render( 
  <p>Goodbye</p>, 
  document.getElementById('container') 
);  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

// ***次渲染 
ReactDOM.render( 
  <dialog> 
    <input /> 
  </dialog>, 
  domContainer 
); 
 
// 下一次渲染 
ReactDOM.render( 
  <dialog> 
    <p>I was just added here!</p>     
      <input /> 
  </dialog>, 
  domContainer 
);  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

let oldInputNode = dialogNode.firstChild; 
dialogNode.removeChild(oldInputNode); 
 
let pNode = document.createElement('p'); 
pNode.textContent = 'I was just added here!'; 
dialogNode.appendChild(pNode); 
 
let newInputNode = document.createElement('input'); 
dialogNode.appendChild(newInputNode);  
1.
2.
3.
4.
5.
6.
7.
8.
9.

function Form({ showMessage }) { 
  let message = null; 
  if (showMessage) { 
    message = <p>I was just added here!</p>; 
  } 
  return ( 
    <dialog> 
      {message} 
      <input /> 
    </dialog> 
  ); 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

function Form({ showMessage }) { 
  let message = null; 
  if (showMessage) { 
    message = { 
      type: 'p', 
      props: { children: 'I was just added here!' } 
    }; 
  } 
  return { 
    type: 'dialog', 
    props: { 
      children: [ 
        message, 
        { type: 'input', props: {} } 
      ] 
    } 
  }; 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

let inputNode = dialogNode.firstChild;  
let pNode = document.createElement('p');  
pNode.textContent = 'I was just added here!';  
dialogNode.insertBefore(pNode, inputNode);  
1.
2.
3.
4.

function ShoppingList({ list }) { 
  return ( 
    <form> 
      {list.map(item => ( 
        <p> 
          You bought {item.name} 
          <br /> 
          Enter how many do you want: <input /> 
        </p> 
      ))} 
    </form> 
  ) 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

for (let i = 0; i < 10; i++) { 
  let pNode = formNode.childNodes[i]; 
  let textNode = pNode.firstChild; 
  textNode.textContent = 'You bought ' + items[i].name; 
}  
1.
2.
3.
4.
5.

function ShoppingList({ list }) { 
  return ( 
    <form> 
      {list.map(item => ( 
        <p key={item.productId}> 
          You bought {item.name} 
          <br /> 
          Enter how many do you want: <input /> 
        </p> 
      ))} 
    </form> 
  ) 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

function Form({ showMessage }) { 
  let message = null; 
  if (showMessage) { 
    message = <p>I was just added here!</p>; 
  } 
  return ( 
    <dialog> 
      {message} 
      <input /> 
    </dialog> 
  ); 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

function Button(props) { 
  // 🔴 没有作用 
  props.isActive = true; 
}  
1.
2.
3.
4.

function FriendList({ friends }) { 
  let items = []; 
  for (let i = 0; i < friends.length; i++) { 
    let friend = friends[i]; 
    items.push( 
      <Friend key={friend.id} friend={friend} /> 
    ); 
  } 
  return <section>{items}</section>; 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

function ExpenseForm() { 
  // 只要不影响其他组件这是被允许的： 
  SuperCalculator.initializeIfNotReady(); 
 
  // 继续渲染...... 
} 
1.
2.
3.
4.
5.
6.

let reactElement = Form({ showMessage: true });  
ReactDOM.render(reactElement, domContainer);  
1.
2.

// { type: Form, props: { showMessage: true } } 
let reactElement = <Form showMessage={true} />; 
ReactDOM.render(reactElement, domContainer); 
1.
2.
3.

// React 内部的某个地方 
let type = reactElement.type; // Form 
let props = reactElement.props; // { showMessage: true } 
let result = type(props); // 无论 Form 会返回什么 
1.
2.
3.
4.

console.log(.type); // 'form' 字符串  
console.log(.type); // Form 函数  
1.
2.

让 React 调用你的组件函数还有***一个好处就是惰性求值。让我们看看它是什么意思。

惰性求值

当我们在 JavaScript 中调用函数时，参数往往在函数调用之前被执行。

// (2) 它会作为第二个计算 
eat( 
  // (1) 它会首先计算 
  prepareMeal() 
); 
1.
2.
3.
4.
5.

这通常是 JavaScript 开发者所期望的因为 JavaScript 函数可能有隐含的副作用。如果我们调用了一个函数，但直到它的结果不知怎地被“使用”后该函数仍没有执行，这会让我们感到十分诧异。

但是，React 组件是相对纯净的。如果我们知道它的结果不会在屏幕上出现，则完全没有必要执行它。

考虑下面这个含有 <Comments> 的 <Page> 组件：

function Story({ currentUser }) { 
  // return { 
  //   type: Page, 
  //   props: { 
  //     user: currentUser, 
  //     children: { type: Comments, props: {} } 
  //   } 
  // } 
  return ( 
    <Page user={currentUser}> 
      <Comments /> 
    </Page> 
  ); 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

<Page> 组件能够在 <Layout> 中渲染传递给它的子项：

function Page({ user, children }) { 
  return ( 
    <Layout> 
      {children} 
    </Layout> 
  ); 
} 
1.
2.
3.
4.
5.
6.
7.

 (在 JSX 中 <A><B /></A> 和 <A children={<B />} /> 相同。)

但是要是存在提前返回的情况呢?

function Page({ user, children }) { 
  if (!user.isLoggedIn) { 
    return <h1>Please log in</h1>; 
  } 
  return ( 
    <Layout> 
      {children} 
    </Layout> 
  ); 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

如果我们像函数一样调用 Commonts() ，不管 Page 是否想渲染它们都会被立即执行：

// { 
//   type: Page, 
//   props: { 
//     children: Comments() // Always runs! 
//   } 
// } 
<Page> 
  {Comments()} 
</Page>  
1.
2.
3.
4.
5.
6.
7.
8.
9.

但是如果我们传递的是一个 React 元素，我们不需要自己执行 Comments ：

// { 
//   type: Page, 
//   props: { 
//     children: { type: Comments } 
//   } 
// } 
<Page> 
  <Comments /> 
</Page>  
1.
2.
3.
4.
5.
6.
7.
8.
9.

让 React 来决定何时以及是否调用组件。如果我们的的 Page 组件忽略自身的 childrenprop 且相反地渲染了 <h1>Please login</h1> ，React 不会尝试去调用 Comments 函数。重点是什么？ 

这很好，因为它既可以让我们避免不必要的渲染也能使我们的代码变得不那么脆弱。（当用户退出登录时，我们并不在乎 Comments 是否被丢弃 — 因为它从没有被调用过。）

状态

我们先前提到过关于协调和在树中元素概念上的“位置”是如何让 React 知晓是该重用宿主实例还是该重建它。宿主实例能够拥有所有相关的局部状态：focus、selection、input 等等。我们想要在渲染更新概念上相同的 UI 时保留这些状态。我们也想可预测性地摧毁它们，当我们在概念上渲染的是完全不同的东西时(例如从 <SignupForm> 转换到 <MessengerChat> )。

局部状态是如此有用，以至于 React 让你的组件也能拥有它。 组件仍然是函数但是 React 用对构建 UI 有好处的许多特性增强了它。在树中每个组件所绑定的局部状态就是这些特性之一。

我们把这些特性叫做 Hooks 。例如，useState 就是一个 Hook 。

function Example() { 
  const [count, setCount] = useState(0); 
 
  return ( 
    <div> 
      <p>You clicked {count} times</p> 
      <button onClick={() => setCount(count + 1)}> 
        Click me 
      </button> 
    </div> 
  ); 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

它返回一对值：当前的状态和更新该状态的函数。

数组的解构语法让我们可以给状态变量自定义名称。例如，我在这里称它们为 count 和 setCount ，但是它们也可以被称作 banana 和 setBanana 。在这些文字之下，我们会用 setState 来替代第二个值无论它在具体的例子中被称作什么。 

(你能在 React 文档 中学习到更多关于 useState 和 其他 Hooks 的知识。) 

一致性 

即使我们想将协调过程本身分割成非阻塞的工作块，我们仍然需要在同步的循环中对真实的宿主实例进行操作。这样我们才能保证用户不会看见半更新状态的 UI ，浏览器也不会对用户不应看到的中间状态进行不必要的布局和样式的重新计算。 

这也是为什么 React 将所有的工作分成了”渲染阶段“和”提交阶段“的原因。渲染阶段 是当 React 调用你的组件然后进行协调的时段。在此阶段进行干涉是安全的且在未来这个阶段将会变成异步的。提交阶段 就是 React 操作宿主树的时候。而这个阶段永远是同步的。

缓存

当父组件通过 setState 准备更新时，React 默认会协调整个子树。因为 React 并不知道在父组件中的更新是否会影响到其子代，所以 React 默认保持一致性。这听起来会有很大的性能消耗但事实上对于小型和中型的子树来说，这并不是问题。

当树的深度和广度达到一定程度时，你可以让 React 去缓存子树并且重用先前的渲染结果当 prop 在浅比较之后是相同时： 

function Row({ item }) { 
  // ... 
} 
 
export default React.memo(Row);  
1.
2.
3.
4.
5.

现在，在父组件 中调用 setState 时如果 中的 item 与先前渲染的结果是相同的，React 就会直接跳过协调的过程。  

你可以通过 useMemo() Hook 获得单个表达式级别的细粒度缓存。该缓存于其相关的组件紧密联系在一起，并且将与局部状态一起被销毁。它只会保留***一次计算的结果。

默认情况下，React 不会故意缓存组件。许多组件在更新的过程中总是会接收到不同的 props ，所以对它们进行缓存只会造成净亏损。

原始模型

令人讽刺地是，React 并没有使用“反应式”的系统来支持细粒度的更新。换句话说，任何在顶层的更新只会触发协调而不是局部更新那些受影响的组件。

这样的设计是有意而为之的。对于 web 应用来说交互时间是一个关键指标，而通过遍历整个模型去设置细粒度的监听器只会浪费宝贵的时间。此外，在很多应用中交互往往会导致或小(按钮悬停)或大(页面转换)的更新，因此细粒度的订阅只会浪费内存资源。

React 的设计原则之一就是它可以处理原始数据。如果你拥有从网络请求中获得的一组 JavaScript 对象，你可以将其直接交给组件而无需进行预处理。没有关于可以访问哪些属性的问题，或者当结构有所变化时造成的意外的性能缺损。React 渲染是 O(视图大小) 而不是 O(模型大小) ，并且你可以通过 windowing 显著地减少视图大小。

有那么一些应用细粒度订阅对它们来说是有用的 — 例如股票代码。这是一个极少见的例子，因为“所有的东西都需要在同一时间内持续更新”。虽然命令式的方法能够优化此类代码，但 React 并不适用于这种情况。同样的，如果你想要解决该问题，你就得在 React 之上自己实现细粒度的订阅。

注意，即使细粒度订阅和“反应式”系统也无法解决一些常见的性能问题。 例如，渲染一棵很深的树(在每次页面转换的时候发生)而不阻塞浏览器。改变跟踪并不会让它变得更快 — 这样只会让其变得更慢因为我们执行了额外的订阅工作。另一个问题是我们需要等待返回的数据在渲染视图之前。在 React 中，我们用并发渲染来解决这些问题。

批量更新

一些组件也许想要更新状态来响应同一事件。下面这个例子是假设的，但是却说明了一个常见的模式：

function Parent() { 
  let [count, setCount] = useState(0); 
  return ( 
    <div onClick={() => setCount(count + 1)}> 
      Parent clicked {count} times 
      <Child /> 
    </div> 
  ); 
} 
 
function Child() { 
  let [count, setCount] = useState(0); 
  return ( 
    <button onClick={() => setCount(count + 1)}> 
      Child clicked {count} times 
    </button> 
  ); 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

当事件被触发时，子组件的 onClick 首先被触发(同时触发了它的 setState )。然后父组件在它自己的 onClick 中调用 setState 。

如果 React 立即重渲染组件以响应 setState 调用，最终我们会重渲染子组件两次： 

*** 进入 React 浏览器 click 事件处理过程 *** 
Child (onClick) 
  - setState 
  - re-render Child // 😞 不必要的重渲染Parent (onClick) 
  - setState 
  - re-render Parent 
  - re-render Child 
*** 结束 React 浏览器 click 事件处理过程 ***  
1.
2.
3.
4.
5.
6.
7.
8.

***次 Child 组件渲染是浪费的。并且我们也不会让 React 跳过 Child 的第二次渲染因为 Parent 可能会传递不同的数据由于其自身的状态更新。

这就是为什么 React 会在组件内所有事件触发完成后再进行批量更新的原因： 

*** 进入 React 浏览器 click 事件处理过程 *** 
Child (onClick) 
  - setState 
Parent (onClick) 
  - setState 
*** Processing state updates           *** 
  - re-render Parent 
  - re-render Child 
*** 结束 React 浏览器 click 事件处理过程  ***  
1.
2.
3.
4.
5.
6.
7.
8.
9.

组件内调用 setState 并不会立即执行重渲染。相反，React 会先触发所有的事件处理器，然后再触发一次重渲染以进行所谓的批量更新。

批量更新虽然有用但可能会让你感到惊讶如果你的代码这样写：

const [count, setCounter] = useState(0); 
 
  function increment() { 
    setCounter(count + 1); 
  } 
 
  function handleClick() { 
    increment(); 
    increment(); 
    increment(); 
  }  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

如果我们将 count 初始值设为 0 ，上面的代码只会代表三次 setCount(1) 调用。为了解决这个问题，我们给 setState 提供了一个 “updater” 函数作为参数： 

const [count, setCounter] = useState(0); 
 
  function increment() { 
    setCounter(c => c + 1); 
  } 
 
  function handleClick() { 
    increment(); 
    increment(); 
    increment(); 
  }  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

React 会将 updater 函数放入队列中，并在之后按顺序执行它们，最终 count 会被设置成 3 并作为一次重渲染的结果。

当状态逻辑变得更加复杂而不仅仅只是少数的 setState 调用时，我建议你使用 useReducer Hook 来描述你的局部状态。它就像 “updater” 的升级模式在这里你可以给每一次更新命名： 

const [counter, dispatch] = useReducer((state, action) => { 
    if (action === 'increment') { 
      return state + 1; 
    } else { 
      return state; 
    } 
  }, 0); 
 
  function handleClick() { 
    dispatch('increment'); 
    dispatch('increment'); 
    dispatch('increment'); 
  }  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

action 字段可以是任意值，尽管对象是常用的选择。

调用树

编程语言的运行时往往有调用栈 。当函数 a() 调用 b() ，b() 又调用 c() 时，在 JavaScript 引擎中会有像 [a, b, c] 这样的数据结构来“跟踪”当前的位置以及接下来要执行的代码。一旦 c 函数执行完毕，它的调用栈帧就消失了!因为它不再被需要了。我们返回到函数 b 中。当我们结束函数 a 的执行时，调用栈就被清空。

当然，React 以 JavaScript 运行当然也遵循 JavaScript 的规则。但是我们可以想象在 React 内部有自己的调用栈用来记忆我们当前正在渲染的组件，例如 [App, Page, Layout, Article /* 此刻的位置 */] 。

React 与通常意义上的编程语言进行时不同因为它针对于渲染 UI 树，这些树需要保持“活性”，这样才能使我们与其进行交互。在***次 ReactDOM.render() 出现之前，DOM 操作并不会执行。

这也许是对隐喻的延伸，但我喜欢把 React 组件当作 “调用树” 而不是 “调用栈” 。当我们调用完 Article 组件，它的 React “调用树” 帧并没有被摧毁。我们需要将局部状态保存以便映射到宿主实例的某个地方。

这些“调用树”帧会随它们的局部状态和宿主实例一起被摧毁，但是只会在协调规则认为这是必要的时候执行。如果你曾经读过 React 源码，你就会知道这些帧其实就是 Fibers) 。

Fibers 是局部状态真正存在的地方。当状态被更新后，React 将其下面的 Fibers 标记为需要进行协调，之后便会调用这些组件。

上下文

在 React 中，我们将数据作为 props 传递给其他组件。有些时候，大多数组件需要相同的东西 — 例如，当前选中的可视主题。将它一层层地传递会变得十分麻烦。

在 React 中，我们通过 Context 解决这个问题。它就像组件的动态范围 ，能让你从顶层传递数据，并让每个子组件在底部能够读取该值，当值变化时还能够进行重新渲染： 

const ThemeContext = React.createContext( 
  'light' // 默认值作为后备 
); 
 
function DarkApp() { 
  return ( 
    <ThemeContext.Provider value="dark"> 
      <MyComponents /> 
    </ThemeContext.Provider> 
  ); 
} 
 
function SomeDeeplyNestedChild() { 
  // 取决于其子组件在哪里被渲染 
  const theme = useContext(ThemeContext); 
  // ... 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

当 SomeDeeplyNestedChild 渲染时， useContext(ThemeContext) 会寻找树中最近的 ，并且使用它的 value 。

(事实上，React 维护了一个上下文栈当其渲染时。)

如果没有 ThemeContext.Provider 存在，useContext(ThemeContext) 调用的结果就会被调用 createContext() 时传递的默认值所取代。在上面的例子中，这个值为 'light' 。

副作用

我们在之前提到过 React 组件在渲染过程中不应该有可观察到的副作用。但是有些时候副作用确实必要的。我们也许需要进行管理 focus 状态、用 canvas 画图、订阅数据源等操作。

在 React 中，这些都可以通过声明 effect 来完成： 

function Example() { 
  const [count, setCount] = useState(0); 
 
  useEffect(() => { 
    document.title = `You clicked ${count} times`; 
  }); 
 
  return ( 
    <div> 
      <p>You clicked {count} times</p> 
      <button onClick={() => setCount(count + 1)}> 
        Click me 
      </button> 
    </div> 
  ); 
}  
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

如果可能，React 会推迟执行 effect 直到浏览器重新绘制屏幕。这是有好处的因为像订阅数据源这样的代码并不会影响交互时间和***绘制时间 。

(有一个极少使用的 Hook 能够让你选择退出这种行为并进行一些同步的工作。请尽量避免使用它。)

effect 不只执行一次。当组件***次展示给用户以及之后的每次更新时它都会被执行。在 effect 中能触及当前的 props 和 state，例如上文例子中的 count 。

effect 可能需要被清理，例如订阅数据源的例子。在订阅之后将其清理，effect 能够返回一个函数： 

useEffect(() => { 
    DataSource.addSubscription(handleChange); 
    return () => DataSource.removeSubscription(handleChange); 
  });  
1.
2.
3.
4.

React 会在下次调用该 effect 之前执行这个返回的函数，当然是在组件被摧毁之前。

有些时候，在每次渲染中都重新调用 effect 是不符合实际需要的。 你可以告诉 React 如果相应的变量不会改变则跳过此次调用： 

useEffect(() => { 
   document.title = `You clicked ${count} times`; 
 }, [count]);  
1.
2.
3.

但是，这往往会成为过早地优化并会造成一些问题如果你不熟悉 JavaScript 中的闭包是如何工作的话。

例如，下面的这段代码是有 bug 的：

useEffect(() => {  
DataSource.addSubscription(handleChange);  
return () => DataSource.removeSubscription(handleChange);  
}, []); 
1.
2.
3.
4.

它含有 bug 因为 [] 代表着“不再重新执行这个 effect 。”但是这个 effect 中的 handleChange 是被定义在外面的。handleChange 也许会引用任何的 props 或 state ：

function handleChange() { 
 
    console.log(count); 
 
} 
1.
2.
3.
4.
5.

如果我们不再让这个 effect 重新调用，handleChange 始终会是***次渲染时的版本，而其中的 count 也永远只会是 0 。

为了解决这个问题，请保证你声明了特定的依赖数组，它包含所有可以改变的东西，即使是函数也不例外：

useEffect(() => {  
DataSource.addSubscription(handleChange);  
return () => DataSource.removeSubscription(handleChange);  
}, [handleChange]); 
1.
2.
3.
4.

取决于你的代码，在每次渲染后 handleChange 都会不同因此你可能仍然会看到不必要的重订阅。 useCallback 能够帮你解决这个问题。或者，你可以直接让它重订阅。例如浏览器中的 addEventListener API 非常快，但为了在组件中避免使用它可能会带来更多的问题而不是其真正的价值。

(你能在 React 文档 中学到更多关于 useEffect 和其他 Hooks 的知识。)

自定义钩子

由于 useState 和 useEffect 是函数调用，因此我们可以将其组合成自己的 Hooks ：

function MyResponsiveComponent() { 
  const width = useWindowWidth(); // 我们自己的 Hook   
  return ( 
    <p>Window width is {width}</p> 
  ); 
} 
 
function useWindowWidth() {   
  const [width, setWidth] = useState(window.innerWidth); 
  useEffect(() => { 
    const handleResize = () => setWidth(window.innerWidth); 
    window.addEventListener('resize', handleResize); 
    return () => { 
      window.removeEventListener('resize', handleResize); 
    }; 
  }); 
  return width; 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

自定义 Hooks 让不同的组件共享可重用的状态逻辑。注意状态本身是不共享的。每次调用 Hook 都只声明了其自身的独立状态。

(你能在 React 文档 中学习更多关于构建自己的 Hooks 的内容。)

静态使用顺序

你可以把 useState 想象成一个可以定义“React 状态变量”的语法。它并不是真正的语法，当然，我们仍在用 JavaScript 编写应用。但是我们将 React 作为一个运行时环境来看待，因为 React 用 JavaScript 来描绘整个 UI 树，它的特性往往更接近于语言层面。

假设 use 是语法，将其使用在组件函数顶层也就说得通了：

// 😉 注意：并不是真的语法 
component Example(props) { 
  const [count, setCount] = use State(0); 
 
  return ( 
    <div> 
      <p>You clicked {count} times</p> 
      <button onClick={() => setCount(count + 1)}> 
        Click me 
      </button> 
    </div> 
  ); 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

当它被放在条件语句中或者组件外时又代表什么呢?

// 😉 注意：并不是真的语法 
 
// 它是谁的...局部状态？ 
const [count, setCount] = use State(0); 
 
component Example() { 
  if (condition) { 
    // 要是 condition 是 false 时会发生什么呢？ 
    const [count, setCount] = use State(0); 
  } 
 
  function handleClick() { 
    // 要是离开了组件函数会发生什么？ 
    // 这和一般的变量又有什么区别呢？ 
    const [count, setCount] = use State(0); 
  } 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

React 状态和在树中与其相关的组件紧密联系在一起。如果 use 是真正的语法当它在组件函数的顶层调用时也能说的通：

// 😉 注意：并不是真的语法 
component Example(props) { 
  // 只在这里有效 
  const [count, setCount] = use State(0); 
 
  if (condition) { 
    // 这会是一个语法错误 
    const [count, setCount] = use State(0); 
  } 
1.
2.
3.
4.
5.
6.
7.
8.
9.

这和 import 声明只在模块顶层有用是一样的道理。

当然，use 并不是真正的语法。 (它不会带来很多好处，并且会带来很多麻烦。)

然而，React 的确期望所有的 Hooks 调用只发生在组件的顶部并且不在条件语句中。这些 Hooks 的规则能够被 linter plugin 所规范。有很多关于这种设计选择的激烈争论，但在实践中我并没有看到它让人困惑。我还写了关于为什么通常提出的替代方案不起作用的文章。

Hooks 的内部实现其实是链表 。当你调用 useState 的时候，我们将指针移到下一项。当我们退出组件的“调用树”帧时，会缓存该结果的列表直到下次渲染开始。

这篇文章简要介绍了 Hooks 内部是如何工作的。数组也许是比链表更好解释其原理的模型：

// 伪代码 
let hooks, i; 
function useState() { 
  i++; 
  if (hooks[i]) { 
    // 再次渲染时 
    return hooks[i]; 
  } 
  // ***次渲染 
  hooks.push(...); 
} 
 
// 准备渲染 
i = -1; 
hooks = fiber.hooks || []; 
// 调用组件 
YourComponent(); 
// 缓存 Hooks 的状态 
fiber.hooks = hooks; 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

(如果你对它感兴趣，完整的代码在这里 。)

这大致就是每个 useState() 如何获得正确状态的方式。就像我们之前所知道的，“匹配”对 React 来说并不是什么新的知识 — 这与协调依赖于在渲染前后元素是否匹配是同样的道理。

还有哪些遗漏

我们已经触及到 React 运行时环境中几乎所有重要的方面。如果你读完了这篇文章，可能已经比 90% 的开发者更了解 React ，没错!

当然有一些内容我并没有提到——主要是因为我们也不太清楚。目前 React 对多道渲染的支持并不太好，即当父组件进行渲染时需要子组件提供的信息。错误处理 API 目前也还没有关于 Hooks 的内容。将来这两个问题可能会一起解决。并发模式在目前看来并不稳定，也有很多关于 Suspense 该如何适应当前版本的有趣问题。也许我会在它们要完成的时候再来讨论，并且 Suspense 已经准备好比 懒加载 能够做的更多。

我认为 React API 的成功之处在于，即使在没有考虑过上面这些大多数主题的情况下，你也能轻松使用它并且可以走的很远。 在大多数情况下，像协调这样好的默认特性启发式地为我们做了正确的事情。在你忘记添加 key 这样的属性时，React 能够好心提醒你。

如果你是一个痴迷于 UI 库的书***，我希望这篇文章对你来说会很有趣的，并且深入阐明了 React 的工作原理。也许你会觉得 React 太过复杂，所以不会再去深入理解它。不管怎样，我都很乐意在 Twitter 上听到你的声音!感谢你的阅读。