{value}

;\n}\n\n// 使用上述组件\nfunction App() {\n return ;\n}\n```\n\n在上述示例中，我们首先使用`createContext`创建一个上下文对象`MyContext`。然后，在`ParentComponent`组件中，我们通过`MyContext.Provider`组件提供了上下文的值，值为`'Hello, World!'`。在`ChildComponent`组件中，我们使用`useContext`钩子获取了上下文的值，并将其显示在页面上。\n\n最终，我们在`App`组件中使用`ParentComponent`组件作为根组件。当渲染应用程序时，`ChildComponent`将获取到上下文的值并显示在页面上。\n\n通过这种方式，`ParentComponent`提供了上下文的值，`ChildComponent`通过`useContext`钩子获取并使用该值，实现了组件之间的数据共享。\n\n","reactions",{"_54":171,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/370/reactions","total_count","+1","-1","laugh","hooray","confused","heart","rocket","eyes","timeline_url","https://api.github.com/repos/pro-collection/interview-question/issues/370/timeline","performed_via_github_app","state_reason","score",{"_54":187,"_56":57,"_58":188,"_60":189,"_62":190,"_64":191,"_66":192,"_68":193,"_70":194,"_72":195,"_74":196,"_107":197,"_127":128,"_129":26,"_130":-5,"_131":199,"_133":200,"_155":148,"_149":202,"_151":203,"_154":-5,"_159":160,"_161":204,"_166":-5,"_167":205,"_169":206,"_181":208,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/349","https://api.github.com/repos/pro-collection/interview-question/issues/349/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/349/comments","https://api.github.com/repos/pro-collection/interview-question/issues/349/events","https://github.com/pro-collection/interview-question/issues/349",1698679648,"I_kwDOJGDC6c5lP8tg",349,"[React] memo 和 useMemo 有和区别？【热度: 654】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[198],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":201,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-05-06T15:47:10Z","2023-05-06T15:47:11Z",{"_163":148,"_164":148,"_165":148},"**关键词**：memo useMemo\n\n`React.memo` 和 `useMemo` 是在 React 中处理性能优化的两个工具，虽然它们名称相似，但是它们的作用和使用方法是不同的。\n\n`React.memo` 是高阶组件，它可以用来优化函数组件的渲染性能。它会比较当前组件的 `props` 和 `state` 是否发生了变化，如果都没有变化，就不会重新渲染该组件，而是直接使用之前的结果。例如：\n\n```jsx\nimport React from 'react';\n \nconst MyComponent = React.memo(props => {\n return

{props.value}

;\n});\n```\n\n在上面的代码中，`React.memo` 包装了一个简单的函数组件 `MyComponent`。如果该组件的 `value` prop 和 `state` 没有发生变化，那么就会直接使用之前的结果不会重新渲染。\n\n`useMemo` 是 `React` 中一个 hooks，它可以用来缓存计算结果，从而优化组件渲染性能。它接受两个参数：要缓存的计算函数和依赖项数组。每当依赖项发生变化时，该计算函数就会重新计算，并返回一个新的结果。例如：\n\n```jsx\nimport React, { useMemo } from 'react';\n \nconst MyComponent = props => {\n const result = useMemo(() => expensiveComputation(props.value), [props.value]);\n return

{result}

;\n};\n```\n\n在上面的代码中，我们传递了一个计算函数 `expensiveComputation`，以及一个依赖项数组 `[props.value]`。如果依赖项没有发生变化，`myValue` 就会被缓存起来，不会重新计算。\n\n总的来说：\n\n`React.memo` 的作用是优化函数组件的渲染性能，它可以比较组件的 `props` 和 `state` 是否发生变化，如果没有变化，就不会重新渲染。\n\n`useMemo` 的作用是缓存计算结果，从而避免重复计算，它接受一个计算函数和一个依赖项数组，当依赖项发生变化时，计算函数就会重新计算，返回一个新的结果，否则就会使用之前的缓存结果。\n",{"_54":207,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/349/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/349/timeline",{"_54":210,"_56":57,"_58":211,"_60":212,"_62":213,"_64":214,"_66":215,"_68":216,"_70":217,"_72":218,"_74":219,"_107":220,"_127":128,"_129":26,"_130":-5,"_131":227,"_133":228,"_155":148,"_149":230,"_151":231,"_154":-5,"_159":160,"_161":232,"_166":-5,"_167":233,"_169":234,"_181":236,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/344","https://api.github.com/repos/pro-collection/interview-question/issues/344/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/344/comments","https://api.github.com/repos/pro-collection/interview-question/issues/344/events","https://github.com/pro-collection/interview-question/issues/344",1698635892,"I_kwDOJGDC6c5lPyB0",344,"[React] createPortal 了解多少？【热度: 597】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[221,222],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":223,"_68":224,"_54":225,"_113":226,"_115":125,"_117":26,"_118":126},5312214934,"LA_kwDOJGDC6c8AAAABPKH3lg","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BD%91%E6%98%93","网易",[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":229,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-05-06T13:38:43Z","2023-05-06T13:38:44Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react createPortal\n\n`createPortal` 是 React 中一个用于将子元素渲染到指定 DOM 元素下的 API。\n\n在 React 应用中，通常会通过组件树传递 props、状态等数据来渲染 UI，并由 React 自动管理 DOM 元素的创建、更新和销毁等操作。不过，有时我们需要将某些 UI 元素渲染到根节点之外的 DOM 元素下，例如弹出框、模态框等。这时，`createPortal` 就能派上用场了。\n\n`createPortal` 的用法如下：\n\n```jsx\nReactDOM.createPortal(child, container)\n```\n\n其中，`child` 是指要渲染的子元素，可以是任何有效的 React 元素，包括组件、HTML 元素等等；`container` 是指要将子元素渲染到的 DOM 元素，可以是一个有效的 DOM 元素对象，例如通过 `document.getElementById` 获取到的 DOM 元素。`createPortal` 会将 `child` 渲染到 `container` 中，但仍然能够受到 React 生命周期的管理，例如 `componentDidMount` 和 `componentWillUnmount` 等方法。\n\n下面是一个例子，它展示了如何使用 `createPortal` 来将一个弹出框渲染到根节点之外的 DOM 元素下：\n\n```jsx\nfunction Dialog(props) {\n return ReactDOM.createPortal(\n

{props.title}

{props.content}

,\n document.getElementById('dialog-container')\n );\n}\n\nfunction App() {\n return (\n

这是一个文本内容。

\n );\n}\n\nReactDOM.render(, document.getElementById('root'));\n```\n\n在这个例子中，`Dialog` 组件使用 `createPortal` 将其子元素渲染到 `#dialog-container` 这个元素下，而不是直接渲染到 `#root` 下。这个功能使得我们可以在 React 应用中方便地处理弹出框等类似需求。\n",{"_54":235,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/344/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/344/timeline",{"_54":238,"_56":57,"_58":239,"_60":240,"_62":241,"_64":242,"_66":243,"_68":244,"_70":245,"_72":246,"_74":247,"_107":248,"_127":128,"_129":26,"_130":-5,"_131":255,"_133":256,"_155":148,"_149":269,"_151":270,"_154":-5,"_159":160,"_161":271,"_166":-5,"_167":272,"_169":273,"_181":275,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/343","https://api.github.com/repos/pro-collection/interview-question/issues/343/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/343/comments","https://api.github.com/repos/pro-collection/interview-question/issues/343/events","https://github.com/pro-collection/interview-question/issues/343",1698631800,"I_kwDOJGDC6c5lPxB4",343,"[React] createElement 和 cloneElement 有什么区别【热度: 218】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[249,250],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":251,"_68":252,"_54":253,"_113":254,"_115":125,"_117":26,"_118":126},5342931240,"LA_kwDOJGDC6c8AAAABPnapKA","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BE%8E%E5%9B%A2","美团",[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":265,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/3","https://github.com/pro-collection/interview-question/milestone/3","https://api.github.com/repos/pro-collection/interview-question/milestones/3/labels",9124547,"MI_kwDOJGDC6c4AizrD",3,"高","高级别面试问题",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},425,"2023-03-06T15:00:27Z","2025-02-10T16:49:33Z","2023-05-06T13:27:11Z","2023-05-06T13:27:12Z",{"_163":148,"_164":148,"_165":148},"**关键词**：createElement cloneElement\n\n### `createElement` 和 `cloneElement` 有什么区别?\n\nReact 中的 `createElement` 和 `cloneElement` 都可以用来创建元素，但它们用法有所不同。\n\n`createElement` 用于在 React 中动态地创建一个新的元素，并返回一个 React 元素对象。它的用法如下：\n\n```jsx\nReact.createElement(type, [props], [...children]);\n```\n\n其中，`type` 是指要创建的元素的类型，可以是一个 HTML 标签名（如 `div`、`span` 等），也可以是一个 React 组件类（如自定义的组件），`props` 是一个包含该元素需要设置的属性信息的对象，`children` 是一个包含其子元素的数组。`createElement` 会以这些参数为基础创建并返回一个 React 元素对象，React 将使用它来构建真正的 DOM 元素。\n\n`cloneElement` 用于复制一个已有的元素，并返回一个新的 React 元素，同时可以修改它的一些属性。它的用法如下：\n\n```jsx\nReact.cloneElement(element, [props], [...children]);\n```\n\n其中，`element` 是指要复制的 React 元素对象，`props` 是一个包含需要覆盖或添加的属性的对象，`children` 是一个包含其修改后的子元素的数组。`cloneElement` 会以这些参数为基础复制该元素，并返回一个新的 React 元素对象。\n\n在实际使用中，`createElement` 通常用于创建新的元素（如动态生成列表），而 `cloneElement` 更适用于用于修改已有的元素，例如在一个组件内部使用 `cloneElement` 来修改传递进来的子组件的属性。\n\n\n### `cloneElement` 有哪些应用场景\n\nReact 中的 `cloneElement` 主要适用于以下场景：\n\n1. 修改 props\n\n`cloneElement` 可以用于复制一个已有的元素并覆盖或添加一些新的属性。例如，可以复制一个带有默认属性的组件并传递新的属性，达到修改属性的目的。\n\n```jsx\n// 假设有这样一个组件\nfunction MyComponent(props) {\n // ...\n}\n\n// 在另一个组件中使用 cloneElement 修改 MyComponent 的 props\nfunction AnotherComponent() {\n return React.cloneElement(, { color: 'red' });\n}\n```\n\n2. 渲染列表\n\n在渲染列表时，可以使用 `Array.map()` 生成一系列的元素数组，也可以使用 `React.Children.map()` 遍历子元素并返回一系列的元素数组，同时使用 `cloneElement` 复制元素并传入新的 key 和 props。\n\n```jsx\n// 使用 Children.map() 遍历子元素并复制元素\nfunction MyList({ children, color }) {\n return (\n

\n {React.Children.map(children, (child, index) =>\n React.cloneElement(child, { key: index, color })\n )}\n \n );\n}\n\n// 在组件中使用 MyList 渲染列表元素\nfunction MyPage() {\n return (\n \n

Item 1

Item 2

Item 3

\n \n );\n}\n```\n\n3. 修改子元素\n\n使用 `cloneElement` 也可以在一个组件内部修改传递进来的子组件的属性，例如修改按钮的样式。\n\n```jsx\nfunction ButtonGroup({ children, style }) {\n return (\n

\n {React.Children.map(children, (child) =>\n React.cloneElement(child, { style: { color: 'red' } })\n )}\n

\n );\n}\n\nfunction MyPage() {\n return (\n \n \n \n \n );\n}\n```\n\n总之，`cloneElement` 可以方便地复制已有的 React 元素并修改其属性，适用于许多场景，例如修改 props、渲染列表和修改子元素等。\n\n",{"_54":274,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/343/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/343/timeline",{"_54":277,"_56":57,"_58":278,"_60":279,"_62":280,"_64":281,"_66":282,"_68":283,"_70":284,"_72":285,"_74":286,"_107":287,"_127":128,"_129":26,"_130":-5,"_131":294,"_133":295,"_155":148,"_149":297,"_151":298,"_154":-5,"_159":160,"_161":299,"_166":-5,"_167":300,"_169":301,"_181":303,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/336","https://api.github.com/repos/pro-collection/interview-question/issues/336/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/336/comments","https://api.github.com/repos/pro-collection/interview-question/issues/336/events","https://github.com/pro-collection/interview-question/issues/336",1697813398,"I_kwDOJGDC6c5lMpOW",336,"[React] 事件绑定原理【热度: 1,097】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[288,289],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":290,"_68":291,"_54":292,"_113":293,"_115":125,"_117":26,"_118":126},5326133419,"LA_kwDOJGDC6c8AAAABPXZYqw","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%B0%8F%E7%B1%B3","小米",[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":296,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-05-05T15:31:51Z","2023-05-05T15:47:20Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react事件绑定、react合成事件、react事件监听\n\n### 绑定原理与过程\n\n在 React 中，事件绑定不同于传统的直接在 HTML 元素添加事件监听器的方式。React 的事件绑定是建立在自定义组件上的，因此需要对 React 组件的生命周期进行理解。\n\nReact 事件绑定的原理可以概括为三个步骤：\n\n1. 创建 React 元素\n\n在 React 中，事件的绑定是通过在 JSX 中创建元素时给元素添加一个事件属性实现的。例如：\n\n```\n\n```\n\n这里使用 onClick 属性将组件的 handleClick 方法传递给一个按钮组件，这个按钮组件在点击之后会调用 handleClick 方法。\n\n2. 挂载事件处理函数\n\n当 React 元素插入文档中之后，React 会在元素宿主节点上挂载事件处理函数。这个过程是在 React 元素生成之后、组件挂载之前完成的。React 在执行组件挂载生命周期函数之前，会将所有元素上声明的事件处理函数统一挂载到 DOM 上。\n\n3. 移除事件处理函数\n\n当 React 元素被移除文档时，React 会自动移除对应的事件处理函数。这个过程是在组件卸载之后、元素从 DOM 中移除之前执行的。\n\nReact 的事件绑定表现为组件的方法，所以在事件处理函数中，可以通过 this 关键字来访问组件的状态和属性。\n\n需要注意的是，React 组件中不能使用原生事件绑定方式，比如使用 `element.addEventListener('click', function(){})`，因为这样做会导致 React 无法正确地跟踪组件状态的变化，从而可能导致一些潜在问题。\n\n### React 组件中为何不能使用原生事件绑定方式\n\nReact 组件中不能使用原生事件绑定方式是因为，React 使用的是 Virtual DOM 技术，而不是直接操作 DOM。React 的 Virtual DOM 能够自动监测组件（即数据）状态的变化和更新，从而根据更新后的状态重新渲染视图，并在必要的时候更新真实 DOM。\n\n如果使用原生事件绑定方式，比如使用 `element.addEventListener('click', function(){})`，那么这些绑定的事件处理函数是直接绑定在真实的 DOM 元素上的，并不参与 Virtual DOM 中的数据流程，这样就会导致以下两个问题：\n\n1. 事件绑定后，如果组件状态变化并且重新渲染，那么重新渲染后的组件实例会重新创建一个新的 DOM 元素，而旧的 DOM 元素会被销毁，导致原来的事件处理函数被绑定在了一个不存在的元素上，导致事件失效。\n\n2. 使用原生事件绑定方式，无法在事件处理函数中直接访问组件实例的状态和属性。例如，在事件处理函数中想要访问一个组件的状态或者属性，就必须使用组件实例的引用（即 this 指针），但是这个 this 指针指向的并不是组件实例本身，而是真实的 DOM 元素，这样就无法直接访问组件状态和属性。\n\n因此，在 React 中，我们必须使用 `onClick` 等钩子函数来绑定事件处理函数，这样 React 就能够在其 Virtual DOM 中正确地跟踪组件状态变化，并保证事件处理函数的正确性。当然，在一些极端的情况下，React 也提供了访问真实 DOM 元素的机制，比如 `ref` 属性，这个可以在某些场景下使用。\n",{"_54":302,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/336/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/336/timeline",{"_54":305,"_56":57,"_58":306,"_60":307,"_62":308,"_64":309,"_66":310,"_68":311,"_70":312,"_72":313,"_74":314,"_107":315,"_127":128,"_129":26,"_130":-5,"_131":317,"_133":318,"_155":148,"_149":320,"_151":321,"_154":-5,"_159":160,"_161":322,"_166":-5,"_167":323,"_169":324,"_181":326,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/327","https://api.github.com/repos/pro-collection/interview-question/issues/327/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/327/comments","https://api.github.com/repos/pro-collection/interview-question/issues/327/events","https://github.com/pro-collection/interview-question/issues/327",1696291845,"I_kwDOJGDC6c5lG1wF",327,"[React] fiber 是如何实现时间切片的？【热度: 587】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[316],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":319,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-05-04T16:15:25Z","2023-05-04T16:19:06Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、fiber 时间切片、fiber 时间、react 协调器\r\n\r\n### 基本原理\r\n\r\n本质上来说就是将渲染任务拆分成多个小任务，以便提高应用程序的响应性和性能。React Fiber 实现时间切片主要依赖于两个核心功能：**任务分割和任务优先级**。\r\n\r\n任务分割是指将一个大的渲染任务切割成多个小任务，每个小任务只负责一小部分 DOM 更新。React Fiber 使用 Fiber 节点之间的父子关系，将一个组件树分割成多个”片段“，每个“片段”内部是一颗 Fiber 子树，多个“片段”之间可以交错执行，实现时间切片。\r\n\r\n任务优先级是指 React Fiber 提供了一套基于优先级的算法来决定哪些任务应该先执行，哪些任务可以放到后面执行。React Fiber 将任务分成多个优先级级别，较高优先级的任务在进行渲染时会优先进行，从而确保应用程序的响应性和性能。\r\n\r\nReact Fiber 实现时间切片的基本原理如下：\r\n\r\n1. React Fiber 会将渲染任务划分成多个小任务，每个小任务一般只负责一小部分 DOM 更新。\r\n2. React Fiber 将这些小任务保存到任务队列中，并按照优先级进行排序和调度。\r\n3. 当浏览器处于空闲状态时，React Fiber 会从任务队列中取出一个高优先级的任务并执行，直到任务完成或者时间片用完。\r\n4. 如果任务完成，则将结果提交到 DOM 树上并开始下一个任务。如果时间片用完，则将任务挂起，并将未完成的工作保存到 Fiber 树中，返回控制权给浏览器。\r\n5. 当浏览器再次处于空闲状态时，React Fiber 会再次从任务队列中取出未完成的任务并继续执行，直到所有任务完成。\r\n\r\n通过使用任务分割和任务优先级算法，React Fiber 实现了时间切片功能，保证了应用程序的响应性和性能，提高了用户的使用体验。\r\n\r\n### 是如何实现任务分割的？伪代码实现一下\r\n\r\nReact Fiber 实现任务分割的过程十分复杂，需要涉及到 Fiber 数据结构、调度器、DOM 操作等多个部分。以下是一个简单的示例代码，演示了 React Fiber 任务分割的基本工作原理。\r\n\r\n```jsx\r\nconst workInProgressFiber = {};\r\n\r\nconst performUnitOfWork = () => {\r\n // 执行当前 Fiber 对应的组件\r\n const isFunctionComponent = workInProgressFiber.type instanceof Function; \r\n if (isFunctionComponent) {\r\n updateFunctionComponent(workInProgressFiber);\r\n } else {\r\n updateHostComponent(workInProgressFiber);\r\n }\r\n\r\n // 返回下一个待处理的 Fiber 节点\r\n if (workInProgressFiber.child) {\r\n return workInProgressFiber.child;\r\n }\r\n\r\n let nextFiber = workInProgressFiber;\r\n while (nextFiber) {\r\n if (nextFiber.sibling) {\r\n return nextFiber.sibling;\r\n }\r\n nextFiber = nextFiber.parent;\r\n }\r\n\r\n return null;\r\n};\r\n\r\nconst render = (element, container) => {\r\n const rootFiber = {\r\n dom: container,\r\n props: {\r\n children: [element],\r\n },\r\n };\r\n\r\n workInProgressFiber = rootFiber;\r\n nextUnitOfWork = rootFiber;\r\n\r\n requestIdleCallback(workLoop);\r\n};\r\n\r\nconst workLoop = (deadline) => {\r\n while (nextUnitOfWork && deadline.timeRemaining() > 0) {\r\n nextUnitOfWork = performUnitOfWork(nextUnitOfWork);\r\n }\r\n\r\n if (nextUnitOfWork) {\r\n requestIdleCallback(workLoop);\r\n }\r\n};\r\n\r\nconst updateFunctionComponent = (fiber) => {\r\n const children = [fiber.type(fiber.props)];\r\n reconcileChildren(fiber, children);\r\n};\r\n\r\nconst updateHostComponent = (fiber) => {\r\n if (!fiber.dom) {\r\n fiber.dom = createDom(fiber);\r\n }\r\n\r\n reconcileChildren(fiber, fiber.props.children);\r\n};\r\n\r\nconst reconcileChildren = (fiber, children) => {\r\n let index = 0;\r\n let oldFiber = fiber.alternate ? fiber.alternate.child : null;\r\n let prevSibling = null;\r\n\r\n while (index < children.length || oldFiber) {\r\n const child = children[index];\r\n let newFiber = null;\r\n const sameType = oldFiber && child && child.type === oldFiber.type;\r\n\r\n if (sameType) {\r\n newFiber = {\r\n type: oldFiber.type,\r\n props: child.props,\r\n dom: oldFiber.dom,\r\n parent: fiber,\r\n alternate: oldFiber,\r\n effectTag: 'UPDATE',\r\n };\r\n }\r\n\r\n if (child && !sameType) {\r\n newFiber = {\r\n type: child.type,\r\n props: child.props,\r\n dom: null,\r\n parent: fiber,\r\n alternate: null,\r\n effectTag: 'PLACEMENT',\r\n };\r\n }\r\n\r\n if (oldFiber && !sameType) {\r\n oldFiber.effectTag = 'DELETION';\r\n deletions.push(oldFiber);\r\n }\r\n\r\n if (oldFiber) {\r\n oldFiber = oldFiber.sibling;\r\n }\r\n\r\n if (index === 0) {\r\n fiber.child = newFiber;\r\n } else if (child) {\r\n prevSibling.sibling = newFiber;\r\n }\r\n\r\n prevSibling = newFiber;\r\n\r\n index++;\r\n }\r\n};\r\n```\r\n\r\n在这个示例中，我们定义了一个名为 `performUnitOfWork` 的函数，用于执行一个 Fiber 节点上的任务。这个函数会根据 Fiber 节点的类型，执行不同的操作，并返回下一个待处理的 Fiber 节点。\r\n\r\n在 `updateFunctionComponent` 和 `updateHostComponent` 函数中，我们分别根据 Fiber 节点的类型执行函数组件和普通组件的更新操作。通过 `reconcileChildren` 函数，我们可以将一个组件的子节点拆分成多个 Fiber 节点，并在 `performUnitOfWork` 函数中进行遍历和处理。\r\n\r\nReact Fiber 实现任务分割的核心思想是将一个大的渲染任务切割成多个小任务，每个小任务只负责一小部分 DOM 更新。通过在 Fiber 树上进行遍历和操作，我们可以实现任务分割，提高应用程序的响应性和性能。\r\n\r\n\r\n### react fiber 是如何实现任务优先级的？用代码简单示范一下\r\n\r\nReact Fiber 的任务优先级是通过创建多个优先级队列，并使用一个时间片策略来调度任务的。以下是一个简单的示例代码，用于演示 React Fiber 的优先级队列和任务优先级机制。\r\n\r\n```jsx\r\nconst MAX_PRIORITY_LEVEL = 5;\r\n\r\nconst NoWork = 0;\r\nconst Sync = 1;\r\nconst DefaultPriority = 3;\r\nconst IdlePriority = 4;\r\nconst AnimationPriority = 5;\r\n\r\nconst initialScheduler = {\r\n didTimeout: false,\r\n enqueuedTasks: [],\r\n scheduledCallback: null,\r\n scheduledCallbackTimeout: null,\r\n taskQueue: [],\r\n currentTime: 0,\r\n};\r\n\r\nlet currentScheduler = initialScheduler;\r\n\r\nconst enableScheduler = () => {\r\n // ...初始化 scheduler 的代码...\r\n};\r\n\r\nconst requestCallback = (callback, options) => {\r\n const currentTime = getCurrentTime();\r\n const timeout = options != null && options.timeout != null ? options.timeout : -1;\r\n const expirationTime =\r\n timeout > 0 ? currentTime + timeout : currentTime + 5 * 1000;\r\n const newTask = {\r\n callback,\r\n priorityLevel: DefaultPriority,\r\n startTime: currentTime,\r\n expirationTime,\r\n };\r\n\r\n currentScheduler.taskQueue.push(newTask);\r\n ensureHostCallbackIsScheduled();\r\n};\r\n\r\nconst ensureHostCallbackIsScheduled = () => {\r\n if (currentScheduler.scheduledCallback === null) {\r\n currentScheduler.scheduledCallback = performSchedulerWork;\r\n currentScheduler.scheduledCallbackTimeout = setTimeout(() => {\r\n performSchedulerWork(currentTime);\r\n }, 0);\r\n }\r\n};\r\n\r\nconst performSchedulerWork = (currentTime) => {\r\n performConcurrentWorkOnRoots();\r\n\r\n if (currentScheduler.taskQueue.length > 0) {\r\n const firstTask = currentScheduler.taskQueue[0];\r\n if (firstTask.startTime <= currentTime) {\r\n currentScheduler.taskQueue.shift();\r\n firstTask.callback({ didTimeout: false });\r\n return;\r\n }\r\n }\r\n};\r\n\r\nconst performConcurrentWorkOnRoots = () => {\r\n const priorityLevel = AnimationPriority;\r\n const deadline = {\r\n timeRemaining() {\r\n return Infinity;\r\n },\r\n };\r\n while (currentScheduler.taskQueue.length > 0) {\r\n const task = findHighestPriorityTask();\r\n if (task.priorityLevel > priorityLevel || task.expirationTime <= currentScheduler.currentTime) {\r\n break;\r\n }\r\n const root = task.callback(deadline);\r\n\r\n if (root !== null) {\r\n // ...执行任务更新...\r\n }\r\n }\r\n};\r\n\r\nconst findHighestPriorityTask = () => {\r\n let highestPriorityTask = null;\r\n let highestPriorityLevel = NoWork;\r\n\r\n for (let i = 0; i < currentScheduler.taskQueue.length; i++) {\r\n const task = currentScheduler.taskQueue[i];\r\n const priorityLevel = task.priorityLevel;\r\n if (priorityLevel > highestPriorityLevel) {\r\n highestPriorityLevel = priorityLevel;\r\n highestPriorityTask = task;\r\n }\r\n }\r\n\r\n return highestPriorityTask;\r\n};\r\n```\r\n\r\n在这个示例中，我们定义了多个优先级常量和优先级队列，以及与之相关的一些变量和函数。我们通过 `requestCallback` 函数，将任务以优先级的方式插入到任务队列中。在 `performConcurrentWorkOnRoots` 函数中，我们按照优先级顺序遍历任务队列，并将任务的回调函数传递给 `callback` 函数执行更新操作。\r\n\r\n通过在任务队列和调度器中使用优先级的方式来调度和执行任务，我们可以在保证页面响应性的同时，最大化利用浏览器的空闲时间，提高应用程序整体的性能和用户体验。\r\n\r\n",{"_54":325,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/327/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/327/timeline",{"_54":328,"_56":57,"_58":329,"_60":330,"_62":331,"_64":332,"_66":333,"_68":334,"_70":335,"_72":336,"_74":337,"_107":338,"_127":128,"_129":26,"_130":-5,"_131":340,"_133":341,"_155":148,"_149":343,"_151":344,"_154":-5,"_159":160,"_161":345,"_166":-5,"_167":346,"_169":347,"_181":349,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/326","https://api.github.com/repos/pro-collection/interview-question/issues/326/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/326/comments","https://api.github.com/repos/pro-collection/interview-question/issues/326/events","https://github.com/pro-collection/interview-question/issues/326",1696273536,"I_kwDOJGDC6c5lGxSA",326,"[React] diff 算法【热度: 538】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[339],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":342,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-05-04T15:45:10Z","2023-05-04T15:45:11Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、react commit 阶段、react 协调器\n\n在 react 中：一个`DOM`节点在某一时刻最多会有4个节点和他相关。\n\n一个DOM节点在某一时刻最多会有4个节点和他相关。\n\n1. `JSX对象`。即ClassComponent的render方法的返回结果，或FunctionComponent的调用结果。JSX对象中包含描述DOM节点的信息。\n\n2. `workInProgress Fiber`。如果该DOM节点将在本次更新中渲染到页面中，workInProgress Fiber代表该DOM节点对应的Fiber节点。\n\n3. `current Fiber`。如果该DOM节点已在页面中，current Fiber代表该DOM节点对应的Fiber节点。\n\n4. `DOM节点本身`。\n\n**Diff算法的本质是对比1和2，生成3。**\n\n### 概览\n\n#### Diff的瓶颈以及React如何应对\n\n由于Diff操作本身也会带来性能损耗，即使在最前沿的算法中，将前后两棵树完全比对的算法的复杂程度为 O(n 3 )，其中n是树中元素的数量。\n\n如果在React中使用了该算法，那么展示1000个元素所需要执行的计算量将在十亿的量级范围\n\n为了降低算法复杂度，**React的diff会预设三个限制**：\n\n1. 只对同级元素进行Diff。如果一个DOM节点在前后两次更新中跨越了层级，那么React不会尝试复用他。\n\n2. 两个不同类型的元素会产生出不同的树。如果元素由div变为p，React会销毁div及其子孙节点，并新建p及其子孙节点。\n\n3. 开发者可以通过 key prop来暗示哪些子元素在不同的渲染下能保持稳定。\n\n#### Diff是如何实现的\n\n我们从Diff的入口函数reconcileChildFibers出发，该函数会根据newChild（即JSX对象）类型调用不同的处理函数。\n\n从同级的节点数量将Diff分为两类：\n\n1. 当newChild类型为object、number、string，代表同级只有一个节点\n\n2. 当newChild类型为Array，同级有多个节点\n\n### 单节点 diff\n\n路程图： \n![image](https://user-images.githubusercontent.com/22188674/235393691-d5355bfb-da2a-4ffd-9961-04a3927ebd11.png)\n\nReact通过先判断key是否相同，如果key相同则判断type是否相同，只有都相同时一个DOM节点才能复用。\n\n### 多节点 diff\n\n主要分为以下几种情况\n\n- 节点更新\n - 节点属性变化\n - 节点类型更新\n- 节点新增或减少\n- 节点位置变化\n\n#### diff 思路\n\nReact 团队发现，在日常开发中，相较于新增和删除，更新组件发生的频率更高。所以Diff会优先判断当前节点是否属于更新。\n\n本质上是进行了两轮遍历：\n- 第一轮遍历：处理更新的节点。\n- 第二轮遍历：处理剩下的不属于更新的节点。\n\n**为何不用双向指针的方式**？\n\n虽然本次更新的JSX对象 newChildren为数组形式，但是和newChildren中每个组件进行比较的是current fiber，同级的Fiber节点是由sibling指针链接形成的单链表，即不支持双指针遍历。\n\n即 newChildren[0]与fiber比较，newChildren[1]与fiber.sibling比较。\n\n所以无法使用双指针优化。\n\n\n#### 第一次遍历\n\n第一轮遍历步骤如下：\n\n1. `let i = 0`，遍历`newChildren`，将`newChildren[i]`与`oldFiber`比较，判断DOM节点是否可复用。\n\n2. 如果可复用，`i++`，继续比较`newChildren[i]`与`oldFiber.sibling`，可以复用则继续遍历。\n\n3. 如果不可复用，分两种情况：\n\n- key不同导致不可复用，立即跳出整个遍历，第一轮遍历结束。\n\n- key相同type不同导致不可复用，会将`oldFiber`标记为`DELETION`，并继续遍历\n\n4. 如果`newChildren`遍历完（即`i === newChildren.length - 1`）或者`oldFiber`遍历完（即`oldFiber.sibling === null`），跳出遍历，第一轮遍历结束。\n\n源码如下： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactChildFiber.new.js#L818\n\n\n#### 第二轮遍历\n\n\n**`newChildren`与`oldFiber`同时遍历完**\n\n那就是最理想的情况：只需在第一轮遍历进行组件更新 \n\n> 源码如下： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactChildFiber.new.js#L825\n\n**`newChildren`没遍历完，`oldFiber`遍历完**\n\n已有的DOM节点都复用了，这时还有新加入的节点，意味着本次更新有新节点插入，我们只需要遍历剩下的`newChildren`为生成的`workInProgress fiber`依次标记`Placement`。\n\n> 源码如下： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactChildFiber.new.js#L869\n\n**`newChildren`遍历完，`oldFiber`没遍历完**\n\n意味着本次更新比之前的节点数量少，有节点被删除了。所以需要遍历剩下的`oldFiber`，依次标记`Deletion`。\n\n> https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactChildFiber.new.js#L863\n\n**`newChildren`与`oldFiber`都没遍历完**\n\n这意味着有节点在这次更新中改变了位置。\n\n这是Diff算法最精髓也是最难懂的部分。我们接下来会重点讲解。\n\n> 源码： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactChildFiber.new.js#L893\n\n\n#### 处理移动的节点\n\n由于有节点改变了位置，所以不能再用位置索引i对比前后的节点，那么如何才能将同一个节点在两次更新中对应上呢？\n\n我们需要使用key。\n\n为了快速的找到key对应的`oldFiber`，我们将所有还未处理的`oldFiber`存入以key为key，`oldFiber`为`value`的`Map`中。\n\n`const existingChildren = mapRemainingChildren(returnFiber, oldFiber);` \n\n> 源码： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactChildFiber.new.js#L890\n\n接下来遍历剩余的`newChildren`，通过`newChildren[i].key`就能在`existingChildren`中找到`key`相同的`oldFiber`。\n\n#### 标记节点是否移动\n\n既然我们的目标是寻找移动的节点，那么我们需要明确：节点是否移动是以什么为参照物？\n\n我们的参照物是：最后一个可复用的节点在`oldFiber`中的位置索引（用变量`lastPlacedIndex`表示）。\n\n由于本次更新中节点是按`newChildren`的顺序排列。在遍历`newChildren`过程中，每个遍历到的可复用节点一定是当前遍历到的所有可复用节点中最靠右的那个，即一定在`lastPlacedIndex`对应的可复用的节点在本次更新中位置的后面。\n\n那么我们只需要比较遍历到的可复用节点在上次更新时是否也在`lastPlacedIndex`对应的`oldFiber`后面，就能知道两次更新中这两个节点的相对位置改变没有。\n\n我们用变量`oldIndex`表示遍历到的可复用节点在`oldFiber`中的位置索引。如果`oldIndex < lastPlacedIndex`，代表本次更新该节点需要向右移动。\n\n`lastPlacedIndex`初始为0，每遍历一个可复用的节点，如果`oldIndex >= lastPlacedIndex`，则`lastPlacedIndex = oldIndex`。\n\n\n### 参考文档\n\n- https://react.iamkasong.com/diff/prepare.html\n",{"_54":348,"_172":156,"_173":156,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/326/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/326/timeline",{"_54":351,"_56":57,"_58":352,"_60":353,"_62":354,"_64":355,"_66":356,"_68":357,"_70":358,"_72":359,"_74":360,"_107":361,"_127":128,"_129":26,"_130":-5,"_131":363,"_133":364,"_155":148,"_149":366,"_151":366,"_154":-5,"_159":160,"_161":367,"_166":-5,"_167":368,"_169":369,"_181":371,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/325","https://api.github.com/repos/pro-collection/interview-question/issues/325/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/325/comments","https://api.github.com/repos/pro-collection/interview-question/issues/325/events","https://github.com/pro-collection/interview-question/issues/325",1689980021,"I_kwDOJGDC6c5kuwx1",325,"[React] commit 阶段的执行过程【热度: 534】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[362],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":365,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-30T16:18:01Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、react commit 阶段、react 协调器\n\ncommitRoot方法是commit阶段工作的起点。fiberRootNode会作为传参。 `commitRoot(root);`\n\n如何走到 commit 阶段的，可以参考这个文档：https://github.com/pro-collection/interview-question/issues/324\n\n在rootFiber.firstEffect上保存了一条需要执行副作用的Fiber节点的单向链表effectList，这些Fiber节点的updateQueue中保存了变化的props。\n\n这些副作用对应的DOM操作在commit阶段执行。\n\n除此之外，一些生命周期钩子（比如componentDidXXX）、hook（比如useEffect）需要在commit阶段执行。\n\ncommit阶段的主要工作（即Renderer的工作流程）分为三部分：\n\nbefore mutation阶段（执行DOM操作前）\n\nmutation阶段（执行DOM操作）\n\nlayout阶段（执行DOM操作后）\n\n你可以从这里看到commit阶段的完整代码： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactFiberWorkLoop.new.js#L2001\n\n在before mutation阶段之前和layout阶段之后还有一些额外工作，涉及到比如useEffect的触发、优先级相关的重置、ref的绑定/解绑。\n\n### before mutation之前\n\n`commitRootImpl`方法中直到第一句`if (firstEffect !== null)`之前属于`before mutation之前`。\n\n我们大体看下他做的工作，现在你还不需要理解他们：\n\n```ts\ndo {\n // 触发useEffect回调与其他同步任务。由于这些任务可能触发新的渲染，所以这里要一直遍历执行直到没有任务\n flushPassiveEffects();\n } while (rootWithPendingPassiveEffects !== null);\n\n // root指 fiberRootNode\n // root.finishedWork指当前应用的rootFiber\n const finishedWork = root.finishedWork;\n\n // 凡是变量名带lane的都是优先级相关\n const lanes = root.finishedLanes;\n if (finishedWork === null) {\n return null;\n }\n root.finishedWork = null;\n root.finishedLanes = NoLanes;\n\n // 重置Scheduler绑定的回调函数\n root.callbackNode = null;\n root.callbackId = NoLanes;\n\n let remainingLanes = mergeLanes(finishedWork.lanes, finishedWork.childLanes);\n // 重置优先级相关变量\n markRootFinished(root, remainingLanes);\n\n // 清除已完成的discrete updates，例如：用户鼠标点击触发的更新。\n if (rootsWithPendingDiscreteUpdates !== null) {\n if (\n !hasDiscreteLanes(remainingLanes) &&\n rootsWithPendingDiscreteUpdates.has(root)\n ) {\n rootsWithPendingDiscreteUpdates.delete(root);\n }\n }\n\n // 重置全局变量\n if (root === workInProgressRoot) {\n workInProgressRoot = null;\n workInProgress = null;\n workInProgressRootRenderLanes = NoLanes;\n } else {\n }\n\n // 将effectList赋值给firstEffect\n // 由于每个fiber的effectList只包含他的子孙节点\n // 所以根节点如果有effectTag则不会被包含进来\n // 所以这里将有effectTag的根节点插入到effectList尾部\n // 这样才能保证有effect的fiber都在effectList中\n let firstEffect;\n if (finishedWork.effectTag > PerformedWork) {\n if (finishedWork.lastEffect !== null) {\n finishedWork.lastEffect.nextEffect = finishedWork;\n firstEffect = finishedWork.firstEffect;\n } else {\n firstEffect = finishedWork;\n }\n } else {\n // 根节点没有effectTag\n firstEffect = finishedWork.firstEffect;\n }\n```\n\n可以看到，before mutation之前主要做一些变量赋值，状态重置的工作。\n\n这一长串代码我们只需要关注最后赋值的firstEffect，在commit的三个子阶段都会用到他。\n\n### layout之后\n接下来让我们简单看下layout阶段执行完后的代码，现在你还不需要理解他们：\n\n```ts\nconst rootDidHavePassiveEffects = rootDoesHavePassiveEffects;\n\n// useEffect相关\nif (rootDoesHavePassiveEffects) {\n rootDoesHavePassiveEffects = false;\n rootWithPendingPassiveEffects = root;\n pendingPassiveEffectsLanes = lanes;\n pendingPassiveEffectsRenderPriority = renderPriorityLevel;\n} else {}\n\n// 性能优化相关\nif (remainingLanes !== NoLanes) {\n if (enableSchedulerTracing) {\n // ...\n }\n} else {\n // ...\n}\n\n// 性能优化相关\nif (enableSchedulerTracing) {\n if (!rootDidHavePassiveEffects) {\n // ...\n }\n}\n\n// ...检测无限循环的同步任务\nif (remainingLanes === SyncLane) {\n // ...\n} \n\n// 在离开commitRoot函数前调用，触发一次新的调度，确保任何附加的任务被调度\nensureRootIsScheduled(root, now());\n\n// ...处理未捕获错误及老版本遗留的边界问题\n\n\n// 执行同步任务，这样同步任务不需要等到下次事件循环再执行\n// 比如在 componentDidMount 中执行 setState 创建的更新会在这里被同步执行\n// 或useLayoutEffect\nflushSyncCallbackQueue();\n\nreturn null;\n```\n\n主要包括三点内容：\n\n1. useEffect相关的处理。\n\n2. 性能追踪相关。\n源码里有很多和interaction相关的变量。他们都和追踪React渲染时间、性能相关，在Profiler API 和DevTools 中使用。\n \n3. 在commit阶段会触发一些生命周期钩子（如 componentDidXXX）和hook（如useLayoutEffect、useEffect）。\n\n\n### before mutation 阶段\n\nRenderer工作的阶段被称为commit阶段。commit阶段可以分为三个子阶段：\n\nbefore mutation阶段（执行DOM操作前）\n\nmutation阶段（执行DOM操作）\n\nlayout阶段（执行DOM操作后）\n\n本节我们看看before mutation阶段（执行DOM操作前）都做了什么。\n\n#### 概览\nbefore mutation阶段的代码很短，整个过程就是遍历effectList并调用commitBeforeMutationEffects函数处理。\n\n```ts\n// 保存之前的优先级，以同步优先级执行，执行完毕后恢复之前优先级\nconst previousLanePriority = getCurrentUpdateLanePriority();\nsetCurrentUpdateLanePriority(SyncLanePriority);\n\n// 将当前上下文标记为CommitContext，作为commit阶段的标志\nconst prevExecutionContext = executionContext;\nexecutionContext |= CommitContext;\n\n// 处理focus状态\nfocusedInstanceHandle = prepareForCommit(root.containerInfo);\nshouldFireAfterActiveInstanceBlur = false;\n\n// beforeMutation阶段的主函数\ncommitBeforeMutationEffects(finishedWork);\n\nfocusedInstanceHandle = null;\n```\n\n我们重点关注beforeMutation阶段的主函数commitBeforeMutationEffects做了什么。\n\n#### commitBeforeMutationEffects\n\n```ts\nfunction commitBeforeMutationEffects() {\n while (nextEffect !== null) {\n const current = nextEffect.alternate;\n\n if (!shouldFireAfterActiveInstanceBlur && focusedInstanceHandle !== null) {\n // ...focus blur相关\n }\n\n const effectTag = nextEffect.effectTag;\n\n // 调用getSnapshotBeforeUpdate\n if ((effectTag & Snapshot) !== NoEffect) {\n commitBeforeMutationEffectOnFiber(current, nextEffect);\n }\n\n // 调度useEffect\n if ((effectTag & Passive) !== NoEffect) {\n if (!rootDoesHavePassiveEffects) {\n rootDoesHavePassiveEffects = true;\n scheduleCallback(NormalSchedulerPriority, () => {\n flushPassiveEffects();\n return null;\n });\n }\n }\n nextEffect = nextEffect.nextEffect;\n }\n}\n```\n\n整体可以分为三部分：\n\n- 处理DOM节点渲染/删除后的 autoFocus、blur 逻辑。\n\n- 调用getSnapshotBeforeUpdate生命周期钩子。\n\n- 调度useEffect。\n\n#### 调用 getSnapshotBeforeUpdate\n\ncommitBeforeMutationEffectOnFiber是commitBeforeMutationLifeCycles的别名。\n\n在该方法内会调用getSnapshotBeforeUpdate。\n\n从Reactv16开始，componentWillXXX钩子前增加了UNSAFE_前缀。\n\n究其原因，是因为Stack Reconciler重构为Fiber Reconciler后，render阶段的任务可能中断/重新开始，对应的组件在render阶段的生命周期钩子（即componentWillXXX）可能触发多次。\n\n这种行为和Reactv15不一致，所以标记为UNSAFE_。\n\n更详细的解释参照这里(opens new window)\n\n为此，React提供了替代的生命周期钩子getSnapshotBeforeUpdate。\n\n我们可以看见，getSnapshotBeforeUpdate是在commit阶段内的before mutation阶段调用的，由于commit阶段是同步的，所以不会遇到多次调用的问题。\n\n#### 调度useEffect\n在这几行代码内，scheduleCallback方法由Scheduler模块提供，用于以某个优先级异步调度一个回调函数。\n\n```ts\n// 调度useEffect\nif ((effectTag & Passive) !== NoEffect) {\n if (!rootDoesHavePassiveEffects) {\n rootDoesHavePassiveEffects = true;\n scheduleCallback(NormalSchedulerPriority, () => {\n // 触发useEffect\n flushPassiveEffects();\n return null;\n });\n }\n}\n```\n\n在此处，被异步调度的回调函数就是触发useEffect的方法flushPassiveEffects。\n\n我们接下来讨论useEffect如何被异步调度，以及为什么要异步（而不是同步）调度。\n\n#### 如何异步调度\n\n在flushPassiveEffects方法内部会从全局变量rootWithPendingPassiveEffects获取effectList。\n\n关于flushPassiveEffects的具体讲解参照useEffect与useLayoutEffect一节\n\n在completeWork一节我们讲到，effectList中保存了需要执行副作用的Fiber节点。其中副作用包括\n\n- 插入DOM节点（Placement）\n- 更新DOM节点（Update）\n- 删除DOM节点（Deletion）\n\n除此外，当一个FunctionComponent含有useEffect或useLayoutEffect，他对应的Fiber节点也会被赋值effectTag。\n\n在flushPassiveEffects方法内部会遍历rootWithPendingPassiveEffects（即effectList）执行effect回调函数。\n\n如果在此时直接执行，rootWithPendingPassiveEffects === null。\n\n那么rootWithPendingPassiveEffects会在何时赋值呢？\n\n在上一节layout之后的代码片段中会根据rootDoesHavePassiveEffects === true?决定是否赋值rootWithPendingPassiveEffects。\n\n```ts\nconst rootDidHavePassiveEffects = rootDoesHavePassiveEffects;\nif (rootDoesHavePassiveEffects) {\n rootDoesHavePassiveEffects = false;\n rootWithPendingPassiveEffects = root;\n pendingPassiveEffectsLanes = lanes;\n pendingPassiveEffectsRenderPriority = renderPriorityLevel;\n}\n```\n\n**所以整个useEffect异步调用分为三步**：\n\n- `before mutation`阶段在`scheduleCallback`中调度`flushPassiveEffects`\n- `layout阶段`之后将`effectList`赋值给`rootWithPendingPassiveEffects`\n- `scheduleCallback`触发`flushPassiveEffects`，`flushPassiveEffects`内部遍历`rootWithPendingPassiveEffects`\n\n#### 为什么需要异步调用\n\n与 componentDidMount、componentDidUpdate 不同的是，在浏览器完成布局与绘制之后，传给 useEffect 的函数会延迟调用。这使得它适用于许多常见的副作用场景，比如设置订阅和事件处理等情况，因此不应在函数中执行阻塞浏览器更新屏幕的操作。\n\n可见，useEffect异步执行的原因主要是防止同步执行时阻塞浏览器渲染。\n\n### mutation阶段\n\n终于到了执行DOM操作的mutation阶段。\n\n#### 概览\n类似before mutation阶段，mutation阶段也是遍历effectList，执行函数。这里执行的是commitMutationEffects。\n\n```ts\nnextEffect = firstEffect;\ndo {\n try {\n commitMutationEffects(root, renderPriorityLevel);\n } catch (error) {\n invariant(nextEffect !== null, 'Should be working on an effect.');\n captureCommitPhaseError(nextEffect, error);\n nextEffect = nextEffect.nextEffect;\n }\n} while (nextEffect !== null);\n```\n\n#### commitMutationEffects\n代码如下：\n```ts\nfunction commitMutationEffects(root: FiberRoot, renderPriorityLevel) {\n // 遍历effectList\n while (nextEffect !== null) {\n\n const effectTag = nextEffect.effectTag;\n\n // 根据 ContentReset effectTag重置文字节点\n if (effectTag & ContentReset) {\n commitResetTextContent(nextEffect);\n }\n\n // 更新ref\n if (effectTag & Ref) {\n const current = nextEffect.alternate;\n if (current !== null) {\n commitDetachRef(current);\n }\n }\n\n // 根据 effectTag 分别处理\n const primaryEffectTag =\n effectTag & (Placement | Update | Deletion | Hydrating);\n switch (primaryEffectTag) {\n // 插入DOM\n case Placement: {\n commitPlacement(nextEffect);\n nextEffect.effectTag &= ~Placement;\n break;\n }\n // 插入DOM 并更新DOM\n case PlacementAndUpdate: {\n // 插入\n commitPlacement(nextEffect);\n\n nextEffect.effectTag &= ~Placement;\n\n // 更新\n const current = nextEffect.alternate;\n commitWork(current, nextEffect);\n break;\n }\n // SSR\n case Hydrating: {\n nextEffect.effectTag &= ~Hydrating;\n break;\n }\n // SSR\n case HydratingAndUpdate: {\n nextEffect.effectTag &= ~Hydrating;\n\n const current = nextEffect.alternate;\n commitWork(current, nextEffect);\n break;\n }\n // 更新DOM\n case Update: {\n const current = nextEffect.alternate;\n commitWork(current, nextEffect);\n break;\n }\n // 删除DOM\n case Deletion: {\n commitDeletion(root, nextEffect, renderPriorityLevel);\n break;\n }\n }\n\n nextEffect = nextEffect.nextEffect;\n }\n}\n```\n\n\ncommitMutationEffects会遍历effectList，对每个Fiber节点执行如下三个操作：\n\n- 根据ContentReset effectTag重置文字节点\n- 更新ref\n- 根据effectTag分别处理，其中effectTag包括(Placement | Update | Deletion | Hydrating)\n\n我们关注步骤三中的`Placement | Update | Deletion`。Hydrating作为服务端渲染相关，我们先不关注。\n\n#### Placement effect\n当Fiber节点含有Placement effectTag，意味着该Fiber节点对应的DOM节点需要插入到页面中。\n\n调用的方法为commitPlacement。\n\n该方法所做的工作分为三步：\n\n1. 获取父级DOM节点。其中finishedWork为传入的Fiber节点。\n```ts\nconst parentFiber = getHostParentFiber(finishedWork);\n// 父级DOM节点\nconst parentStateNode = parentFiber.stateNode;\n```\n\n2. 获取Fiber节点的DOM兄弟节点\n```ts\n获取Fiber节点的DOM兄弟节点\n```\n\n3. 根据DOM兄弟节点是否存在决定调用parentNode.insertBefore或parentNode.appendChild执行DOM插入操作。\n```ts\n// parentStateNode是否是rootFiber\nif (isContainer) {\n insertOrAppendPlacementNodeIntoContainer(finishedWork, before, parent);\n} else {\n insertOrAppendPlacementNode(finishedWork, before, parent);\n}\n```\n\n值得注意的是，getHostSibling（获取兄弟DOM节点）的执行很耗时，当在同一个父Fiber节点下依次执行多个插入操作，getHostSibling算法的复杂度为指数级。\n\n这是由于Fiber节点不只包括HostComponent，所以Fiber树和渲染的DOM树节点并不是一一对应的。要从Fiber节点找到DOM节点很可能跨层级遍历。\n\n```tsx\nfunction Item() {\n return

;\n}\n\nfunction App() {\n return (\n

\n \n

\n )\n}\n\nReactDOM.render(, document.getElementById('root'));\n```\n\n对应的Fiber树和DOM树结构为：\n```\n// Fiber树\n child child child child\nrootFiber -----> App -----> div -----> Item -----> li\n\n// DOM树\n#root ---> div ---> li\n```\n\n当在div的子节点Item前插入一个新节点p，即App变为：\n\n```tsx\nfunction App() {\n return (\n

\n \n

\n )\n}\n```\n\n对应的Fiber树和DOM树结构为：\n\n```\n// Fiber树\n child child child\nrootFiber -----> App -----> div -----> p \n | sibling child\n | -------> Item -----> li \n// DOM树\n#root ---> div ---> p\n |\n ---> li\n```\n\n此时DOM节点 p的兄弟节点为li，而Fiber节点 p对应的兄弟DOM节点为： `fiberP.sibling.child`\n\n即fiber p的兄弟fiber Item的子fiber li\n\n#### Update effect\n\n当Fiber节点含有Update effectTag，意味着该Fiber节点需要更新。调用的方法为commitWork，他会根据Fiber.tag分别处理。\n\n这里我们主要关注FunctionComponent和HostComponent。\n\n#### FunctionComponent mutation\n\n当fiber.tag为FunctionComponent，会调用commitHookEffectListUnmount。该方法会遍历effectList，执行所有useLayoutEffect hook的销毁函数。\n\n所谓“销毁函数”，见如下例子\n```ts\nuseLayoutEffect(() => {\n // ...一些副作用逻辑\n\n return () => {\n // ...这就是销毁函数\n }\n})\n```\n\n你不需要很了解useLayoutEffect，我们会在下一节详细介绍。你只需要知道在mutation阶段会执行useLayoutEffect的销毁函数。\n\n#### HostComponent mutation\n\n当fiber.tag为HostComponent，会调用commitUpdate。\n\n最终会在updateDOMProperties (opens new window)中将render阶段 completeWork (opens new window)中为Fiber节点赋值的updateQueue对应的内容渲染在页面上。\n\n```ts\nfor (let i = 0; i < updatePayload.length; i += 2) {\n const propKey = updatePayload[i];\n const propValue = updatePayload[i + 1];\n\n // 处理 style\n if (propKey === STYLE) {\n setValueForStyles(domElement, propValue);\n // 处理 DANGEROUSLY_SET_INNER_HTML\n } else if (propKey === DANGEROUSLY_SET_INNER_HTML) {\n setInnerHTML(domElement, propValue);\n // 处理 children\n } else if (propKey === CHILDREN) {\n setTextContent(domElement, propValue);\n } else {\n // 处理剩余 props\n setValueForProperty(domElement, propKey, propValue, isCustomComponentTag);\n }\n}\n```\n\n#### Deletion effect\n\n当Fiber节点含有Deletion effectTag，意味着该Fiber节点对应的DOM节点需要从页面中删除。调用的方法为commitDeletion。\n\n该方法会执行如下操作：\n\n- 递归调用Fiber节点及其子孙Fiber节点中fiber.tag为ClassComponent的componentWillUnmount (opens new window)生命周期钩子，从页面移除Fiber节点对应DOM节点\n- 解绑ref\n- 调度useEffect的销毁函数\n\n### layout阶段\n\n该阶段之所以称为layout，因为该阶段的代码都是在DOM渲染完成（mutation阶段完成）后执行的。\n\n该阶段触发的生命周期钩子和hook可以直接访问到已经改变后的DOM，即该阶段是可以参与DOM layout的阶段。\n\n与前两个阶段类似，layout阶段也是遍历effectList，执行函数。\n\n具体执行的函数是commitLayoutEffects。\n\n\n#### commitLayoutEffects\n\ncommitLayoutEffects一共做了两件事：\n\n1. commitLayoutEffectOnFiber（调用生命周期钩子和hook相关操作）\n\n2. commitAttachRef（赋值 ref）\n\n#### commitLayoutEffectOnFiber\n\ncommitLayoutEffectOnFiber方法会根据fiber.tag对不同类型的节点分别处理。\n\n- 对于ClassComponent，他会通过current === null?区分是mount还是update，调用componentDidMount (opens new window)或componentDidUpdate\n\n触发状态更新的this.setState如果赋值了第二个参数回调函数，也会在此时调用。\n\n- 对于FunctionComponent及相关类型，他会调用useLayoutEffect hook的回调函数，调度useEffect的销毁与回调函数\n\n相关类型指特殊处理后的FunctionComponent，比如ForwardRef、React.memo包裹的FunctionComponent\n\nmutation阶段会执行useLayoutEffect hook的销毁函数。\n\n结合这里我们可以发现，useLayoutEffect hook从上一次更新的销毁函数调用到本次更新的回调函数调用是同步执行的。\n\n而useEffect则需要先调度，在Layout阶段完成后再异步执行。\n\n这就是useLayoutEffect与useEffect的区别。\n\n- 对于HostRoot，即rootFiber，如果赋值了第三个参数回调函数，也会在此时调用。\n\n#### commitAttachRef\n\ncommitLayoutEffects会做的第二件事是commitAttachRef。\n\n代码逻辑很简单：获取DOM实例，更新ref。\n\n#### current Fiber树切换\n\n至此，整个layout阶段就结束了。\n\n\n\n\n",{"_54":370,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/325/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/325/timeline",{"_54":373,"_56":57,"_58":374,"_60":375,"_62":376,"_64":377,"_66":378,"_68":379,"_70":380,"_72":381,"_74":382,"_107":383,"_127":128,"_129":26,"_130":-5,"_131":385,"_133":386,"_155":148,"_149":388,"_151":389,"_154":-5,"_159":160,"_161":390,"_166":-5,"_167":391,"_169":392,"_181":394,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/324","https://api.github.com/repos/pro-collection/interview-question/issues/324/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/324/comments","https://api.github.com/repos/pro-collection/interview-question/issues/324/events","https://github.com/pro-collection/interview-question/issues/324",1689968075,"I_kwDOJGDC6c5kut3L",324,"[React] render 阶段的执行过程【热度: 1,793】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[384],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":387,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-30T15:45:51Z","2023-04-30T15:45:52Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、react fiber、react 协调器\n\nrender阶段开始于`performSyncWorkOnRoot`或`performConcurrentWorkOnRoot`方法的调用。这取决于本次更新是同步更新还是异步更新。\n\n```js\n// performSyncWorkOnRoot会调用该方法\nfunction workLoopSync() {\n while (workInProgress !== null) {\n performUnitOfWork(workInProgress);\n }\n}\n\n// performConcurrentWorkOnRoot会调用该方法\nfunction workLoopConcurrent() {\n while (workInProgress !== null && !shouldYield()) {\n performUnitOfWork(workInProgress);\n }\n}\n```\n\n可以看到，他们唯一的区别是是否调用shouldYield。如果当前浏览器帧没有剩余时间，shouldYield会中止循环，直到浏览器有空闲时间后再继续遍历。\n\nworkInProgress代表当前已创建的workInProgress fiber。\n\nperformUnitOfWork方法会创建下一个Fiber节点并赋值给workInProgress，并将workInProgress与已创建的Fiber节点连接起来构成Fiber树。\n\n通过遍历的方式实现可中断的递归，所以performUnitOfWork的工作可以分为两部分：“递”和“归”。\n\n### 创建节点\n\n首先从rootFiber开始向下深度优先遍历。为遍历到的每个Fiber节点调用`beginWork`方法 (opens new window)。\n\n该方法会根据传入的Fiber节点创建子Fiber节点，并将这两个Fiber节点连接起来。\n\n当遍历到叶子节点（即没有子组件的组件）时就会进入“归”阶段。\n\n在“归”阶段会调用`completeWork` (opens new window)处理Fiber节点。\n\n当某个Fiber节点执行完completeWork，如果其存在兄弟Fiber节点（即fiber.sibling !== null），会进入其兄弟Fiber的“递”阶段。\n\n如果不存在兄弟Fiber，会进入父级Fiber的“归”阶段。\n\n“递”和“归”阶段会交错执行直到“归”到rootFiber。至此，render阶段的工作就结束了。\n\n**举例**\n\n代码如下：\n\n```js\nfunction App() {\n return (\n

\n i am\n KaSong\n

\n )\n}\n\nReactDOM.render(, document.getElementById(\"root\"));\n```\n\n对应的 fiber 树结构如下 \n![image](https://user-images.githubusercontent.com/22188674/235359287-0f448fa3-657d-40b4-8cff-92327ef5414c.png)\n\nrender 阶段会依次执行\n\n```\n1. rootFiber beginWork\n2. App Fiber beginWork\n3. div Fiber beginWork\n4. \"i am\" Fiber beginWork\n5. \"i am\" Fiber completeWork\n6. span Fiber beginWork\n7. span Fiber completeWork\n8. div Fiber completeWork\n9. App Fiber completeWork\n10. rootFiber completeWork\n```\n\n### beginWork\n\n源码链接： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactFiberBeginWork.new.js#L3075\n\n工作流程图：\n![image](https://user-images.githubusercontent.com/22188674/235361451-6440499a-09dc-4478-81e4-e0585e815f0b.png)\n\nbeginWork的工作是传入当前Fiber节点，创建子Fiber节点，我们从传参来看看具体是如何做的。\n\n**传参**\n\n```ts\nfunction beginWork(\n current: Fiber | null, // 当前组件对应的Fiber节点在上一次更新时的Fiber节点，即workInProgress.alternate\n workInProgress: Fiber, // 当前组件对应的Fiber节点\n renderLanes: Lanes, // 优先级相关，在讲解Scheduler时再讲解\n): Fiber | null {\n // ...省略函数体\n}\n```\n\nbeginWork的工作可以分为两部分:\n\n- `update`时：如果current存在，在满足一定条件时可以复用current节点，这样就能克隆current.child作为workInProgress.child，而不需要新建workInProgress.child。\n- `mount`时：除fiberRootNode以外，current === null。会根据fiber.tag不同，创建不同类型的子Fiber节点\n\n```ts\nfunction beginWork(\n current: Fiber | null,\n workInProgress: Fiber,\n renderLanes: Lanes\n): Fiber | null {\n\n // update时：如果current存在可能存在优化路径，可以复用current（即上一次更新的Fiber节点）\n if (current !== null) {\n // ...省略\n\n // 复用current\n return bailoutOnAlreadyFinishedWork(\n current,\n workInProgress,\n renderLanes,\n );\n } else {\n didReceiveUpdate = false;\n }\n\n // mount时：根据tag不同，创建不同的子Fiber节点\n switch (workInProgress.tag) {\n case IndeterminateComponent:\n // ...省略\n case LazyComponent:\n // ...省略\n case FunctionComponent:\n // ...省略\n case ClassComponent:\n // ...省略\n case HostRoot:\n // ...省略\n case HostComponent:\n // ...省略\n case HostText:\n // ...省略\n // ...省略其他类型\n }\n}\n```\n\n#### update时\n\n满足如下情况时didReceiveUpdate === false（即可以直接复用前一次更新的子Fiber，不需要新建子Fiber）\n\n```ts\nif (current !== null) {\n const oldProps = current.memoizedProps;\n const newProps = workInProgress.pendingProps;\n\n if (\n oldProps !== newProps ||\n hasLegacyContextChanged() ||\n (__DEV__ ? workInProgress.type !== current.type : false)\n ) {\n didReceiveUpdate = true;\n } else if (!includesSomeLane(renderLanes, updateLanes)) {\n didReceiveUpdate = false;\n switch (workInProgress.tag) {\n // 省略处理\n }\n return bailoutOnAlreadyFinishedWork(\n current,\n workInProgress,\n renderLanes,\n );\n } else {\n didReceiveUpdate = false;\n }\n} else {\n didReceiveUpdate = false;\n}\n```\n\n1. `oldProps === newProps && workInProgress.type === current.type`，即props与fiber.type不变\n2. `!includesSomeLane(renderLanes, updateLanes)`，即当前Fiber节点优先级不够，会在讲解Scheduler时介绍\n\n#### mount\n\n当不满足优化路径时，我们就进入第二部分，新建子Fiber。\n\n```ts\n// mount时：根据tag不同，创建不同的Fiber节点\nswitch (workInProgress.tag) {\n case IndeterminateComponent:\n // ...省略\n case LazyComponent:\n // ...省略\n case FunctionComponent:\n // ...省略\n case ClassComponent:\n // ...省略\n case HostRoot:\n // ...省略\n case HostComponent:\n // ...省略\n case HostText:\n // ...省略\n // ...省略其他类型\n}\n```\n\n我们可以看到，根据fiber.tag不同，进入不同类型Fiber的创建逻辑。\n\n对于我们常见的组件类型，如`（FunctionComponent/ClassComponent/HostComponent）`，最终会进入`reconcileChildren` (opens new window)方法。\n\n#### reconcileChildren\n\n- 对于mount的组件，他会创建新的子Fiber节点\n- 对于update的组件，他会将当前组件与该组件在上次更新时对应的Fiber节点比较（也就是俗称的Diff算法），将比较的结果生成新Fiber节点\n\n```ts\nexport function reconcileChildren(\n current: Fiber | null,\n workInProgress: Fiber,\n nextChildren: any,\n renderLanes: Lanes\n) {\n if (current === null) {\n // 对于mount的组件\n workInProgress.child = mountChildFibers(\n workInProgress,\n null,\n nextChildren,\n renderLanes,\n );\n } else {\n // 对于update的组件\n workInProgress.child = reconcileChildFibers(\n workInProgress,\n current.child,\n nextChildren,\n renderLanes,\n );\n }\n}\n```\n\n从代码可以看出，和beginWork一样，他也是通过current === null ?区分mount与update。\n\n不论走哪个逻辑，最终他会生成新的子Fiber节点并赋值给workInProgress.child，作为本次beginWork返回值 (opens new window)\n，并作为下次performUnitOfWork执行时workInProgress的传参\n\n#### effectTag\n\n我们知道，render阶段的工作是在内存中进行，当工作结束后会通知Renderer需要执行的DOM操作。要执行DOM操作的具体类型就保存在fiber.effectTag中。\n\n```ts\n// DOM需要插入到页面中\nexport const Placement = /* */ 0b00000000000010;\n// DOM需要更新\nexport const Update = /* */ 0b00000000000100;\n// DOM需要插入到页面中并更新\nexport const PlacementAndUpdate = /* */ 0b00000000000110;\n// DOM需要删除\nexport const Deletion = /* */ 0b00000000001000;\n```\n\n通过二进制表示effectTag，可以方便的使用位操作为fiber.effectTag赋值多个effect。\n\n那么，如果要通知Renderer将Fiber节点对应的DOM节点插入页面中，需要满足两个条件：\n\n1. `fiber.stateNode`存在，即Fiber节点中保存了对应的DOM节点\n\n2. `(fiber.effectTag & Placement) !== 0`，即 `Fiber节点存在Placement effectTag`\n\n我们知道，mount时，fiber.stateNode === null，且在reconcileChildren中调用的mountChildFibers不会为Fiber节点赋值effectTag。那么首屏渲染如何完成呢？\n\n针对第一个问题，`fiber.stateNode`会在`completeWork`中创建，我们会在下一节介绍。\n\n第二个问题的答案十分巧妙：假设`mountChildFibers`也会赋值effectTag，那么可以预见mount时整棵Fiber树所有节点都会有Placement\neffectTag。那么commit阶段在执行DOM操作时每个节点都会执行一次插入操作，这样大量的DOM操作是极低效的。\n\n为了解决这个问题，**在mount时只有rootFiber会赋值Placement effectTag**，在commit阶段只会执行一次插入操作。\n\n### completeWork\n\n流程图：\n![image](https://user-images.githubusercontent.com/22188674/235362048-ce278ddf-b944-4ed6-a6af-e3b1502fb6c7.png)\n\n类似beginWork，completeWork也是针对不同fiber.tag调用不同的处理逻辑。\n\n```ts\nfunction completeWork(\n current: Fiber | null,\n workInProgress: Fiber,\n renderLanes: Lanes,\n): Fiber | null {\n const newProps = workInProgress.pendingProps;\n\n switch (workInProgress.tag) {\n case IndeterminateComponent:\n case LazyComponent:\n case SimpleMemoComponent:\n case FunctionComponent:\n case ForwardRef:\n case Fragment:\n case Mode:\n case Profiler:\n case ContextConsumer:\n case MemoComponent:\n return null;\n case ClassComponent: {\n // ...省略\n return null;\n }\n case HostRoot: {\n // ...省略\n updateHostContainer(workInProgress);\n return null;\n }\n case HostComponent: {\n // ...省略\n return null;\n }\n // ...省略\n }\n // ...省略\n}\n```\n\n我们重点关注页面渲染所必须的 `HostComponent`（即原生DOM组件对应的Fiber节点），其他类型Fiber的处理留在具体功能实现时讲解。\n\n#### 处理 HostComponent\n\n和`beginWork`一样，我们根据 `current === null` ?判断是mount还是`update`。\n\n同时针对 `HostComponent`，判断 `update` 时我们还需要考虑 `workInProgress.stateNode != null` ?（即该Fiber节点是否存在对应的DOM节点）\n\n```ts\ncase\nHostComponent: {\n popHostContext(workInProgress);\n const rootContainerInstance = getRootHostContainer();\n const type = workInProgress.type;\n\n if (current !== null && workInProgress.stateNode != null) {\n // update的情况\n // ...省略\n } else {\n // mount的情况\n // ...省略\n }\n return null;\n}\n```\n\n#### update 时\n\n当update时，Fiber节点已经存在对应DOM节点，所以不需要生成DOM节点。需要做的主要是处理props，比如：\n\n- `onClick、onChange` 等回调函数的注册\n- 处理 `style prop`\n- 处理 `DANGEROUSLY_SET_INNER_HTML prop`\n- 处理 `children prop`\n\n我们去掉一些当前不需要关注的功能（比如ref）。可以看到最主要的逻辑是调用updateHostComponent方法。\n\n```ts\nif (current !== null && workInProgress.stateNode != null) {\n // update的情况\n updateHostComponent(\n current,\n workInProgress,\n type,\n newProps,\n rootContainerInstance,\n );\n}\n```\n\n在updateHostComponent内部，被处理完的props会被赋值给workInProgress.updateQueue，并最终会在commit阶段被渲染在页面上。\n\n`workInProgress.updateQueue = (updatePayload: any);`\n\n其中updatePayload为数组形式，他的偶数索引的值为变化的prop key，奇数索引的值为变化的prop value。\n\n#### mount 时\n\n同样，我们省略了不相关的逻辑。可以看到，mount时的主要逻辑包括三个：\n\n- 为Fiber节点生成对应的DOM节点\n- 将子孙DOM节点插入刚生成的DOM节点中\n- 与update逻辑中的updateHostComponent类似的处理props的过程\n\n```ts\n// mount的情况\n\n// ...省略服务端渲染相关逻辑\n\nconst currentHostContext = getHostContext();\n// 为fiber创建对应DOM节点\nconst instance = createInstance(\n type,\n newProps,\n rootContainerInstance,\n currentHostContext,\n workInProgress,\n );\n// 将子孙DOM节点插入刚生成的DOM节点中\nappendAllChildren(instance, workInProgress, false, false);\n// DOM节点赋值给fiber.stateNode\nworkInProgress.stateNode = instance;\n\n// 与update逻辑中的updateHostComponent类似的处理props的过程\nif (\n finalizeInitialChildren(\n instance,\n type,\n newProps,\n rootContainerInstance,\n currentHostContext,\n )\n) {\n markUpdate(workInProgress);\n}\n```\n\nmount时只会在rootFiber存在Placement effectTag。那么commit阶段是如何通过一次插入DOM操作（对应一个Placement effectTag）将整棵DOM树插入页面的呢？\n\n原因就在于 `completeWork中的appendAllChildren` 方法。\n\n由于`completeWork`属于“归”阶段调用的函数，每次调用`appendAllChildren`时都会将已生成的子孙DOM节点插入当前生成的DOM节点下。那么当“归”到rootFiber时，我们已经有一个构建好的离屏DOM树。\n\n#### effectList\n\n至此render阶段的绝大部分工作就完成了。\n\n还有一个问题：作为DOM操作的依据，commit阶段需要找到所有有effectTag的Fiber节点并依次执行effectTag对应操作。难道需要在commit阶段再遍历一次Fiber树寻找effectTag !== null的Fiber节点么？\n\n这显然是很低效的。\n\n为了解决这个问题，在completeWork的上层函数completeUnitOfWork中，每个执行完completeWork且存在effectTag的Fiber节点会被保存在一条被称为effectList的单向链表中。\n\neffectList中第一个Fiber节点保存在fiber.firstEffect，最后一个元素保存在fiber.lastEffect。\n\n类似appendAllChildren，在“归”阶段，所有有effectTag的Fiber节点都会被追加在effectList中，最终形成一条以rootFiber.firstEffect为起点的单向链表。\n\n```\n nextEffect nextEffect\nrootFiber.firstEffect -----------> fiber -----------> fiber\n```\n\n这样，在commit阶段只需要遍历`effectList`就能执行所有`effect`了。\n\n### 流程结尾\n至此，render阶段全部工作完成。在performSyncWorkOnRoot函数中fiberRootNode被传递给commitRoot方法，开启commit阶段工作流程。\n\n`commitRoot(root);`\n\n\n",{"_54":393,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/324/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/324/timeline",{"_54":396,"_56":57,"_58":397,"_60":398,"_62":399,"_64":400,"_66":401,"_68":402,"_70":403,"_72":404,"_74":405,"_107":406,"_127":128,"_129":26,"_130":-5,"_131":408,"_133":409,"_155":148,"_149":411,"_151":412,"_154":-5,"_159":160,"_161":413,"_166":-5,"_167":414,"_169":415,"_181":417,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/323","https://api.github.com/repos/pro-collection/interview-question/issues/323/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/323/comments","https://api.github.com/repos/pro-collection/interview-question/issues/323/events","https://github.com/pro-collection/interview-question/issues/323",1688900261,"I_kwDOJGDC6c5kqpKl",323,"[React] Fiber的含义与数据结构【热度: 1,778】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[407],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":410,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-28T17:31:23Z","2023-04-28T17:31:24Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、react fiber、react 协调器\n\n### Fiber的含义\n\n1. 作为架构来说，之前React15的Reconciler采用递归的方式执行，数据保存在递归调用栈中，所以被称为stack Reconciler。React16的Reconciler基于Fiber节点实现，被称为Fiber Reconciler。\n\n2. 作为静态的数据结构来说，每个Fiber节点对应一个React element，保存了该组件的类型（函数组件/类组件/原生组件...）、对应的DOM节点等信息。\n\n3. 作为动态的工作单元来说，每个Fiber节点保存了本次更新中该组件改变的状态、要执行的工作（需要被删除/被插入页面中/被更新...）。\n\n### Fiber的结构\n\n总的属性如下：\n```js\nfunction FiberNode(\n tag: WorkTag,\n pendingProps: mixed,\n key: null | string,\n mode: TypeOfMode,\n) {\n // 作为静态数据结构的属性\n this.tag = tag;\n this.key = key;\n this.elementType = null;\n this.type = null;\n this.stateNode = null;\n\n // 用于连接其他Fiber节点形成Fiber树\n this.return = null;\n this.child = null;\n this.sibling = null;\n this.index = 0;\n\n this.ref = null;\n\n // 作为动态的工作单元的属性\n this.pendingProps = pendingProps;\n this.memoizedProps = null;\n this.updateQueue = null;\n this.memoizedState = null;\n this.dependencies = null;\n\n this.mode = mode;\n\n this.effectTag = NoEffect;\n this.nextEffect = null;\n\n this.firstEffect = null;\n this.lastEffect = null;\n\n // 调度优先级相关\n this.lanes = NoLanes;\n this.childLanes = NoLanes;\n\n // 指向该fiber在另一次更新时对应的fiber\n this.alternate = null;\n}\n```\n\n可以按三层含义将他们分类来看\n\n#### 作为架构\n\n每个Fiber节点有个对应的React element，多个Fiber节点是如何连接形成树呢？靠如下三个属性：\n\n```js\n// 指向父级Fiber节点\nthis.return = null;\n// 指向子Fiber节点\nthis.child = null;\n// 指向右边第一个兄弟Fiber节点\nthis.sibling = null;\n```\n\n举个例子，如下的组件结构：\n\n```js\nfunction App() {\n return (\n

\n i am\n KaSong\n

\n )\n}\n```\n\n对应的Fiber树结构： \n![image](https://user-images.githubusercontent.com/22188674/235214339-4efeccaf-95fd-420f-8ac2-7a9b89c301c0.png)\n\n#### 作为静态的数据结构\n\n作为一种静态的数据结构，保存了组件相关的信息：\n\n```js\n// Fiber对应组件的类型 Function/Class/Host...\nthis.tag = tag;\n// key属性\nthis.key = key;\n// 大部分情况同type，某些情况不同，比如FunctionComponent使用React.memo包裹\nthis.elementType = null;\n// 对于 FunctionComponent，指函数本身，对于ClassComponent，指class，对于HostComponent，指DOM节点tagName\nthis.type = null;\n// Fiber对应的真实DOM节点\nthis.stateNode = null;\n```\n\n#### 作为动态的工作单元\n作为动态的工作单元，Fiber中如下参数保存了本次更新相关的信息，我们会在后续的更新流程中使用到具体属性时再详细介绍\n\n```js\n// 保存本次更新造成的状态改变相关信息\nthis.pendingProps = pendingProps;\nthis.memoizedProps = null;\nthis.updateQueue = null;\nthis.memoizedState = null;\nthis.dependencies = null;\n\nthis.mode = mode;\n\n// 保存本次更新会造成的DOM操作\nthis.effectTag = NoEffect;\nthis.nextEffect = null;\n\nthis.firstEffect = null;\nthis.lastEffect = null;\n\n// 调度优先级相关\nthis.lanes = NoLanes;\nthis.childLanes = NoLanes;\n```\n\n\n\n\n\n",{"_54":416,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/323/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/323/timeline",{"_54":419,"_56":57,"_58":420,"_60":421,"_62":422,"_64":423,"_66":424,"_68":425,"_70":426,"_72":427,"_74":428,"_107":429,"_127":128,"_129":26,"_130":-5,"_131":431,"_133":432,"_155":148,"_149":434,"_151":435,"_154":-5,"_159":160,"_161":436,"_166":-5,"_167":437,"_169":438,"_181":440,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/322","https://api.github.com/repos/pro-collection/interview-question/issues/322/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/322/comments","https://api.github.com/repos/pro-collection/interview-question/issues/322/events","https://github.com/pro-collection/interview-question/issues/322",1688824333,"I_kwDOJGDC6c5kqWoN",322,"[React] fiber 架构的工作原理？【热度: 1,774】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[430],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":433,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-28T16:23:02Z","2023-04-28T16:37:43Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、react fiber、react 协调器\r\n\r\n### 双缓存Fiber树\r\n\r\n如果当前帧画面计算量比较大，导致清除上一帧画面到绘制当前帧画面之间有较长间隙，就会出现白屏。\r\n\r\n为了解决这个问题，就有了图像处理中的**双缓存技术**。 \r\n\r\n双缓存是一种技术，用于在图像处理中减少闪烁和图像模糊等视觉问题。在使用双缓存时，图像处理器会将图像绘制到一个“后台缓存”中，而不是直接绘制到屏幕上。一旦绘制完成，新的图像将与当前显示的图像交换，使得新图像无缝地显示在屏幕上，避免了闪烁和模糊的问题。因此，双缓存有助于提高图像处理的质量和可靠性，特别是在高速显示和实时处理应用中。\r\n\r\nReact使用“双缓存”来完成Fiber树的构建与替换——对应着DOM树的创建与更新。\r\n\r\n\r\n在React中最多会同时存在两棵Fiber树。当前屏幕上显示内容对应的Fiber树称为current Fiber树，正在内存中构建的Fiber树称为workInProgress Fiber树。\r\n\r\nReact Fiber 的双缓存机制是一种优化技术，用于在 UI 更新过程中避免视觉问题，如闪烁、撕裂和卡顿等。React Double Buffer 在 React Fiber 内部实现了两个缓存区域：当前显示的缓存（Current Buffer）和等待显示的缓存（Work Buffer）。\r\n\r\n```js\r\ncurrentFiber.alternate === workInProgressFiber;\r\nworkInProgressFiber.alternate === currentFiber;\r\n```\r\n\r\n\r\n当应用程序状态发生更改，并需要更新 UI 时，React Fiber 首先在 Work Buffer 中执行所有渲染操作，以避免将中间状态呈现在屏幕上。一旦 Work Buffer 中的所有渲染操作完成，React Fiber 将当前缓存与工作缓存进行切换，即将 Work Buffer 设置为当前缓存，以此来更新屏幕上的 UI。\r\n\r\n这样一来，React Fiber 就可以确保在任何时候，所有呈现在屏幕上的内容都是完整和稳定的。\r\n\r\n### mount与update 场景\r\n\r\n当组件第一次被挂载时：\r\n\r\n```jsx\r\nclass MyComponent extends React.Component {\r\n\r\n constructor(props) {\r\n super(props);\r\n this.state = {\r\n count: 0,\r\n };\r\n }\r\n\r\n handleClick = () => {\r\n this.setState((prevState) => ({\r\n count: prevState.count + 1,\r\n }));\r\n }\r\n\r\n render() {\r\n return (\r\n

\r\n Click me: {this.state.count}\r\n

\r\n );\r\n }\r\n}\r\n\r\nReactDOM.render(, document.getElementById('root'));\r\n```\r\n\r\n当我们将 `` 挂载到页面上时，React Fiber 首先会在内存中创建一个空的 Fiber 树，然后根据组件的定义，为组件创建一个初始的“工作单元”（Work In Progress）。\r\n\r\n在这个工作单元内部，React Fiber 会为状态和 props 建立初始的 Fiber 对象，并在之后的更新过程中使用这些 Fiber 对象来跟踪组件的状态和变化。这样可以确保任何时候都可以根据状态和 props 的变化来更新 UI，而不会出现任何问题。\r\n\r\n接下来，React Fiber 开始在工作单元中执行所有的渲染操作，生成一棵虚拟 DOM 树，并将其添加到 Work Buffer 中。然后，React Fiber 会检查 Work Buffer 是否有更改，如果有更改，就将 Work Buffer 与 Current Buffer 进行对比，以查找差异并更新到 DOM 上。\r\n\r\n这个初次渲染的过程不太会涉及到双缓存树，因为当前缓存是空的，所有的操作都是在 Work Buffer 中进行的。但是，一旦初次渲染完成，并且组件状态发生变化时，双缓存树就开始发挥作用了。\r\n\r\n当我们通过点击按钮更新组件状态时，React Fiber 将启动一个新的渲染周期，并为更新创建一个新的工作单元。React Fiber 会在新的工作单元中更新状态、生成新的虚拟 DOM 树，并将其添加到 Work Buffer 中。\r\n\r\n然后，React Fiber 会将 Work Buffer 与 Current Buffer 进行对比，找出差异并将其更新到 DOM 上。但是，由于双缓存树的存在，React Fiber 不会立即将 Work Buffer 切换到 Current Buffer，以避免将中间状态显示在屏幕上。\r\n\r\n### 执行流程\r\n好的，下面是 React Fiber 在页面初次更新时的工作过程的流程图：\r\n\r\n1. 应用程序启动，ReactDOM 调用 `ReactDOM.render()` 方法，并将组件渲染到 DOM 中，React Fiber 创建一个空的 Fiber 树。\r\n2. React Fiber 为组件创建初始的“工作单元”，并在其中创建状态和 props 的 Fiber 对象。\r\n3. React Fiber 执行组件的 `render()` 方法，生成虚拟 DOM 树并添加到工作单元中。\r\n4. React Fiber 将工作单元中的虚拟 DOM 树添加到 Work Buffer 中。\r\n5. React Fiber 检查 Work Buffer 是否有更改，如果有更改，则将其与 Current Buffer 进行对比，并将差异更新到 DOM 上。\r\n6. 由于这是初次渲染，Current Buffer 为空，所有更新操作都在 Work Buffer 中完成，然后将 Work Buffer 设置为 Current Buffer。\r\n7. React Fiber 在内存中保留 Fiber 树的副本，并用于后续的更新操作。此时，组件初次渲染流程结束。\r\n\r\n\r\n",{"_54":439,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/322/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/322/timeline",{"_54":442,"_56":57,"_58":443,"_60":444,"_62":445,"_64":446,"_66":447,"_68":448,"_70":449,"_72":450,"_74":451,"_107":452,"_127":128,"_129":26,"_130":-5,"_131":454,"_133":455,"_155":148,"_149":468,"_151":468,"_154":-5,"_159":160,"_161":469,"_166":-5,"_167":470,"_169":471,"_181":473,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/320","https://api.github.com/repos/pro-collection/interview-question/issues/320/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/320/comments","https://api.github.com/repos/pro-collection/interview-question/issues/320/events","https://github.com/pro-collection/interview-question/issues/320",1687104886,"I_kwDOJGDC6c5kjy12",320,"[React] React Reconciler 为何要采用 fiber 架构？【热度: 1,794】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[453],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":456,"_64":457,"_58":458,"_66":459,"_68":460,"_70":461,"_72":462,"_118":463,"_143":464,"_145":465,"_147":148,"_127":128,"_149":466,"_151":467,"_153":-5,"_154":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/4","https://github.com/pro-collection/interview-question/milestone/4","https://api.github.com/repos/pro-collection/interview-question/milestones/4/labels",9124550,"MI_kwDOJGDC6c4AizrG",4,"资深","资深级别面试问题",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},48,"2023-03-06T15:00:45Z","2024-10-07T08:15:55Z","2023-04-27T15:37:45Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、react fiber、react 协调器\n\n### 代数效应的实践\n\nReact中做的就是践行代数效应（Algebraic Effects）。\n\n简单点儿来说就是： **用于将副作用从函数调用中分离。**\n\n举例子： \n比如我们要获取用户的姓名做展示：\n\n```js\nconst resource = fetchProfileData();\n\nfunction ProfileDetails() {\n // Try to read user info, although it might not have loaded yet\n const user = resource.user.read();\n return

{user.name}

;\n}\n```\n\n代码如上，但是 resource 是通过异步获取的。这个时候代码就要改为下面这种形式\n\n```js\nconst resource = fetchProfileData();\n\nasync function ProfileDetails() {\n // Try to read user info, although it might not have loaded yet\n const user = await resource.user.read();\n return

{user.name}

;\n}\n```\n\n但是 async/await 是具有传染性的。这个穿践行就是副作用，我们不希望有这样的副作用，尽管里面有异步调用，不希望这样的副作用传递给外部的函数，只希望外部的函数是一个纯函数。\n\n### 代数效应在React中的应用\n\n在 react 代码中，每一个函数式组件，其实都是一个纯函数，但是内部里面可能会有各种各样的副作用。这些副作用就是我们使用的 hooks;\n\n对于类似useState、useReducer、useRef这样的Hook，我们不需要关注FunctionComponent的state在Hook中是如何保存的，React会为我们处理。\n\n我们只需要假设useState返回的是我们想要的state，并编写业务逻辑就行。\n\n可以看官方的 Suspense demo, 可以是通过 Suspense 让内部直接可以同步的方式调用异步代码； \n代码链接： https://codesandbox.io/s/frosty-hermann-bztrp?file=/src/index.js:152-160\n```jsx\nimport React, { Suspense } from \"react\";\nimport ReactDOM from \"react-dom\";\n\nimport \"./styles.css\";\nimport { fetchProfileData } from \"./fakeApi\";\n\nconst resource = fetchProfileData();\n\nfunction ProfilePage() {\n return (\n Loading profile...}\n >\n \n Loading posts...}\n >\n \n \n \n );\n}\n\nfunction ProfileDetails() {\n // Try to read user info, although it might not have loaded yet\n const user = resource.user.read();\n return

{user.name}

;\n}\n\nfunction ProfileTimeline() {\n // Try to read posts, although they might not have loaded yet\n const posts = resource.posts.read();\n return (\n

{post.text}

\n );\n}\n\nconst rootElement = document.getElementById(\n \"root\"\n);\nReactDOM.createRoot(rootElement).render(\n \n);\n```\n\n### Generator 架构\n\n从React15到React16，协调器（Reconciler）重构的一大目的是：将老的同步更新的架构变为异步可中断更新。\n\n异步可中断更新可以理解为：更新在执行过程中可能会被打断（浏览器时间分片用尽或有更高优任务插队），当可以继续执行时恢复之前执行的中间状态。\n\n其实，浏览器原生就支持类似的实现，这就是Generator。\n\n但是Generator的一些缺陷使React团队放弃了他：\n\n- 类似async，Generator也是传染性的，使用了Generator则上下文的其他函数也需要作出改变。这样心智负担比较重。\n- Generator执行的中间状态是上下文关联的。\n\n例如这样的例子：\n```js\nfunction* doWork(A, B, C) {\n var x = doExpensiveWorkA(A);\n yield;\n var y = x + doExpensiveWorkB(B);\n yield;\n var z = y + doExpensiveWorkC(C);\n return z;\n}\n```\n\n但是当我们考虑“高优先级任务插队”的情况，如果此时已经完成doExpensiveWorkA与doExpensiveWorkB计算出x与y。\n\n此时B组件接收到一个高优更新，由于Generator执行的中间状态是上下文关联的，所以计算y时无法复用之前已经计算出的x，需要重新计算。\n\n如果通过全局变量保存之前执行的中间状态，又会引入新的复杂度。\n\n### fiber 架构\n\n他的中文翻译叫做纤程，与进程（Process）、线程（Thread）、协程（Coroutine）同为程序执行过程。\n\n在很多文章中将纤程理解为协程的一种实现。在JS中，协程的实现便是Generator。\n\n所以，我们可以将纤程(Fiber)、协程(Generator)理解为代数效应思想在JS中的体现。\n\nReact Fiber可以理解为：\n\nReact内部实现的一套状态更新机制。支持任务不同优先级，可中断与恢复，并且恢复后可以复用之前的中间状态。\n\n其中每个任务更新单元为React Element对应的Fiber节点。\n\n\n\n",{"_54":472,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/320/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/320/timeline",{"_54":475,"_56":57,"_58":476,"_60":477,"_62":478,"_64":479,"_66":480,"_68":481,"_70":482,"_72":483,"_74":484,"_107":485,"_127":128,"_129":26,"_130":-5,"_131":487,"_133":488,"_155":148,"_149":490,"_151":491,"_154":-5,"_159":160,"_161":492,"_166":-5,"_167":493,"_169":494,"_181":496,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/319","https://api.github.com/repos/pro-collection/interview-question/issues/319/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/319/comments","https://api.github.com/repos/pro-collection/interview-question/issues/319/events","https://github.com/pro-collection/interview-question/issues/319",1687063658,"I_kwDOJGDC6c5kjoxq",319,"[React] React16 是什么样的架构特点？【热度: 2,403】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[486],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":489,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-27T15:12:52Z","2023-04-27T15:13:45Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react16 架构、react Reconciler、react fiber、react 渲染器、react 协调器\n\nReact16架构可以分为三层：\n\nScheduler（调度器）—— 调度任务的优先级，高优任务优先进入Reconciler\nReconciler（协调器）—— 负责找出变化的组件\nRenderer（渲染器）—— 负责将变化的组件渲染到页面上\n可以看到，相较于React15，React16中新增了Scheduler（调度器）。\n\n### Scheduler（调度器）\n\n以浏览器是否有剩余时间作为任务中断的标准，那么**需要一种机制，当浏览器有剩余时间时通知我们**。\n\n其实部分浏览器已经实现了这个API，这就是 `requestIdleCallback` (opens new window)。但是由于以下因素，React放弃使用：\n\n- 浏览器兼容性\n- 触发频率不稳定，受很多因素影响。比如当我们的浏览器切换tab后，之前tab注册的 `requestIdleCallback` 触发的频率会变得很低\n\n基于以上原因，React实现了功能更完备的 `requestIdleCallback polyfill`，这就是`Scheduler`。除了在空闲时触发回调的功能外，`Scheduler` 还提供了多种调度优先级供任务设置。\n\nScheduler (opens new window) 是独立于React的库\n\n### Reconciler（协调器）\n\n在 React15 中 `Reconciler` 是递归处理虚拟DOM的\n\n在 React16 中更新工作从递归变成了可以中断的循环过程。每次循环都会调用 `shouldYield` 判断当前是否有剩余时间。\n```js\n/** @noinline */\nfunction workLoopConcurrent() {\n // Perform work until Scheduler asks us to yield\n while (workInProgress !== null && !shouldYield()) {\n workInProgress = performUnitOfWork(workInProgress);\n }\n}\n```\n\n**那么React16是如何解决中断更新时DOM渲染不完全的问题呢？**\n\n在React16中，Reconciler与Renderer不再是交替工作。当Scheduler将任务交给Reconciler后，Reconciler会为变化的虚拟DOM打上代表增/删/更新的标记；\n\n全部标记可以见这里： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/react-reconciler/src/ReactSideEffectTags.js\n\n整个Scheduler与 Reconciler 的工作都在内存中进行。只有当所有组件都完成Reconciler的工作，才会统一交给Renderer。\n\n可以看这里 react16 对 Reconciler 的解释：https://zh-hans.legacy.reactjs.org/docs/codebase-overview.html#fiber-reconciler\n\nReconciler 内部采用了 `Fiber` 的架构。\n\n### Renderer（渲染器）\n\nRenderer根据Reconciler为虚拟DOM打的标记，同步执行对应的DOM操作。\n\n\n\n### 参考资料 \n- https://react.iamkasong.com/preparation/newConstructure.html#react16%E6%9E%B6%E6%9E%84\n\n\n\n```js\n\n```\n",{"_54":495,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/319/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/319/timeline",{"_54":498,"_56":57,"_58":499,"_60":500,"_62":501,"_64":502,"_66":503,"_68":504,"_70":505,"_72":506,"_74":507,"_107":508,"_127":128,"_129":26,"_130":-5,"_131":510,"_133":511,"_155":148,"_149":513,"_151":514,"_154":-5,"_159":160,"_161":515,"_166":-5,"_167":516,"_169":517,"_181":519,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/318","https://api.github.com/repos/pro-collection/interview-question/issues/318/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/318/comments","https://api.github.com/repos/pro-collection/interview-question/issues/318/events","https://github.com/pro-collection/interview-question/issues/318",1687040816,"I_kwDOJGDC6c5kjjMw",318,"[React] React15 架构存在什么样的问题？【热度: 1,613】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[509],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":512,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-27T14:59:36Z","2023-04-27T15:13:34Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react15 架构、react 架构、react Reconciler、react 渲染器、react 协调器\n\nReact15 架构可以分为两层：\n\n- Reconciler（协调器）—— 负责找出变化的组件\n- Renderer（渲染器）—— 负责将变化的组件渲染到页面上\n\n### Reconciler（协调器）\n\n我们知道，在React中可以通过 `this.setState、this.forceUpdate、ReactDOM.render` 等API触发更新。\n\n每当有更新发生时，Reconciler会做如下工作：\n\n- 调用函数组件、或class组件的render方法，将返回的JSX转化为虚拟DOM\n- 将虚拟DOM和上次更新时的虚拟DOM对比\n- 通过对比找出本次更新中变化的虚拟DOM\n- 通知Renderer将变化的虚拟DOM渲染到页面上\n\n### Renderer（渲染器）\n由于React支持跨平台，所以不同平台有不同的Renderer。我们前端最熟悉的是负责在浏览器环境渲染的Renderer —— `ReactDOM`\n\n除此之外，还有：\n\n- ReactNative 渲染器，渲染App原生组件\n- ReactTest 渲染器，渲染出纯Js对象用于测试\n- ReactArt 渲染器，渲染到Canvas, SVG 或 VML (IE8)\n\n在每次更新发生时，Renderer接到 `Reconciler` 通知，将变化的组件渲染在当前宿主环境。\n\n### React15 架构的缺点\n**react15 是通过递归去更新组件的**\n\n在 Reconciler 中，mount的组件会调用 mountComponent (opens new window)，update 的组件会调用 updateComponent (opens new window)。这两个方法都会递归更新子组件。\n\n**由于递归执行，所以更新一旦开始，中途就无法中断。当层级很深时，递归更新时间超过了16ms，用户交互就会卡顿。**\n\n本质上说是因为递归的架构，是不允许中断的，因为 react 希望有更好的渲染性能，那么面对大规模 dom diff 更新渲染的时候，就不能让每一递归时间超过 16 ms。\n递归是做不到这个功能的。所以只有重写 react15 架构。引入了 react16 fiber 架构。\n\n\n\n",{"_54":518,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/318/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/318/timeline",{"_54":521,"_56":57,"_58":522,"_60":523,"_62":524,"_64":525,"_66":526,"_68":527,"_70":528,"_72":529,"_74":530,"_107":531,"_127":128,"_129":26,"_130":-5,"_131":533,"_133":534,"_155":148,"_149":536,"_151":537,"_154":-5,"_159":160,"_161":538,"_166":-5,"_167":539,"_169":540,"_181":542,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/317","https://api.github.com/repos/pro-collection/interview-question/issues/317/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/317/comments","https://api.github.com/repos/pro-collection/interview-question/issues/317/events","https://github.com/pro-collection/interview-question/issues/317",1687022155,"I_kwDOJGDC6c5kjepL",317,"[React] react 是如何实现页面的快速响应？【热度: 696】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[532],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":535,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-27T14:49:35Z","2023-04-27T15:13:20Z",{"_163":148,"_164":148,"_165":148},"**关键词**：react 快速响应实现、react 可中断更新、react IO瓶颈、react CPU瓶颈\n\n### react 是如何实现快速响应的？\n\n我们日常使用App，浏览网页时，有两类场景会制约快速响应：\n\n当遇到大计算量的操作或者设备性能不足使页面掉帧，导致卡顿。\n\n发送网络请求后，由于需要等待数据返回才能进一步操作导致不能快速响应。\n\n这两类场景可以概括为：\n\n- CPU的瓶颈\n- IO的瓶颈\n\n### CPU的瓶颈\n\n**主流浏览器刷新频率为60Hz，即每（1000ms / 60Hz）16.6ms浏览器刷新一次。**\n\n我们知道，JS可以操作DOM，GUI渲染线程与JS线程是互斥的。所以JS脚本执行和浏览器布局、绘制不能同时执行。\n\n在每16.6ms时间内，需要完成如下工作： `JS脚本执行 ----- 样式布局 ----- 样式绘制`\n\n当JS执行时间过长，超出了16.6ms，这次刷新就没有时间执行样式布局和样式绘制了。\n\n比如我们可以通过一个循环，渲染列表 3000 个组件，那么这种渲染时间，就肯定是远超过 16.6 ms 的，页面就会感觉到卡顿。\n\n如何解决这个问题呢？\n\n**答案是：在浏览器每一帧的时间中，预留一些时间给JS线程，React利用这部分时间更新组件（可以看到，在源码中，预留的初始时间是5ms）。** \n源码位置： https://github.com/facebook/react/blob/1fb18e22ae66fdb1dc127347e169e73948778e5a/packages/scheduler/src/forks/SchedulerHostConfig.default.js#L119\n\n当预留的时间不够用时，React将线程控制权交还给浏览器使其有时间渲染UI，React则等待下一帧时间到来继续被中断的工作。\n\n这种将长任务分拆到每一帧中，像蚂蚁搬家一样一次执行一小段任务的操作，被称为时间切片（time slice）\n\n**所以，解决CPU瓶颈的关键是实现时间切片，而时间切片的关键是：将同步的更新变为可中断的异步更新。**\n\n### IO的瓶颈\n\n网络延迟是前端开发者无法解决的。如何在网络延迟客观存在的情况下，减少用户对网络延迟的感知？\n\n简单点儿来说，就是在点击页面跳转的是时候提前去加载下一个页面的内容。或者在当前页面 hold .5s 左右时间，利用这个时间去加载下一个页面的内容。 \n从而达到下一个页面的快速交互\n\nReact实现了 `Suspense` 功能及配套的 hook——`useDeferredValue`。\n\n而在源码内部，为了支持这些特性，**同样需要将同步的更新变为可中断的异步更新。**\n",{"_54":541,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/317/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/317/timeline",{"_54":544,"_56":57,"_58":545,"_60":546,"_62":547,"_64":548,"_66":549,"_68":550,"_70":551,"_72":552,"_74":553,"_107":554,"_127":128,"_129":26,"_130":-5,"_131":557,"_133":558,"_155":148,"_149":560,"_151":561,"_154":-5,"_159":160,"_161":562,"_166":-5,"_167":563,"_169":564,"_181":566,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/306","https://api.github.com/repos/pro-collection/interview-question/issues/306/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/306/comments","https://api.github.com/repos/pro-collection/interview-question/issues/306/events","https://github.com/pro-collection/interview-question/issues/306",1680054594,"I_kwDOJGDC6c5kI5lC",306,"[React] 如何监听路由变化？【热度: 679】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[555,556],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":290,"_68":291,"_54":292,"_113":293,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":559,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-23T14:53:27Z","2023-04-23T14:53:28Z",{"_163":148,"_164":148,"_165":148},"**依赖**\n\n- react-router-dom v6\n- react v18\n\n### 实现\n\n监听的核心原理基于useEffect，和useLocation，通过useEffect监听当前location的变化，这样就实现的最基本的监听结构：\n\n```jsx\nconst location = useLocation();\nuseEffect(() => {\n //记录路径\n}, [location]);\n```\n\n然后，我们可以在useEffect中记录和更新from、to的值，可以根据自己的需要选择from、to的数据类型，这里我使用了React-router提供的Location类型。\n\n更新逻辑为：将to的值赋给from，然后将新的location赋值给to\n\n```typescript jsx\nimport { Location, useLocation } from \"react-router-dom\";\n\ntype LocationTrans = {\n from: Location;\n to: Location;\n};\n\nconst location = useLocation();\nconst locationState = useRef({\n from: null,\n to: null,\n});\n\nuseEffect(() => {\n locationState.current.from = locationState.current.to;\n locationState.current.to = location;\n}, [location]);\n```\n\n最后，利用React的Context进行封装，将其封装成一个组件和一个hook，使用者可以通过这个组件来进行监听，通过hook快速访问数据。我将这些代码放在了同一个.tsx文件中，保证了逻辑的高内聚。\n\n```typescript jsx\nimport React, { createContext, useContext, useEffect, useRef } from \"react\";\nimport { Location, useLocation } from \"react-router-dom\";\n\n\ntype LocationTrans = {\n from: Location;\n to: Location;\n};\n\nexport const LocationContext =\n createContext>(null);\n\nexport function WithLocationListener(props: { children: React.ReactNode }) {\n const location = useLocation();\n\n const locationState = useRef({\n from: null,\n to: null,\n });\n\n useEffect(() => {\n locationState.current.from = locationState.current.to;\n locationState.current.to = location;\n }, [location]);\n\n return (\n \n {props.children}\n \n );\n}\n\nexport function useLocationConsumer(): LocationTrans {\n const ref = useContext(LocationContext);\n return ref.current;\n}\n```\n\n### 使用\n\n这个组件只能在RouterProvider的子组件中使用，因为useLocation只能在这个范围内使用。\n\n```typescript jsx\n//import ....\n\nfunction Layout() {\n return (\n \n {/* ..... */}\n \n );\n}\n```\n\n在需要用到路由信息的页面：\n\n```typescript jsx\nconst { from, to } = useLocationConsumer();\n```\n\n### 参考文档\n- https://juejin.cn/post/7195910055497580600\n",{"_54":565,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/306/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/306/timeline",{"_54":568,"_56":57,"_58":569,"_60":570,"_62":571,"_64":572,"_66":573,"_68":574,"_70":575,"_72":576,"_74":577,"_107":578,"_127":128,"_129":26,"_130":-5,"_131":581,"_133":582,"_155":148,"_149":584,"_151":585,"_154":-5,"_159":160,"_161":586,"_166":-5,"_167":587,"_169":588,"_181":590,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/305","https://api.github.com/repos/pro-collection/interview-question/issues/305/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/305/comments","https://api.github.com/repos/pro-collection/interview-question/issues/305/events","https://github.com/pro-collection/interview-question/issues/305",1680052575,"I_kwDOJGDC6c5kI5Ff",305,"[React] 开发过程中有哪些性能优化手段？【热度: 1,511】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[579,580],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":290,"_68":291,"_54":292,"_113":293,"_115":125,"_117":26,"_118":126},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":583,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-23T14:47:00Z","2023-04-23T14:47:01Z",{"_163":148,"_164":148,"_165":148},"### 路由懒加载\n\n两种方式可实现:\n\n- 使用 React 中 Suspense,lazy\n- 使用 react-loadable\n\n#### React 中 Suspense,lazy\n\n应用的组件需要使用 lazy 的方式引入，且使用 Suspense 包裹异步加载的组件\n\n```jsx\n import { Route, Switch } from 'react-router-dom';\n\nconst MainCom = lazy(() => import('../views/main/maincom'));\n\nclass RouterConfig extends React.Component {\n render() {\n return (\n 加载中 }>\n \n ...\n \n ...\n \n\n \n )\n }\n}\n\nexport default RouterConfig;\n```\n\n#### react-loadable\n\n```jsx\n import { Route, Switch } from 'react-router-dom';\nimport Loadable from 'react-loadable';\n\nconst logincom = Loadable({\n loader: () => import('../views/login/login'),\n loading() {\n return

正在加载

\n },\n})\n\nclass RouterConfig extends React.Component {\n render() {\n return (\n 加载中 }>\n \n ...\n \n ...\n \n\n \n )\n }\n}\n\nexport default RouterConfig;\n```\n\n### 受控性组件颗粒化，独立请求服务渲染单元\n\n可控性组件颗粒化，独立请求服务渲染单元是笔者在实际工作总结出来的经验。目的就是避免因自身的渲染更新或是副作用带来的全局重新渲染。\n\n大概思路是这样子的：\n![1](https://foruda.gitee.com/images/1682260059688615416/19b33481_7819612.png)\n\n拆分需要单独调用后端接口的细小组件，建立独立的数据请求和渲染，这种依赖数据更新 -> 视图渲染的组件，能从整个体系中抽离出来，好处我总结有以下几个方面。\n\n1. 可以避免父组件的冗余渲染，react的数据驱动，依赖于 state 和 props 的改变，改变state 必然会对组件 render 函数调用，如果父组件中的子组件过于复杂，一个自组件的 state\n 改变，就会牵一发动全身，必然影响性能，所以如果把很多依赖请求的组件抽离出来，可以直接减少渲染次数。\n\n2. 可以优化组件自身性能，无论从class声明的有状态组件还是fun声明的无状态，都有一套自身优化机制，无论是用shouldupdate 还是用 hooks中 useMemo useCallback\n ，都可以根据自身情况，定制符合场景的渲条件，使得依赖数据请求组件形成自己一个小的，适合自身的渲染环境。\n\n3. 能够和redux ,以及redux衍生出来 redux-action , dva,更加契合的工作，用 connect\n 包裹的组件，就能通过制定好的契约，根据所需求的数据更新，而更新自身，而把这种模式用在这种小的，需要数据驱动的组件上，就会起到物尽其用的效果。\n\n### shouldComponentUpdate ,PureComponent 和 React.memo ,immetable.js/immer.js 助力性能调优\n\n#### PureComponent 和 React.memo\n\nReact.PureComponent 通过props和state的浅对比来实现 shouldComponentUpate()。如果对象包含复杂的数据结构(比如对象和数组)\n，他会浅比较，如果深层次的改变，是无法作出判断的，React.PureComponent 认为没有变化，而没有渲染试图。\n\nreact.memo 和 PureComponent 功能类似，react.memo 作为第一个高阶组件，第二个参数可以对props 进行比较，和shouldComponentUpdate不同的, 当第二个参数返回 true\n的时候，证明props没有改变，不渲染组件，反之渲染组件。\n\n#### shouldComponentUpdate\n\n使用 shouldComponentUpdate() 以让React知道当state或props的改变是否影响组件的重新render，默认返回ture，返回false时不会重新渲染更新，而且该方法并不会在初始化渲染或当使用\nforceUpdate() 时被调用。\n\n#### immetable.js/immer.js\n\nimmetable.js 是Facebook 开发的一个js库，可以提高对象的比较性能，像之前所说的pureComponent 只能对对象进行浅比较，,对于对象的数据类型,却束手无策,所以我们可以用 immetable.js 配合\nshouldComponentUpdate 或者 react.memo来使用。immutable 中我们用react-redux来简单举一个例子，如下所示数据都已经被 immetable.js处理。\n\n```jsx\nimport { is } from 'immutable'\n\nconst GoodItems = connect(state =>\n ({ GoodItems: filter(state.getIn(['Items', 'payload', 'list']), state.getIn(['customItems', 'payload', 'list'])) || Immutable.List(), })\n /* 此处省略很多代码～～～～～～ */\n)(memo(({ Items, dispatch, setSeivceId }) => {\n /* */\n}, (pre, next) => is(pre.Items, next.Items)))\n\n```\n\n通过 is 方法来判断，前后Items(对象数据类型)是否发生变化。\n\n**immer** 是 mobx 的作者写的一个 immutable 库，核心实现是利用 ES6 的 proxy，几乎以最小的成本实现了 js 的不可变数据结构，简单易用、体量小巧、设计巧妙，满足了我们对 JS 不可变数据结构的需求。\n\n具体使用可见： https://juejin.cn/post/7157745748832944141\n\n### hooks 组件中，常使用 useMemo、useCallback、useRef 等方式方式重复申明\n\n每次点击button的时候,都会执行Index函数。handerClick1 , handerClick2,handerClick3都会重新声明。这种函数的重复申明，会使得子组件每次都是拿到的新的应用对象，会导致 memo 直接失效。\n\n```jsx\nfunction Index() {\n const [number, setNumber] = useState(0)\n const [handerClick1, handerClick2, handerClick3] = useMemo(() => {\n const fn1 = () => {\n /* 一些操作 */\n }\n const fn2 = () => {\n /* 一些操作 */\n }\n const fn3 = () => {\n /* 一些操作 */\n }\n return [fn1, fn2, fn3]\n }, []) /* 只有当数据里面的依赖项，发生改变的时候，才会重新声明函数。 */\n return

\n 点我有惊喜1\n 点我有惊喜2\n 点我有惊喜3\n \n

\n}\n```\n\n推荐使用 ahooks - usePersistFn、useMemoizedFn 其实现也非常简单，就是将函数的应用绑定在了 ref 上\n\n```jsx\nfunction usePersistFn(fn, deps) {\n const fnRef = useRef();\n\n useEffect(() => {\n fnRef.current = fn;\n }, [fn, ...deps]);\n\n return useCallback(() => {\n return fnRef.current();\n }, [fnRef]);\n}\n```\n\n### 警惕 context 陷阱\n使用Context可以避免的组件的层层props嵌套的问题。但是它使用consumer拿值时,会多一层组件。但得益于 useContext hook 我们可以不使用consumer组件。直接拿到值,直观。一般的使用场景,如那拿全局的class前缀，或者国际化，Ui主题颜色等。\n\n**但是当 Provider 的 value 值发生变化时，它内部的所有消费组件都会重新渲染。Provider 及其内部 consumer 组件都不受制于 shouldComponentUpdate、memo 等函数，因此当 consumer 组件在其祖先组件退出更新的情况下也能更新。**\n\n使用 `createContext 和 useContext` 的时候，尽量从顶层往下传递的数据是不可变的数据，否则会引起整个链路层级的渲染。 \n\n此处推荐使用 `recoil`，由 facebook 官方出品，使用语法非常简单，跟 context 很类似。\n\n",{"_54":589,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/305/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/305/timeline",{"_54":592,"_56":57,"_58":593,"_60":594,"_62":595,"_64":596,"_66":597,"_68":598,"_70":599,"_72":600,"_74":601,"_107":602,"_127":128,"_129":26,"_130":-5,"_131":604,"_133":605,"_155":148,"_149":607,"_151":608,"_154":-5,"_159":160,"_161":609,"_166":-5,"_167":610,"_169":611,"_181":613,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/304","https://api.github.com/repos/pro-collection/interview-question/issues/304/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/304/comments","https://api.github.com/repos/pro-collection/interview-question/issues/304/events","https://github.com/pro-collection/interview-question/issues/304",1680040487,"I_kwDOJGDC6c5kI2In",304,"[React] ref 是如何拿到函数组件的实例【热度: 881】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[603],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":606,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-23T14:07:56Z","2023-04-23T14:17:50Z",{"_163":148,"_164":148,"_165":148},"### 使用`forwordRef`\n\n将`input`单独封装成一个组件`TextInput`。\n\n```jsx\nconst TextInput = React.forwardRef((props,ref) => {\n return \n})\n\n```\n\n用`TextInputWithFocusButton`调用它\n\n```jsx\nfunction TextInputWithFocusButton() {\n // 关键代码\n const inputEl = useRef(null);\n const onButtonClick = () => {\n // 关键代码，`current` 指向已挂载到 DOM 上的文本输入元素\n inputEl.current.focus();\n };\n return (\n <>\n // 关键代码\n \n \n \n );\n}\n\n```\n\n### useImperativeHandle\n\n有时候，我们可能**不想将整个子组件暴露给父组件**，而只是暴露出父组件需要的值或者方法，这样可以让代码更加明确。而`useImperativeHandle` Api就是帮助我们做这件事的。\n\n```jsx\nconst TextInput = forwardRef((props,ref) => {\n const inputRef = useRef();\n // 关键代码\n useImperativeHandle(ref, () => ({\n focus: () => {\n inputRef.current.focus();\n }\n }));\n return \n})\n\n\nfunction TextInputWithFocusButton() {\n // 关键代码\n const inputEl = useRef(null);\n const onButtonClick = () => {\n // 关键代码，`current` 指向已挂载到 DOM 上的文本输入元素\n inputEl.current.focus();\n };\n return (\n <>\n // 关键代码\n \n \n \n );\n}\n\n\n```\n\n也可以使用`current.focus()`来做`input`聚焦。\n\n> 这里要注意的是，子组件`TextInput`中的`useRef`对象，只是用来获取`input`元素的，大家不要和父组件的`useRef`混淆了。\n",{"_54":612,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/304/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/304/timeline",{"_54":615,"_56":57,"_58":616,"_60":617,"_62":618,"_64":619,"_66":620,"_68":621,"_70":622,"_72":623,"_74":624,"_107":625,"_127":128,"_129":26,"_130":-5,"_131":628,"_133":629,"_155":148,"_149":631,"_151":632,"_154":-5,"_159":160,"_161":633,"_166":-5,"_167":634,"_169":635,"_181":637,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/302","https://api.github.com/repos/pro-collection/interview-question/issues/302/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/302/comments","https://api.github.com/repos/pro-collection/interview-question/issues/302/events","https://github.com/pro-collection/interview-question/issues/302",1680037895,"I_kwDOJGDC6c5kI1gH",302,"[React] Hooks 有哪些？【热度: 2,594】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[626,627],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":251,"_68":252,"_54":253,"_113":254,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":630,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-23T14:00:05Z","2023-10-02T03:40:53Z",{"_163":148,"_164":148,"_165":148},"### react 16.8 hooks\r\n\r\n- useState\r\n- useEffect\r\n- useContext\r\n- useReducer\r\n- useMemo\r\n- useCallback\r\n- useRef\r\n- useImperativeHandle\r\n- useLayoutEffect\r\n- useDebugValue\r\n\r\n\r\n### React v18中的hooks\r\n- useSyncExternalStore\r\n- useTransition\r\n- useDeferredValue\r\n- useInsertionEffect\r\n- useId\r\n\r\n\r\n### 简单介绍一下 react 18 新增的 hooks\r\n\r\n### useSyncExternalStore\r\n\r\n`useSyncExternalStore`:是一个推荐用于**读取和订阅外部数据源**的 `hook`，其方式与选择性的 `hydration` 和时间切片等并发渲染功能兼容\r\n\r\n```javascript\r\nconst state = useSyncExternalStore(\r\n subscribe,\r\n getSnapshot[, getServerSnapshot]\r\n)\r\n\r\n```\r\n\r\n* `subscribe`: 订阅函数，用于注册一个回调函数，**当存储值发生更改时被调用**。此外， `useSyncExternalStore` 会通过带有记忆性的 `getSnapshot` 来判别数据是否发生变化，如果发生变化，那么会**强制更新数据**。\r\n* `getSnapshot`: 返回当前存储值的函数。必须返回缓存的值。如果 `getSnapshot` 连续多次调用，则必须返回相同的确切值，除非中间有存储值更新。\r\n* `getServerSnapshot`：返回服务端(hydration模式下)渲染期间使用的存储值的函数\r\n\r\n---\r\n\r\n#### useTransition\r\n\r\n> `useTransition`：\r\n>\r\n> * 返回一个**状态值**表示过渡任务的等待状态，\r\n> * 以及一个启动该过渡任务的函数。\r\n\r\n**过渡任务** 在一些场景中，如：`输入框`、`tab切换`、`按钮`等，这些任务需要视图上立刻做出响应，这些任务可以称之为**立即更新的任务**\r\n\r\n但有的时候，更新任务并不是那么紧急，或者来说要去请求数据等，导致新的状态不能立马更新，需要用一个`loading...`的等待状态，这类任务就是过度任务\r\n\r\n```javascript\r\nconst [isPending, startTransition] = useTransition();\r\n\r\n```\r\n\r\n* `isPending`：**过渡状态的标志**，为`true`时是等待状态\r\n* `startTransition`：可以**将里面的任务变成过渡任务**\r\n\r\n---\r\n\r\n#### useDeferredValue\r\n\r\n> `useDeferredValue`：接受一个值，并返回该值的新副本，该副本将**推迟**到更紧急地更新之后。\r\n\r\n如果当前渲染是一个紧急更新的结果，比如用户输入，`React` 将**返回之前的值**，然后**在紧急渲染完成后渲染新的值**。\r\n\r\n也就是说`useDeferredValue`可以让状态滞后派生。\r\n\r\n```javascript\r\nconst deferredValue = useDeferredValue(value);\r\n\r\n```\r\n\r\n* `value`：可变的值，如`useState`创建的值\r\n* `deferredValue`: 延时状态\r\n\r\n> **useTransition和useDeferredValue做个对比**\r\n>\r\n> * 相同点：`useDeferredValue` 和 `useTransition` 一样，都是**过渡更新任务**\r\n> * 不同点：`useTransition` 给的是一个**状态**，而`useDeferredValue`给的是一个**值**\r\n\r\n---\r\n\r\n#### useInsertionEffect\r\n\r\n`useInsertionEffect`：与 `useLayoutEffect` 一样，但它在所有 DOM 突变之前**同步触发**\r\n\r\n在执行顺序上 `useInsertionEffect` > `useLayoutEffect` > `useEffect`\r\n\r\n> `seInsertionEffect` 应仅限于 `css-in-js` 库作者使用。 \r\n> 优先考虑使用 `useEffect` 或 `useLayoutEffect` 来替代。\r\n\r\n---\r\n\r\n#### useId\r\n\r\n`useId` ：是一个**用于生成横跨服务端和客户端的稳定的唯一 ID** 的同时避免`hydration`不匹配的 hook。\r\n\r\n---\r\n\r\n\r\n### 参考文档\r\n- https://juejin.cn/post/7118937685653192735\r\n",{"_54":636,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/302/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/302/timeline",{"_54":639,"_56":57,"_58":640,"_60":641,"_62":642,"_64":643,"_66":644,"_68":645,"_70":646,"_72":647,"_74":648,"_107":649,"_127":128,"_129":26,"_130":-5,"_131":651,"_133":652,"_155":148,"_149":654,"_151":655,"_154":-5,"_159":160,"_161":656,"_166":-5,"_167":657,"_169":658,"_181":660,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/301","https://api.github.com/repos/pro-collection/interview-question/issues/301/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/301/comments","https://api.github.com/repos/pro-collection/interview-question/issues/301/events","https://github.com/pro-collection/interview-question/issues/301",1680033449,"I_kwDOJGDC6c5kI0ap",301,"[React] 生命周期有哪些？【热度: 889】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[650],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":653,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-23T13:45:38Z","2023-04-23T14:17:15Z",{"_163":148,"_164":148,"_165":148},"主要生命周期分为两个版本，\n\n分别是： `v16.0前` 和 `v16.4`\n\n### v16.0 前\n\n![1](https://foruda.gitee.com/images/1682257247128664078/b5848c64_7819612.png)\n\n总共分为**四大阶段**：\n\n1. {初始化| Intialization}\n2. {挂载| Mounting}\n3. {更新| Update}\n4. {卸载| Unmounting}\n\n\n#### Intialization(初始化）\n\n在初始化阶段,会用到 `constructor()` 这个构造函数，如：\n\n```javascript\nconstructor(props) {\n super(props);\n}\n\n```\n\n* `super`的作用\n * 用来调用*基类*的构造方法( `constructor()` ),\n * 也**将父组件的`props`注入给子组件，供子组件读取**\n* 初始化操作，定义`this.state`的初始内容\n* **只会执行一次**\n\n---\n\n#### Mounting(挂载）（3个）\n\n1. `componentWillMount`：**在组件挂载到`DOM`前调用**\n\n * 这里面的调用的`this.setState`不会引起组件的重新渲染，也可以把写在这边的内容提到`constructor()`，所以在项目中很少。\n * **只会调用一次**\n2. `render`: 渲染\n * 只要`props`和`state`发生改变（无论值是否有变化,两者的重传递和重赋值，都可以引起组件重新`render`），`都会重新渲染render`。\n * `return`：**是必须的，是一个React元素**，不负责组件实际渲染工作，由`React`自身根据此元素去渲染出`DOM`。\n * `render` 是**纯函数**，不能执行`this.setState`。\n3. `componentDidMount`：**组件挂载到`DOM`后调用**\n\n * **调用一次**\n\n---\n\n#### Update(更新)（5个）\n\n1. `componentWillReceiveProps(nextProps)`:调用于`props`引起的组件更新过程中\n\n * `nextProps`：父组件传给当前组件新的`props`\n * 可以用`nextProps`和`this.props`来查明重传`props`是否发生改变（原因：不能保证父组件重传的`props`有变化）\n * 只要`props`发生变化就会，引起调用\n\n2. `shouldComponentUpdate(nextProps, nextState)`：用于性能优化\n\n * `nextProps`：当前组件的`this.props`\n * `nextState`：当前组件的`this.state`\n * 通过比较`nextProps`和`nextState`,来判断当前组件是否有必要继续执行更新过程。\n * 返回`false`：表示停止更新，用于减少组件的不必要渲染，优化性能\n * 返回`true`：继续执行更新\n * 像`componentWillReceiveProps（）`中执行了`this.setState`，更新了`state`，但**在`render`前**(如`shouldComponentUpdate`，`componentWillUpdate`)，`this.state`依然指向更新前的state，不然`nextState`及当前组件的`this.state`的对比就一直是`true`了\n\n3. `componentWillUpdate(nextProps, nextState)`：组件更新前调用\n\n * 在`render`方法前执行\n * 由于组件更新就会调用，所以一般很少使用\n\n4. `render`：重新渲染\n\n5. `componentDidUpdate(prevProps, prevState)`：组件更新后被调用\n\n * `prevProps`：组件更新前的`props`\n * `prevState`：组件更新前的`state`\n * 可以操作组件更新的DOM\n\n---\n\n#### Unmounting(卸载)（1个）\n\n`componentWillUnmount`：组件被卸载前调用\n\n可以在这里执行一些**清理工作**，比如清除组件中使用的*定时器*，清除`componentDidMount`中*手动创建的DOM元素*等，以避免引起内存泄漏\n\n---\n\n\n### React v16.4\n\n![2](https://foruda.gitee.com/images/1682257393147988566/aa702114_7819612.png)\n\n与 `v16.0`的生命周期相比\n\n* 新增了 -- （两个`getXX`）\n 1. `getDerivedStateFromProps`\n 2. `getSnapshotBeforeUpdate`\n* 取消了 -- (三个`componmentWillXX`)\n 1. `componentWillMount`、\n 2. `componentWillReceiveProps`、\n 3. `componentWillUpdate`\n\n\n#### getDerivedStateFromProps\n\n`getDerivedStateFromProps(prevProps, prevState)`：组件创建和更新时调用的方法\n\n* `prevProps`：组件更新前的`props`\n* `prevState`：组件更新前的`state`\n\n> 在`React v16.3`中，在创建和更新时，只能是由父组件引发才会调用这个函数，在`React v16.4`改为无论是`Mounting`还是`Updating`，全部都会调用。\n\n是一个静态函数，也就是这个函数不能通过`this`访问到`class`的属性。\n\n> 如果`props`传入的内容不需要影响到你的`state`，那么就需要返回一个`null`，这个**返回值是必须的**，所以尽量将其写到函数的末尾。\n\n在组件创建时和更新时的render方法之前调用，它应该\n\n* 返回一个对象来更新状态\n* 或者返回`null`来不更新任何内容\n\n#### getSnapshotBeforeUpdate\n\n`getSnapshotBeforeUpdate(prevProps,prevState)`:`Updating`时的函数，在render之后调用\n\n* `prevProps`：组件更新前的`props`\n* `prevState`：组件更新前的`state`\n\n可以读取，但无法使用DOM的时候，在组件可以在可能更改之前从`DOM`捕获一些信息（例如滚动位置）\n\n> **返回的任何值都将作为参数传递给`componentDidUpdate（)`**\n\n---\n\n\n### Note\n\n在`17.0`的版本，官方彻底废除\n\n* `componentWillMount`、\n* `componentWillReceiveProps`、\n* `componentWillUpdate`\n",{"_54":659,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/301/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/301/timeline",{"_54":662,"_56":57,"_58":663,"_60":664,"_62":665,"_64":666,"_66":667,"_68":668,"_70":669,"_72":670,"_74":671,"_107":672,"_127":128,"_129":26,"_130":-5,"_131":674,"_133":675,"_155":156,"_149":677,"_151":678,"_154":-5,"_159":160,"_161":679,"_166":-5,"_167":680,"_169":681,"_181":683,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/299","https://api.github.com/repos/pro-collection/interview-question/issues/299/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/299/comments","https://api.github.com/repos/pro-collection/interview-question/issues/299/events","https://github.com/pro-collection/interview-question/issues/299",1677047724,"I_kwDOJGDC6c5j9bes",299,"[React] React 18 的新特性有哪些【热度: 989】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[673],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":676,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-20T16:26:15Z","2024-05-12T06:11:51Z",{"_163":148,"_164":148,"_165":148},"### 18 的新特性\n\n#### 新功能：自动批量处理\n\n批量处理是指 React 将多个状态更新分组到一个重新渲染中，以获得更好的性能。如果没有自动批量处理，我们只对 React 事件处理程序中的更新进行批量处理。默认情况下，React 不会对\nPromise、setTimeout、原生事件处理程序或任何其它事件中的更新进行批量处理。有了自动批量处理，这些更新将被自动的批量处理。\n\n```typescript jsx\n// 之前：只对 React 事件执行批量处理\nsetTimeout(() => {\n setCount(c => c + 1);\n setFlag(f => !f);\n // React 将渲染两次，每次状态更新一次（无批量处理）\n}, 1000);\n\n// 之后：超时、Promises、本机事件处理程序\n// 或任何其他事件内的更新是批处理的。\n\nsetTimeout(() => {\n setCount(c => c + 1);\n setFlag(f => !f);\n // React 只会在最终重新渲染一次（这就是批量处理！）\n}, 1000);\n```\n\n#### 新功能：过渡\n\n过渡是 React 中的一个新概念，用以区分紧急和非紧急更新。\n\n- 紧急更新反映了直接的交互，如输入、点击、按压等。\n- 过渡更新将 UI 从一个视图过渡到另一个。\n\n像输入、点击或按压这样的紧急更新，需要立即响应，以符合我们对物理对象行为方式的直觉。否则他们就会感到“不对劲儿”。然而，过渡是不同的，因为用户并不期望在屏幕上看到每个中间值。\n\n例如，当你在一个下拉菜单中选择一个过滤器时，你希望过滤器按钮本身在你点击时能立即做出反应。然而，实际结果可能会单独过渡。一个小的延迟将是难以察觉的，而且往往是预期的。并且，如果你在结果渲染完成之前再次改变过滤器，你只关心看到最新的结果。\n\n通常情况下，为了获得最佳的用户体验，一个用户输入应该同时导致一个紧急更新和一个非紧急更新。你可以在输入事件中使用 startTransition API 来告知 React 哪些是紧急更新，哪些是“过渡”：\n\n```typescript jsx\nimport { startTransition } from 'react';\n\n// 紧急：显示输入的内容\nsetInputValue(input);\n\n// 将内部的任何状态更新都标记为过渡\nstartTransition(() => {\n // 过渡：显示结果\n setSearchQuery(input);\n});\n```\n\n被 startTransition 包裹的更新被当作非紧急事件处理，如有更紧急更新，如点击或按键，则会被中断。如果一个过渡被用户中断（例如，连续输入多个字符），React 会丢弃未完成的无效的渲染，而只渲染最新的更新。\n\n- useTransition：一个启动过渡的 Hook，包括一个值以跟踪待定状态。\n- startTransition：当 Hook 不能使用时，一个启动过渡的方法。\n\n过渡将选择并发渲染，这允许更新被中断。如果内容重新挂起，过渡也会告诉 React 继续显示当前内容，同时在后台渲染过渡内容。\n\n#### 新的 Suspense 特性\n\n如果组件树的某一部分还没有准备好被显示，Suspense 可以让你声明式地指定加载状态：\n\n```typescript jsx\n}>\n \n\n```\n\nSuspense 使“UI 加载状态”成为 React 编程模型中的第一类声明式概念。这让我们可以在它上面建立更高层次的功能。\n\n几年前，我们推出了一个有限的 Suspense 版本。然而，唯一支持的用例是用 React.lazy 拆分代码，且在服务端渲染时根本不支持。\n\n在 React 18 中，我们增加了对服务端的 Suspense 支持，并使用并发渲染特性扩展了其功能。\n\nReact 18 中的 Suspense 在与过渡 API 结合时效果最好。如果你在过渡期间挂起，React 将防止已经可见的内容被回退取代。相反，React 会延迟渲染，直到有足够的数据加载，以防止出现糟糕的加载状态。\n\n#### 新的客户端、服务端渲染 API\n\n在这个版本中，我们借此机会重新设计了我们为在客户端和服务端渲染所暴露的 API。这些更改允许用户在升级到 React 18 中的新 API 时继续使用 React 17 模式下的旧 API。\n\n**React DOM Client**\n\n这些新的 API 现在从 react-dom/client 导出：\n\n- createRoot：新的创建根的方法，以进行 render 或 unmount。使用它替代 ReactDOM.render。没有它，React 18 的新功能就不能工作。\n- hydrateRoot：新的方法用以创建服务端渲染应用。使用它替代 ReactDOM.hydrate 与新的 React DOM 服务端 API 一起使用。没有它，React 18 的新功能就不能工作。\n\ncreateRoot 和 hydrateRoot 都接受一个新的选项，叫做 onRecoverableError，以防你想在 React render 或 hydrate 从错误恢复时得到通知，以便记录。默认情况下，React会使用\nreportError，或在较旧的浏览器中使用 console.error。\n\n**React DOM Server**\n\n这些新的 API 现在从 react-dom/server 导出，并且完全支持服务端的流式 Suspense：\n\n- renderToPipeableStream：用于 Node 环境下的 Stream。\n- renderToReadableStream：用于现代边缘运行环境，如 Deno 和 Cloudflare workers。\n\n现有的 renderToString 方法仍然可用，但不鼓励使用。\n\n#### 新的严格模式行为\n\n在未来，我们希望增加一个功能，允许 React 在保留状态的同时增加和删除部分的 UI。例如，当用户从一个屏幕切出并切回时，React 应该能够立即显示之前的屏幕。要做到这一点，React 将使用与之前相同的组件状态来卸载和重新装载树。\n\n这个功能将给 React 应用带来更好的开箱即用的性能，但需要组件对 effect 被多次装载和销毁具有弹性。大多数 effect 会正常工作而无需任何更改，但有些 effect 假设它们只被装载或销毁一次。\n\n为了帮助浮现这些问题，React 18 为严格模式引入了一个新的仅用于开发的检查。每当组件第一次装载时，此检查将自动卸载并重新装载每个组件，并在第二次装载时恢复先前的状态。\n\n在这个变化之前，React 会装载组件并创建 effect：\n\n```\n* React 装载组件\n * layout effect 创建\n * effect 创建\n```\n\n在 React 18 的严格模式下，React 会在开发模式下模拟卸载和重新装载组件：\n\n```\n* React 装载组件\n * layout effect 创建\n * effect 创建\n* React 模拟卸载组件\n * layout effect 销毁\n * effect 销毁\n* React 模拟装载组件（使用之前的状态）\n * layout effect 创建\n * effect 创建\n```\n\n#### 新的 Hook\n\n**useId**\n\nuseId 是一个新的 Hook，用于在客户端和服务端上生成唯一 ID，避免 hydrate 不匹配。它主要用于组件库，这些库集成了需要唯一 ID 的可访问性 API。这解决了 React 17 及更低版本中已经存在的问题，但在 React\n18 中更为重要，因为新的流式服务端渲染器对 HTML 的无序交付方式。\n\n**useTransition**\n\nuseTransition 和 startTransition 让你把一些状态更新标记为不紧急。其他状态更新在默认情况下被认为是紧急的。React\n将允许紧急的状态更新（例如，更新一个文本输入）中断非紧急的状态更新（例如，渲染一个搜索结果列表）。\n\n**useDeferredValue**\n\nuseDeferredValue 让你推迟重新渲染树的非紧急部分。它类似于 debounce，但与之相比有一些优势。它没有固定的时间延迟，React 会在第一次渲染反映在屏幕后立即尝试延迟渲染。延迟渲染是可中断的，它不会阻塞用户输入。\n\n**useSyncExternalStore**\n\nuseSyncExternalStore 是一个新的 Hook，它允许外部存储支持并发读取，通过强制更新到 store 以同步。在实现对外部数据源的订阅时，它消除了对 useEffect 的需求，并被推荐给任何与 React\n外部状态集成的库。\n\n**useInsertionEffect**\n\nuseInsertionEffect 是一个新的 Hook ，允许 CSS-in-JS 库解决在渲染中注入样式的性能问题。除非你已经建立了一个 CSS-in-JS 库，否则我们不希望你使用它。这个 Hook 将在 DOM 被变更后运行，但在\nlayout effect 读取新布局之前。这解决了一个在 React 17 及以下版本中已经存在的问题，但在 React 18 中更加重要，因为 React 在并发渲染时向浏览器让步，给它一个重新计算布局的机会。\n\n### Concurrent Mode（并发模式）\n\nConcurrent Mode（以下简称 CM）翻译叫并发模式，这个概念我们或许已经听过很多次了，实际上，在去年这个概念已经很成熟了，在 React 17 中就可以通过一些试验性的api开启 CM。\n\n并发模式可帮助应用保持响应，并根据用户的设备性能和网速进行适当的调整，该模式通过使渲染可中断来修复阻塞渲染限制。在 Concurrent 模式中，React 可以同时更新多个状态。\n\n说的太复杂可能有点拗口，总结一句话就是：**React 17 和 React 18 的区别就是：从同步不可中断更新变成了异步可中断更新。**\n\n为了更好的管理root节点，React 18 引入了一个新的 root API，新的 root API 还支持 new concurrent renderer（并发模式的渲染），它允许你进入concurrent mode（并发模式）。\n\n```jsx\n// React 17\nimport React from 'react';\nimport ReactDOM from 'react-dom';\nimport App from './App';\n\nconst root = document.getElementById('root')\n!;\n\nReactDOM.render(, root);\n\n// React 18\nimport React from 'react';\nimport ReactDOM from 'react-dom/client';\nimport App from './App';\n\nconst root = document.getElementById('root')\n!;\n\nReactDOM.createRoot(root).render();\n```\n\n在 React 18 中，提供了新的 root api，我们只需要把 render 升级成 createRoot(root).render() 就可以开启并发模式了。\n\n那么这个时候，可能有同学会提问：开启并发模式就是开启了并发更新么？\n\nNO！在 React 17 中一些实验性功能里面，开启并发模式就是开启了并发更新，但是在 React 18 正式版发布后，由于官方策略调整，React 不再依赖并发模式开启并发更新了。\n\n换句话说：**开启了并发模式，并不一定开启了并发更新！**\n\n一句话总结：**在 18 中，不再有多种模式，而是以是否使用并发特性作为是否开启并发更新的依据。**\n\n可以从架构角度来概括下，当前一共有两种架构：\n\n- 采用不可中断的递归方式更新的 `Stack Reconciler`（老架构）\n- 采用可中断的遍历方式更新的 `Fiber Reconciler`（新架构）\n\n新架构可以选择是否开启并发更新，所以当前市面上所有 React 版本有四种情况：\n\n- 老架构（v15及之前版本）\n- 新架构，未开启并发更新，与情况1行为一致（v16、v17 默认属于这种情况）\n- 新架构，未开启并发更新，但是启用了并发模式和一些新功能（比如 Automatic Batching，v18 默认属于这种情况）\n- 新架构，开启并发模式，开启并发更新\n\n**并发特性指开启并发模式后才能使用的特性**，比如：\n\n- useDeferredValue\n- useTransition\n\n![1](https://foruda.gitee.com/images/1682007325938364918/c6174e9f_7819612.png)\n\n#### startTransition 并发特性举例\n\n这个新的 API 可以通过将特定更新标记为“过渡”来显著改善用户交互，简单来说，就是被 startTransition 回调包裹的 setState 触发的渲染被标记为不紧急渲染，这些渲染可能被其他紧急渲染所抢占。\n\n```tsx\nimport React, { useState, useEffect, useTransition } from 'react';\n\nconst App: React.FC = () => {\n const [list, setList] = useState([]);\n const [isPending, startTransition] = useTransition();\n useEffect(() => {\n // 使用了并发特性，开启并发更新\n startTransition(() => {\n setList(new Array(10000).fill(null));\n });\n }, []);\n return (\n <>\n {list.map((_, i) => (\n

{i}

\n ))}\n \n );\n};\n\nexport default App;\n```\n\n#### useDeferredValue 并发特性举例\n\n从介绍上来看 useDeferredValue 与 useTransition 是否感觉很相似呢？\n\n相同：useDeferredValue 本质上和内部实现与 useTransition 一样，都是标记成了延迟更新任务。不同：useTransition 是把更新任务变成了延迟更新任务，而 useDeferredValue\n是产生一个新的值，这个值作为延时状态。（一个用来包装方法，一个用来包装值）\n\n所以，上面 startTransition 的例子，我们也可以用 useDeferredValue 来实现：\n\n```jsx\nimport React, { useState, useEffect, useDeferredValue } from 'react';\n\nconst App: React.FC = () => {\n const [list, setList] = useState < any[] > ([]);\n useEffect(() => {\n setList(new Array(10000).fill(null));\n }, []);\n // 使用了并发特性，开启并发更新\n const deferredList = useDeferredValue(list);\n return (\n <>\n {deferredList.map((_, i) => (\n

{i}

\n ))}\n \n );\n};\n\nexport default App;\n```\n\n此时我们的任务被拆分到每一帧不同的 task 中，JS脚本执行时间大体在5ms左右，这样浏览器就有剩余时间执行样式布局和样式绘制，减少掉帧的可能性。\n\n\n### setState 自动批处理\n\nReact 18 通过在默认情况下执行批处理来实现了开箱即用的性能改进。\n\n批处理是指为了获得更好的性能，在数据层，将多个状态更新批量处理，合并成一次更新（在视图层，将多个渲染合并成一次渲染）。\n\n#### 在 React 18 之前：有一些情况下并不会合并更新\n\n在React 18 之前，我们只在 React 事件处理函数中进行批处理更新。默认情况下，在 `promise、setTimeout、原生事件处理函数中`、或任`何其它事件内`的更新都不会进行批处理：\n\n**情况一：React 事件处理函数**\n\n下面的代码就会批量处理，只会渲染一次页面\n\n```typescript jsx\nimport React, { useState } from 'react';\n\n// React 18 之前\nconst App: React.FC = () => {\n console.log('App组件渲染了！');\n const [count1, setCount1] = useState(0);\n const [count2, setCount2] = useState(0);\n return (\n {\n setCount1(count => count + 1);\n setCount2(count => count + 1);\n // 在React事件中被批处理\n }}\n >\n {`count1 is ${count1}, count2 is ${count2}`}\n \n );\n};\n\nexport default App;\n```\n\n**情况二：setTimeout**\n\n如果我们把状态的更新放在`promise`或者`setTimeout`里面，组件都会渲染两次，不会进行批量更新。\n\n```typescript jsx\nimport React, { useState } from 'react';\n\n// React 18 之前\nconst App: React.FC = () => {\n console.log('App组件渲染了！');\n const [count1, setCount1] = useState(0);\n const [count2, setCount2] = useState(0);\n return (\n {\n setTimeout(() => {\n setCount1(count => count + 1);\n setCount2(count => count + 1);\n });\n // 在 setTimeout 中不会进行批处理\n }}\n >\n

count1： {count1}

count2： {count2}

\n \n );\n};\n\nexport default App;\n```\n\n**情况三：原生js事件**\n\n在原生js事件中，结果跟情况二是一样的，每次点击更新两个状态，组件都会渲染两次，不会进行批量更新。\n\n```typescript jsx\nimport React, { useEffect, useState } from 'react';\n\n// React 18 之前\nconst App: React.FC = () => {\n console.log('App组件渲染了！');\n const [count1, setCount1] = useState(0);\n const [count2, setCount2] = useState(0);\n useEffect(() => {\n document.body.addEventListener('click', () => {\n setCount1(count => count + 1);\n setCount2(count => count + 1);\n });\n // 在原生js事件中不会进行批处理\n }, []);\n return (\n <>\n

count1： {count1}

count2： {count2}

\n \n );\n};\n\nexport default App;\n```\n\n#### 在 React 18 中: 合并更新\n\n在 React 18 上面的三个例子只会有一次 render，因为所有的更新都将自动批处理。这样无疑是很好的提高了应用的整体性能。\n\n不过以下例子会在 React 18 中执行两次 render：\n\n```typescript jsx\nimport React, { useState } from 'react';\n\n// React 18\nconst App: React.FC = () => {\n console.log('App组件渲染了！');\n const [count1, setCount1] = useState(0);\n const [count2, setCount2] = useState(0);\n return (\n {\n await setCount1(count => count + 1);\n setCount2(count => count + 1);\n }}\n >\n

count1： {count1}

count2： {count2}

\n \n );\n};\n\nexport default App;\n```\n\n总结：\n\n- 在 18 之前，只有在react事件处理函数中，才会自动执行批处理，其它情况会多次更新\n- 在 18 之后，任何情况都会自动执行批处理，多次更新始终合并为一次\n\n### flushSync\n\n批处理是一个破坏性改动，如果你想退出批量更新，你可以使用 flushSync：\n\n```typescript jsx\nimport React, { useState } from 'react';\nimport { flushSync } from 'react-dom';\n\nconst App: React.FC = () => {\n const [count1, setCount1] = useState(0);\n const [count2, setCount2] = useState(0);\n return (\n {\n flushSync(() => {\n setCount1(count => count + 1);\n });\n // 第一次更新\n flushSync(() => {\n setCount2(count => count + 1);\n });\n // 第二次更新\n }}\n >\n

count1： {count1}

count2： {count2}

\n \n );\n};\n\nexport default App;\n```\n\n### 其他\n\n#### Suspense 不再需要 fallback 来捕获\n\n空的 fallback 属性的处理方式做了改变：不再跳过缺失值或值为null 的 fallback 的 Suspense 边界。\n\n**更新前**\n\n以前，如果你的 Suspense 组件没有提供 fallback 属性，React 就会悄悄跳过它，继续向上搜索下一个边界：\n\n```jsx\n// React 17\nconst App = () => {\n return (\n }> // <--- 这个边界被使用，显示 Loading 组件\n // <--- 这个边界被跳过，没有 fallback 属性\n \n \n \n );\n};\n\nexport default App;\n```\n\n**更新后**\n\n现在，React将使用当前组件的 Suspense 作为边界，即使当前组件的 Suspense 的值为 null 或 undefined：\n\n```jsx\n// React 18\nconst App = () => {\n return (\n }> // <--- 不使用\n // <--- 这个边界被使用，将 fallback 渲染为 null\n \n \n \n );\n};\n\nexport default App;\n```\n\n#### 关于 React 组件的返回值\n\n- 在 React 17 中，如果你需要返回一个空组件，React只允许返回null。如果你显式的返回了 undefined，控制台则会在运行时抛出一个错误。\n- 在 React 18 中，不再检查因返回 undefined 而导致崩溃。既能返回 null，也能返回 undefined（但是 React 18 的dts文件还是会检查，只允许返回 null，你可以忽略这个类型错误）。\n\n### 结论\n\n- 并发更新的意义就是交替执行不同的任务，当预留的时间不够用时，React 将线程控制权交还给浏览器，等待下一帧时间到来，然后继续被中断的工作\n- 并发模式是实现并发更新的基本前提\n- 时间切片是实现并发更新的具体手段\n\n\n### 参考文档\n\n- https://zh-hans.legacy.reactjs.org/blog/2022/03/29/react-v18.html\n- https://juejin.cn/post/7094037148088664078\n- https://juejin.cn/post/7027995169211285512\n",{"_54":682,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/299/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/299/timeline",{"_54":685,"_56":57,"_58":686,"_60":687,"_62":688,"_64":689,"_66":690,"_68":691,"_70":692,"_72":693,"_74":694,"_107":695,"_127":128,"_129":26,"_130":-5,"_131":697,"_133":698,"_155":148,"_149":700,"_151":701,"_154":-5,"_159":160,"_161":702,"_166":-5,"_167":703,"_169":704,"_181":706,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/295","https://api.github.com/repos/pro-collection/interview-question/issues/295/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/295/comments","https://api.github.com/repos/pro-collection/interview-question/issues/295/events","https://github.com/pro-collection/interview-question/issues/295",1671499521,"I_kwDOJGDC6c5joQ8B",295,"[React] forwardRef 作用是什么？【热度: 2,628】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[696],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":699,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-17T15:54:15Z","2023-04-18T01:34:07Z",{"_163":148,"_164":148,"_165":148},"`forwardRef` 是 React 提供的一个高阶函数，它可以让你在函数组件中访问子组件的 ref，并把该 ref 传递给子组件。\n\n使用 `forwardRef` 的主要场景是，当你需要访问子组件的 DOM 节点或实例时，比如要操作子组件的滚动条、聚焦输入框等等。在这些场景下，需要用到 `ref`，而 `ref` 又不能直接在函数组件中使用。\n\n下面是 `forwardRef` 的基本使用方式：\n\n```jsx\njsxCopy codeimport React, { forwardRef } from 'react';\n\nconst MyComponent = forwardRef((props, ref) => {\n return ;\n});\n\nfunction App() {\n const inputRef = React.createRef();\n\n const handleClick = () => {\n inputRef.current.focus();\n };\n\n return (\n

\n \n \n

\n );\n}\n```\n\n在上面的例子中，我们创建了一个 `MyComponent` 组件，并通过 `forwardRef` 来包裹它。这样，`MyComponent` 就可以在 props 中接收一个 `ref` 属性，而 `forwardRef` 将会将该属性转发到子组件中。\n\n在 `App` 组件中，我们创建了一个 `inputRef` 对象，并将它作为 `MyComponent` 的 `ref` 属性传递给了 `MyComponent` 组件。然后，我们在 `handleClick` 函数中使用 `inputRef` 来聚焦输入框。\n\n需要注意的是，`forwardRef` 的回调函数接收两个参数：`props` 和 `ref`。其中，`props` 是组件的属性对象，`ref` 是回调函数中定义的 ref 对象。在函数组件中，我们必须将 `ref` 传递给要访问的子组件，否则 `ref` 将无法访问到子组件的 DOM 节点或实例。",{"_54":705,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/295/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/295/timeline",{"_54":708,"_56":57,"_58":709,"_60":710,"_62":711,"_64":712,"_66":713,"_68":714,"_70":715,"_72":716,"_74":717,"_107":718,"_127":128,"_129":26,"_130":-5,"_131":720,"_133":721,"_155":156,"_149":723,"_151":724,"_154":-5,"_159":160,"_161":725,"_166":-5,"_167":726,"_169":727,"_181":729,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/290","https://api.github.com/repos/pro-collection/interview-question/issues/290/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/290/comments","https://api.github.com/repos/pro-collection/interview-question/issues/290/events","https://github.com/pro-collection/interview-question/issues/290",1670010423,"I_kwDOJGDC6c5jilY3",290,"[React] useState 是如何实现的？",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[719],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":722,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-16T15:08:27Z","2023-04-16T15:13:40Z",{"_163":148,"_164":148,"_165":148},"### hooks 的实现原理\r\n\r\n流程图如下：renderWithHooks 根据current来判断当前是首次渲染还是更新。 hooks加载时调用对应的mount函数，更新时调用对应的update函数。\r\nhooks生成单向链表，通过next连接，最后一个next指向null。 state hooks会生成update循环链表， effects会生成另外一个effectList循环链表。\r\n\r\n![image](https://user-images.githubusercontent.com/22188674/232322402-c4a5a5a0-feec-4bda-92b8-775cc4dfdb1a.png)\r\n\r\n### renderWithHooks\r\n\r\nreact-reconciler/src/ReactFiberHooks.js\r\n\r\n```jsx\r\n// renderWithHooks中判断是否是首次渲染\r\nfunction renderWithHooks(current, workInProgress, Component, props, nextRenderLanes) {\r\n\r\n //当前正在渲染的车道\r\n renderLanes = nextRenderLanes\r\n currentlyRenderingFiber = workInProgress;\r\n //函数组件更新队列里存的effect\r\n workInProgress.updateQueue = null;\r\n //函数组件状态存的hooks的链表\r\n workInProgress.memoizedState = null;\r\n //如果有老的fiber,并且有老的hook链表\r\n if (current !== null && current.memoizedState !== null) {\r\n ReactCurrentDispatcher.current = HooksDispatcherOnUpdate;\r\n } else {\r\n ReactCurrentDispatcher.current = HooksDispatcherOnMount;\r\n }\r\n\r\n//需要要函数组件执行前给ReactCurrentDispatcher.current赋值\r\n\r\n const children = Component(props);\r\n currentlyRenderingFiber = null;\r\n workInProgressHook = null;\r\n currentHook = null;\r\n renderLanes = NoLanes;\r\n return children;\r\n}\r\n```\r\n\r\n`HooksDispatcherOnMount和HooksDispatcherOnUpdate`对象分别存放hooks的挂载函数和更新函数\r\n\r\n### hooks的注册\r\n\r\n```typescript jsx\r\n\r\nfunction resolveDispatcher() {\r\n return ReactCurrentDispatcher.current;\r\n}\r\n\r\n/**\r\n *\r\n * @param {*} reducer 处理函数，用于根据老状态和动作计算新状态\r\n * @param {*} initialArg 初始状态\r\n */\r\n\r\nexport function useState(initialState) {\r\n const dispatcher = resolveDispatcher();\r\n return dispatcher.useState(initialState);\r\n}\r\n```\r\n\r\n![image](https://user-images.githubusercontent.com/22188674/232322419-c4db85f8-f162-40b7-84a5-affc349b9b82.png)\r\n\r\n```typescript jsx\r\n/**\r\n * 构建新的hooks，其主要作用是在 Fiber 树中遍历到某个组件时，\r\n * 根据该组件的类型和当前处理阶段（mount 或 update），处理该组件的 Hook 状态。\r\n */\r\nfunction updateWorkInProgressHook() {\r\n //获取将要构建的新的hook的老hook\r\n if (currentHook === null) {\r\n const current = currentlyRenderingFiber.alternate;\r\n currentHook = current.memoizedState;\r\n } else {\r\n currentHook = currentHook.next;\r\n }\r\n //根据老hook创建新hook\r\n const newHook = {\r\n memoizedState: currentHook.memoizedState,\r\n queue: currentHook.queue,\r\n next: null,\r\n baseState: currentHook.baseState,\r\n baseQueue: currentHook.baseQueue\r\n }\r\n if (workInProgressHook === null) {\r\n currentlyRenderingFiber.memoizedState = workInProgressHook = newHook;\r\n } else {\r\n workInProgressHook = workInProgressHook.next = newHook;\r\n }\r\n return workInProgressHook;\r\n}\r\n\r\n```\r\n\r\n### useState 实现\r\n\r\n接收一个初始状态值，返回一个数组，包含当前状态值和更新状态值的方法。可以通过调用更新方法来改变状态值，并触发组件的重新渲染\r\n\r\n```typescript\r\n//useState其实就是一个内置了reducer的useReducer\r\n\r\n/**\r\n * hook的属性\r\n * hook.memoizedState 当前 hook真正显示出来的状态\r\n * hook.baseState 第一个跳过的更新之前的老状态\r\n * hook.queue.lastRenderedState 上一个计算的状态\r\n */\r\n\r\nfunction mountState(initialState) {\r\n const hook = mountWorkInProgressHook();\r\n hook.memoizedState = hook.baseState = initialState;\r\n const queue = {\r\n pending: null,\r\n dispatch: null,\r\n lastRenderedReducer: baseStateReducer,//上一个reducer\r\n lastRenderedState: initialState//上一个state\r\n }\r\n hook.queue = queue;\r\n const dispatch = (queue.dispatch = dispatchSetState.bind(null, currentlyRenderingFiber, queue));\r\n return [hook.memoizedState, dispatch];\r\n}\r\n\r\nfunction dispatchSetState(fiber, queue, action) {\r\n // 获取当前的更新赛道 1\r\n const lane = requestUpdateLane();\r\n const update = {\r\n lane,//本次更新优先级就是1\r\n action,\r\n hasEagerState: false,//是否有急切的更新\r\n eagerState: null,//急切的更新状态\r\n next: null\r\n }\r\n const alternate = fiber.alternate;\r\n\r\n //当你派发动作后，我立刻用上一次的状态和上一次的reducer计算新状态\r\n //只要第一个更新都能进行此项优化\r\n if (fiber.lanes === NoLanes && (alternate === null || alternate.lanes == NoLanes)) {\r\n //先获取队列上的老的状态和老的reducer\r\n const { lastRenderedReducer, lastRenderedState } = queue;\r\n //使用上次的状态和上次的reducer结合本次action进行计算新状态\r\n const eagerState = lastRenderedReducer(lastRenderedState, action);\r\n update.hasEagerState = true;\r\n update.eagerState = eagerState;\r\n if (Object.is(eagerState, lastRenderedState)) {\r\n return;\r\n }\r\n }\r\n //下面是真正的入队更新，并调度更新逻辑\r\n const root = enqueueConcurrentHookUpdate(fiber, queue, update, lane);\r\n const eventTime = requestEventTime();\r\n scheduleUpdateOnFiber(root, fiber, lane, eventTime);\r\n}\r\n\r\n//useState其实就是一个内置了reducer的useReducer\r\nfunction baseStateReducer(state, action) {\r\n return typeof action === 'function' ? action(state) : action;\r\n}\r\n\r\nfunction updateState(initialState) {\r\n return updateReducer(baseStateReducer, initialState);\r\n}\r\n\r\nfunction updateReducer(reducer) {\r\n const hook = updateWorkInProgressHook();\r\n const queue = hook.queue;\r\n queue.lastRenderedReducer = reducer;\r\n const current = currentHook;\r\n let baseQueue = current.baseQueue;\r\n const pendingQueue = queue.pending;\r\n\r\n //把新旧更新链表合并\r\n if (pendingQueue !== null) {\r\n if (baseQueue !== null) {\r\n const baseFirst = baseQueue.next;\r\n const pendingFirst = pendingQueue.next;\r\n baseQueue.next = pendingFirst;\r\n pendingQueue.next = baseFirst;\r\n }\r\n current.baseQueue = baseQueue = pendingQueue;\r\n queue.pending = null;\r\n }\r\n if (baseQueue !== null) {\r\n const first = baseQueue.next;\r\n let newState = current.baseState;\r\n let newBaseState = null;\r\n let newBaseQueueFirst = null;\r\n let newBaseQueueLast = null;\r\n let update = first;\r\n do {\r\n const updateLane = update.lane;\r\n const shouldSkipUpdate = !isSubsetOfLanes(renderLanes, updateLane);\r\n if (shouldSkipUpdate) {\r\n const clone = {\r\n lane: updateLane,\r\n action: update.action,\r\n hasEagerState: update.hasEagerState,\r\n eagerState: update.eagerState,\r\n next: null,\r\n };\r\n\r\n // 省略部分代码\r\n\r\n hook.memoizedState = newState;\r\n hook.baseState = newBaseState;\r\n hook.baseQueue = newBaseQueueLast;\r\n queue.lastRenderedState = newState;\r\n }\r\n if (baseQueue === null) {\r\n queue.lanes = NoLanes;\r\n }\r\n const dispatch = queue.dispatch;\r\n return [hook.memoizedState, dispatch];\r\n }\r\n```\r\n\r\n### 参考文档\r\n- https://juejin.cn/post/6844903981836140552\r\n- https://juejin.cn/post/7219129726078533693\r\n",{"_54":728,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/290/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/290/timeline",{"_54":731,"_56":57,"_58":732,"_60":733,"_62":734,"_64":735,"_66":736,"_68":737,"_70":738,"_72":739,"_74":740,"_107":741,"_127":128,"_129":26,"_130":-5,"_131":748,"_133":749,"_155":148,"_149":751,"_151":752,"_154":-5,"_159":160,"_161":753,"_166":-5,"_167":754,"_169":755,"_181":757,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/286","https://api.github.com/repos/pro-collection/interview-question/issues/286/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/286/comments","https://api.github.com/repos/pro-collection/interview-question/issues/286/events","https://github.com/pro-collection/interview-question/issues/286",1669976171,"I_kwDOJGDC6c5jidBr",286,"[React] 父组件调用子组件的方法",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[742,743],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":744,"_68":745,"_54":746,"_113":747,"_115":125,"_117":26,"_118":126},5312726360,"LA_kwDOJGDC6c8AAAABPKnFWA","https://api.github.com/repos/pro-collection/interview-question/labels/%E8%85%BE%E8%AE%AF","腾讯",[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":750,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-16T13:45:21Z","2023-04-16T13:45:22Z",{"_163":148,"_164":148,"_165":148},"在React中，我们经常在子组件中调用父组件的方法，一般用props回调即可。但是有时候也需要在父组件中调用子组件的方法，通过这种方法实现高内聚。有多种方法，请按需服用。\n\n### 类组件中\n\n#### React.createRef()\n\n* 优点：通俗易懂，用ref指向。\n\n* 缺点：使用了HOC的子组件不可用，无法指向真是子组件\n\n 比如一些常用的写法，mobx的@observer包裹的子组件就不适用此方法。\n\n```scala\nimport React, { Component } from 'react';\n\nclass Sub extends Component {\n callback() {\n console.log('执行回调');\n }\n render() {\n return

子组件

;\n }\n}\n\nclass Super extends Component {\n constructor(props) {\n super(props);\n this.sub = React.createRef();\n }\n handleOnClick() {\n this.sub.callback();\n }\n render() {\n return (\n

\n \n

\n );\n }\n}\n\n\n```\n\n#### ref的函数式声明\n\n* 优点：ref写法简洁\n* 缺点：使用了HOC的子组件不可用，无法指向真是子组件（同上）\n\n使用方法和上述的一样，就是定义ref的方式不同。\n\n```csharp\n...\n\n_{this.sub = ref}>}\n\n...\n\n\n```\n\n#### 使用props自定义onRef属性\n\n* 优点：假如子组件是嵌套了HOC，也可以指向真实子组件。\n* 缺点：需要自定义props属性\n\n```typescript\nimport React, { Component } from 'react';\nimport { observer } from 'mobx-react'\n\n@observer\nclass Sub extends Component {\n\tcomponentDidMount(){\n // 将子组件指向父组件的变量\n\t\tthis.props.onRef && this.props.onRef(this);\n\t}\n\tcallback(){\n\t\tconsole.log(\"执行我\")\n\t}\n\trender(){\n\t\treturn (

子组件

);\n\t}\n}\n\nclass Super extends Component {\n\thandleOnClick(){\n // 可以调用子组件方法\n\t\tthis.Sub.callback();\n\t}\n\trender(){\n\t\treturn (\n

\n\t\t\t

click

\n\t\t\t_{this.Sub = node }>}\n\t \t

)\n\t}\n}\n\n\n```\n\n### 函数组件、Hook组件\n\n#### useImperativeHandle\n\n* 优点： 1、写法简单易懂 2、假如子组件嵌套了HOC，也可以指向真实子组件\n* 缺点： 1、需要自定义props属性 2、需要自定义暴露的方法\n\n```javascript\nimport React, { useImperativeHandle } from 'react';\nimport { observer } from 'mobx-react'\n\n\nconst Parent = () => {\n let ChildRef = React.createRef();\n\n function handleOnClick() {\n ChildRef.current.func();\n }\n\n return (\n

\n \n \n

\n );\n};\n\nconst Child = observer(props => {\n //用useImperativeHandle暴露一些外部ref能访问的属性\n useImperativeHandle(props.onRef, () => {\n // 需要将暴露的接口返回出去\n return {\n func: func,\n };\n });\n function func() {\n console.log('执行我');\n }\n return

子组件

;\n});\n\nexport default Parent;\n\n```\n\n#### forwardRef\n\n使用forwardRef抛出子组件的ref\n\n这个方法其实更适合自定义HOC。但问题是，withRouter、connect、Form.create等方法并不能抛出ref，假如Child本身就需要嵌套这些方法，那基本就不能混着用了。forwardRef本身也是用来抛出子元素，如input等原生元素的ref的，并不适合做组件ref抛出，因为组件的使用场景太复杂了。\n\n```javascript\nimport React, { useRef, useImperativeHandle } from 'react';\nimport ReactDOM from 'react-dom';\nimport { observer } from 'mobx-react'\n\nconst FancyInput = React.forwardRef((props, ref) => {\n const inputRef = useRef();\n useImperativeHandle(ref, () => ({\n focus: () => {\n inputRef.current.focus();\n }\n }));\n\n return \n});\n\nconst Sub = observer(FancyInput)\n\nconst App = props => {\n const fancyInputRef = useRef();\n\n return (\n

\n \n fancyInputRef.current.focus()}\n >父组件调用子组件的 focus\n

\n )\n}\n\nexport default App;\n\n\n```\n\n### 总结\n\n父组件调子组件函数有两种情况\n\n* 子组件无HOC嵌套：推荐使用ref直接调用\n* 有HOC嵌套：推荐使用自定义props的方式\n",{"_54":756,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/286/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/286/timeline",{"_54":759,"_56":57,"_58":760,"_60":761,"_62":762,"_64":763,"_66":764,"_68":765,"_70":766,"_72":767,"_74":768,"_107":769,"_127":128,"_129":26,"_130":-5,"_131":772,"_133":773,"_155":148,"_149":775,"_151":776,"_154":-5,"_159":160,"_161":777,"_166":-5,"_167":778,"_169":779,"_181":781,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/285","https://api.github.com/repos/pro-collection/interview-question/issues/285/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/285/comments","https://api.github.com/repos/pro-collection/interview-question/issues/285/events","https://github.com/pro-collection/interview-question/issues/285",1666757233,"I_kwDOJGDC6c5jWLJx",285,"[React] Hooks 实现原理是什么, 简单描述一下",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[770,771],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":121,"_68":122,"_54":123,"_113":124,"_115":125,"_117":26,"_118":126},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":774,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-13T16:38:09Z","2023-08-20T08:02:17Z",{"_163":148,"_164":148,"_165":148},"在探索 useEffect 原理的时候，一直被一个问题困扰：useEffect 作用和用途是什么？当然，用于函数的副作用这句话谁都会讲。举个例子吧：\n\n```typescript jsx\nfunction App() {\n const [num, setNum] = useState(0);\n\n useEffect(() => {\n // 模拟异步请求后端数据\n setTimeout(() => {\n setNum(num + 1);\n }, 1000);\n }, []);\n\n return

{!num ? \"请求后端数据...\" : `后端数据是 ${num}`}

;\n}\n```\n\n这段代码，虽然这样组织可读性更高，毕竟可以将这个请求理解为函数的副作用。**但这并不是必要的**。完全可以不使用`useEffect`，直接使用`setTimeout`，并且它的回调函数中更新函数组件的 state。\n\n在 useEffect 的第二个参数中，我们可以指定一个数组，如果下次渲染时，数组中的元素没变，那么就不会触发这个副作用（可以类比 Class 类的关于 nextprops 和 prevProps 的生命周期）。好处显然易见，**相比于直接裸写在函数组件顶层，useEffect 能根据需要，避免多余的 render**。\n\n下面是一个不包括销毁副作用功能的 useEffect 的 TypeScript 实现：\n\n```ini\n// 还是利用 Array + Cursor的思路\nconst allDeps: any[][] = [];\nlet effectCursor: number = 0;\n\nfunction useEffect(callback: () => void, deps: any[]) {\n if (!allDeps[effectCursor]) {\n // 初次渲染：赋值 + 调用回调函数\n allDeps[effectCursor] = deps;\n ++effectCursor;\n callback();\n return;\n }\n\n const currenEffectCursor = effectCursor;\n const rawDeps = allDeps[currenEffectCursor];\n // 检测依赖项是否发生变化，发生变化需要重新render\n const isChanged = rawDeps.some(\n (dep: any, index: number) => dep !== deps[index]\n );\n if (isChanged) {\n callback();\n allDeps[effectCursor] = deps; // 感谢 juejin@carlzzz 的指正\n }\n ++effectCursor;\n}\n\nfunction render() {\n ReactDOM.render(, document.getElementById(\"root\"));\n effectCursor = 0; // 注意将 effectCursor 重置为0\n}\n\n```\n\n对于 useEffect 的实现，配合下面案例的使用会更容易理解。当然，你也可以在这个 useEffect 中发起异步请求，并在接受数据后，调用 state 的更新函数，不会发生爆栈的情况。\n\n```typescript jsx\nfunction App() {\n const [num, setNum] = useState < number > 0;\n const [num2] = useState < number > 1;\n\n // 多次触发\n // 每次点击按钮，都会触发 setNum 函数\n // 副作用检测到 num 变化，会自动调用回调函数\n useEffect(() => {\n console.log(\"num update: \", num);\n }, [num]);\n\n // 仅第一次触发\n // 只会在compoentDidMount时，触发一次\n // 副作用函数不会多次执行\n useEffect(() => {\n console.log(\"num2 update: \", num2);\n }, [num2]);\n\n return (\n

num: {num}

\n \n \n

\n );\n}\n\n```\n\nuseEffect 第一个回调函数可以返回一个用于销毁副作用的函数，相当于 Class 组件的 unmount 生命周期。这里为了方便说明，没有进行实现。\n\n参考文档：\n- https://juejin.cn/post/6844903975838285838\n",{"_54":780,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/285/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/285/timeline",{"_54":783,"_56":57,"_58":784,"_60":785,"_62":786,"_64":787,"_66":788,"_68":789,"_70":790,"_72":791,"_74":792,"_107":793,"_127":128,"_129":26,"_130":-5,"_131":796,"_133":797,"_155":148,"_149":799,"_151":800,"_154":-5,"_159":160,"_161":801,"_166":-5,"_167":802,"_169":803,"_181":805,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/277","https://api.github.com/repos/pro-collection/interview-question/issues/277/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/277/comments","https://api.github.com/repos/pro-collection/interview-question/issues/277/events","https://github.com/pro-collection/interview-question/issues/277",1662739503,"I_kwDOJGDC6c5jG2Qv",277,"[Vue] watch 和 computed 的区别和理解",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[794,795],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":744,"_68":745,"_54":746,"_113":747,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":798,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-11T15:23:05Z","2023-04-11T15:23:06Z",{"_163":148,"_164":148,"_165":148},"**计算属性computed :**\n\n1. 支持缓存，只有依赖数据发生改变，才会重新进行计算，计算属性可用于快速计算视图（View）中显示的属性。这些计算将被缓存，并且只在需要时更新。computed是计算属性的; 它会根据所依赖的数据动态显示新的计算结果, 该计算结果会被缓存起来。computed的值在getter执行后是会被缓存的。如果所依赖的数据发生改变时候, 就会重新调用getter来计算最新的结果。\n\n2. 不支持异步，当computed内有异步操作时无效，无法监听数据的变化\n\n3. computed 属性值会默认走缓存，计算属性是基于它们的响应式依赖进行缓存的，也就是基于data中声明过或者父组件传递的props中的数据通过计算得到的值\n\n4. 如果一个属性是由其他属性计算而来的，这个属性依赖其他属性，是一个多对一或者一对一，一般用computed\n\n5. 如果computed属性属性值是函数，那么默认会走get方法；函数的返回值就是属性的属性值；在computed中的，属性都有一个get和一个set方法，当数据变化时，调用set方法。\n\n6. 适用于一些重复使用数据或复杂及费时的运算。我们可以把它放入computed中进行计算, 然后会在computed中缓存起来, 下次就可以直接获取了。\n\n7. 如果我们需要的数据依赖于其他的数据的话, 我们可以把该数据设计为computed中。\n\n8. computed 是基于响应性依赖来进行缓存的。只有在响应式依赖发生改变时它们才会重新求值, 也就是说, 当msg属性值没有发生改变时, 多次访问 reversedMsg 计算属性会立即返回之前缓存的计算结果, 而不会再次执行computed中的函数。但是methods方法中是每次调用, 都会执行函数的, methods它不是响应式的。\n\n9. computed中的成员可以只定义一个函数作为只读属性, 也可以定义成 get/set变成可读写属性, 但是methods中的成员没有这样的。\n\n\n**侦听属性watch：**\n\n1.watch它是一个对data的数据监听回调, 当依赖的data的数据变化时, 会执行回调。在回调中会传入newVal和oldVal两个参数。Vue实列将会在实例化时调用$watch(), 他会遍历watch对象的每一个属性。watch的使用场景是：当在data中的某个数据发生变化时, 我们需要做一些操作, 或者当需要在数据变化时执行异步或开销较大的操作时. 我们就可以使用watch来进行监听。watch普通监听和深度监听不支持缓存，数据变，直接会触发相应的操作；\n\n2.watch里面有一个属性为deep，含义是：是否深度监听某个对象的值, 该值默认为false。watch支持异步；\n\n3.监听的函数接收两个参数，第一个参数是最新的值；第二个参数是输入之前的值；\n\n4.当一个属性发生变化时，需要执行对应的操作；一对多；\n\n5.监听数据必须是data中声明过或者父组件传递过来的props中的数据，当数据变化时，触发其他操作，函数有两个参数，\n\n**watch 和 computed的区别是：**\n\n相同点：他们两者都是观察页面数据变化的。\n\n不同点：computed只有当依赖的数据变化时才会计算, 当数据没有变化时, 它会读取缓存数据。 watch每次都需要执行函数。watch更适用于数据变化时的异步操作。\n\n当需要在数据变化时执行异步或开销较大的操作时，这个方式是最有用的。这是和computed最大的区别，请勿滥用。\n",{"_54":804,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/277/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/277/timeline",{"_54":807,"_56":57,"_58":808,"_60":809,"_62":810,"_64":811,"_66":812,"_68":813,"_70":814,"_72":815,"_74":816,"_107":817,"_127":128,"_129":26,"_130":-5,"_131":820,"_133":821,"_155":148,"_149":823,"_151":824,"_154":-5,"_159":160,"_161":825,"_166":-5,"_167":826,"_169":827,"_181":829,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/272","https://api.github.com/repos/pro-collection/interview-question/issues/272/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/272/comments","https://api.github.com/repos/pro-collection/interview-question/issues/272/events","https://github.com/pro-collection/interview-question/issues/272",1659780547,"I_kwDOJGDC6c5i7j3D",272,"[Vue] vue3 的响应式库是独立出来的，它单独使用的时候是什么效果",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[818,819],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":744,"_68":745,"_54":746,"_113":747,"_115":125,"_117":26,"_118":126},[],{"_54":456,"_64":457,"_58":458,"_66":459,"_68":460,"_70":461,"_72":462,"_118":463,"_143":822,"_145":465,"_147":148,"_127":128,"_149":466,"_151":467,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-09T07:23:25Z","2023-04-09T07:23:26Z",{"_163":148,"_164":148,"_165":148},"vue3 的响应式库是独立出来的，它可以很方便的集成进 React，作为 React 的状态管理库使用！\n\n### 使用示范\n定义 store\n```typescript\n// store.ts\nimport { reactive, computed, effect } from '@vue/reactivity';\n\nexport const state = reactive({\n count: 0,\n});\n\nconst plusOne = computed(() => state.count + 1);\n\neffect(() => {\n console.log('plusOne changed: ', plusOne);\n});\n\nconst add = () => (state.count += 1);\n\nexport const mutations = {\n // mutation\n add,\n};\n\nexport const store = {\n state,\n computed: {\n plusOne,\n },\n};\n\nexport type Store = typeof store;\n```\n\n消费使用\n```js\n// Index.tsx\nimport { Provider, useStore } from 'rxv'\nimport { mutations, store, Store } from './store.ts'\nfunction Count() {\n const countState = useStore((store: Store) => {\n const { state, computed } = store;\n const { count } = state;\n const { plusOne } = computed;\n\n return {\n count,\n plusOne,\n };\n });\n\n return (\n \n

计数器

store中的count现在是 {countState.count}

computed值中的plusOne现在是 {countState.plusOne.value}

\n \n

\n \n );\n}\n\nexport default () => {\n return (\n \n \n \n );\n};\n```\n\n可以看出，store的定义只用到了@vue/reactivity，而rxv只是在组件中做了一层桥接，连通了Vue3和React，正如它名字的含义：React x Vue。\n\n### 如何实现\n只要effect能接入到React系统中，那么其他的api都没什么问题，因为它们只是去收集effect的依赖，去通知effect触发更新。\n\neffect接受的是一个函数，而且effect还支持通过传入schedule参数来自定义依赖更新的时候需要触发什么函数，\n\n而rxv的核心api: useStore接受的也是一个函数selector，它会让用户自己选择在组件中需要访问的数据。\n\n把selector包装在effect中执行，去收集依赖。\n\n指定依赖发生更新时，需要调用的函数是当前正在使用useStore的这个组件的forceUpdate强制渲染函数。\n\n简单的看一下核心实现\n\nshare.ts\n```typescript\nexport const useForceUpdate = () => {\n const [, forceUpdate] = useReducer(s => s + 1, 0);\n return forceUpdate;\n};\n\nexport const useEffection = (...effectArgs: Parameters) => {\n // 用一个ref存储effection\n // effect函数只需要初始化执行一遍\n const effectionRef = useRef();\n if (!effectionRef.current) {\n effectionRef.current = effect(...effectArgs);\n }\n\n // 卸载组件后取消effect\n const stopEffect = () => {\n stop(effectionRef.current!);\n };\n useEffect(() => stopEffect, []);\n\n return effectionRef.current\n};\n```\n\n核心逻辑在此\n```typescript\nimport React, { useContext } from 'react';\nimport { useForceUpdate, useEffection } from './share';\n\ntype Selector = (store: T) => S;\n\nconst StoreContext = React.createContext(null);\n\nconst useStoreContext = () => {\n const contextValue = useContext(StoreContext);\n if (!contextValue) {\n throw new Error(\n 'could not find store context value; please ensure the component is wrapped in a ',\n );\n }\n return contextValue;\n};\n\n/**\n * 在组件中读取全局状态\n * 需要通过传入的函数收集依赖\n */\nexport const useStore = (selector: Selector): S => {\n const forceUpdate = useForceUpdate();\n const store = useStoreContext();\n\n const effection = useEffection(() => selector(store), {\n scheduler: job => {\n if (job() === undefined) return;\n forceUpdate();\n },\n lazy: true,\n });\n\n const value = effection();\n return value;\n};\n\nexport const Provider = StoreContext.Provider;\n```\n\n参考文档：\n- https://github.com/sl1673495/react-composition-api\n- https://juejin.cn/post/6844904054192078855\n",{"_54":828,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/272/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/272/timeline",{"_54":831,"_56":57,"_58":832,"_60":833,"_62":834,"_64":835,"_66":836,"_68":837,"_70":838,"_72":839,"_74":840,"_107":841,"_127":128,"_129":26,"_130":-5,"_131":844,"_133":845,"_155":148,"_149":847,"_151":848,"_154":-5,"_159":160,"_161":849,"_166":-5,"_167":850,"_169":851,"_181":853,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/271","https://api.github.com/repos/pro-collection/interview-question/issues/271/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/271/comments","https://api.github.com/repos/pro-collection/interview-question/issues/271/events","https://github.com/pro-collection/interview-question/issues/271",1659775681,"I_kwDOJGDC6c5i7irB",271,"[Vue] Vue3 的响应式原理?",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[842,843],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":744,"_68":745,"_54":746,"_113":747,"_115":125,"_117":26,"_118":126},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":846,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-09T07:02:57Z","2023-04-09T07:02:58Z",{"_163":148,"_164":148,"_165":148},"### 该话题涉及的相关内容\n\n- 原理：Proxy、track、trigger\n- 新增属性\n- 遍历后新增\n- 遍历后删除或者清空\n- 获取 keys\n- 删除对象属性\n- 判断属性是否存在\n- 性能\n\n推荐阅读文档： https://juejin.cn/post/6844904122479542285\n\n### 响应式仓库\n\nVue3 不同于 Vue2 也体现在源码结构上，Vue3 把耦合性比较低的包分散在 `packages` 目录下单独发布成 `npm` 包。这也是目前很流行的一种大型项目管理方式 `Monorepo`。\n\n其中负责响应式部分的仓库就是 `@vue/reactivity`，它不涉及 Vue 的其他的任何部分，是非常非常「正交」的一种实现方式。\n\n甚至可以`轻松的集成进 React` https://juejin.cn/post/6844904095594381325\n\n### 区别\n\nProxy 和 Object.defineProperty 的使用方法看似很相似，其实 Proxy 是在「更高维度」上去拦截属性的修改的，怎么理解呢？\n\nVue2 中，对于给定的 data，如 `{ count: 1 }`，是需要根据具体的 key 也就是 `count`，去对「修改 data.count 」和「读取 data.count」进行拦截，也就是\n\n```javascript\nObject.defineProperty(data, 'count', {\n get() {},\n set() {},\n})\n```\n\n必须预先知道要拦截的 key 是什么，这也就是为什么 Vue2 里对于对象上的新增属性无能为力。\n\n而 Vue3 所使用的 Proxy，则是这样拦截的：\n\n```javascript\nnew Proxy(data, {\n get(key) { },\n set(key, value) { },\n})\n\n```\n\n可以看到，根本不需要关心具体的 key，它去拦截的是「修改 data 上的任意 key」和「读取 data 上的任意 key」。\n\n所以，不管是已有的 key 还是新增的 key，都逃不过它的魔爪。\n\n但是 Proxy 更加强大的地方还在于 Proxy 除了 get 和 set，还可以拦截更多的操作符。\n\n### 简单的例子🌰\n\n先写一个 Vue3 响应式的最小案例，本文的相关案例都只会用 `reactive` 和 `effect` 这两个 api。如果你了解过 React 中的 `useEffect`，相信你会对这个概念秒懂，Vue3 的 `effect` 不过就是去掉了手动声明依赖的「进化版」的 `useEffect`。\n\nReact 中手动声明 `[data.count]` 这个依赖的步骤被 Vue3 内部直接做掉了，在 `effect` 函数内部读取到 `data.count` 的时候，它就已经被收集作为依赖了。\n\nVue3：\n\n```kotlin\n// 响应式数据\nconst data = reactive({\n count: 1\n})\n\n// 观测变化\neffect(() => console.log('count changed', data.count))\n\n// 触发 console.log('count changed', data.count) 重新执行\ndata.count = 2\n\n```\n\nReact：\n\n```scss\n// 数据\nconst [data, setData] = useState({\n count: 1\n})\n\n// 观测变化需要手动声明依赖\nuseEffect(() => {\n console.log('count changed', data.count)\n}, [data.count])\n\n// 触发 console.log('count changed', data.count) 重新执行\nsetData({\n count: 2\n})\n\n```\n\n也可以把 `effect` 中的回调函数联想到视图的重新渲染、 watch 的回调函数等等…… 它们是同样基于这套响应式机制的。\n\n而本文的核心目的，就是探究这个基于 Proxy 的 reactive api，到底能强大到什么程度，能监听到用户对于什么程度的修改。\n\n### 讲讲原理\n\n先最小化的讲解一下响应式的原理，其实就是在 Proxy 第二个参数 `handler` 也就是陷阱操作符中，拦截各种取值、赋值操作，依托 `track` 和 `trigger` 两个函数进行依赖收集和派发更新。\n\n`track` 用来在读取时收集依赖。\n\n`trigger` 用来在更新时触发依赖。\n\n### track\n\n```vbnet\nfunction track(target: object, type: TrackOpTypes, key: unknown) {\n const depsMap = targetMap.get(target);\n // 收集依赖时通过 key 建立一个 set\n let dep = new Set()\n targetMap.set(ITERATE_KEY, dep)\n // 这个 effect 可以先理解为更新函数存放在 dep 里\n dep.add(effect)\n}\n\n```\n\n`target` 是原对象。\n\n`type` 是本次收集的类型，也就是收集依赖的时候用来标识是什么类型的操作，比如上文依赖中的类型就是 `get`，这个后续会详细讲解。\n\n`key` 是指本次访问的是数据中的哪个 key，比如上文例子中收集依赖的 key 就是 `count`\n\n首先全局会存在一个 `targetMap`，它用来建立 `数据 -> 依赖` 的映射，它是一个 WeakMap 数据结构。\n\n而 `targetMap` 通过数据 `target`，可以获取到 `depsMap`，它用来存放这个数据对应的所有响应式依赖。\n\n`depsMap` 的每一项则是一个 Set 数据结构，而这个 Set 就存放着对应 key 的更新函数。\n\n是不是有点绕？我们用一个具体的例子来举例吧。\n\n```ini\nconst target = { count: 1}\nconst data = reactive(target)\n\nconst effection = effect(() => {\n console.log(data.count)\n})\n\n```\n\n对于这个例子的依赖关系，\n\n1. 全局的 `targetMap` 是：\n\n```js\ntargetMap: {\n { count: 1 }: dep\n}\n\n```\n\n2. dep 则是\n\n```js\ndep: {\n count: Set { effection }\n}\n\n```\n\n这样一层层的下去，就可以通过 `target` 找到 `count` 对应的更新函数 `effection` 了。\n\n### trigger\n\n这里是最小化的实现，仅仅为了便于理解原理，实际上要复杂很多，\n\n其实 `type` 的作用很关键，先记住，后面会详细讲。\n\n```typescript\nexport function trigger(\n target: object,\n type: TriggerOpTypes,\n key?: unknown,\n) {\n // 简化来说就是通过 key 找到所有更新函数依次执行\n const dep = targetMap.get(target)\n dep.get(key).forEach(effect => effect())\n}\n```\n",{"_54":852,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/271/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/271/timeline",{"_54":855,"_56":57,"_58":856,"_60":857,"_62":858,"_64":859,"_66":860,"_68":861,"_70":862,"_72":863,"_74":864,"_107":865,"_127":128,"_129":26,"_130":-5,"_131":868,"_133":869,"_155":148,"_149":871,"_151":872,"_154":-5,"_159":160,"_161":873,"_166":-5,"_167":874,"_169":875,"_181":877,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/269","https://api.github.com/repos/pro-collection/interview-question/issues/269/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/269/comments","https://api.github.com/repos/pro-collection/interview-question/issues/269/events","https://github.com/pro-collection/interview-question/issues/269",1659765940,"I_kwDOJGDC6c5i7gS0",269,"前端路由的实现原理",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[866,867],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":744,"_68":745,"_54":746,"_113":747,"_115":125,"_117":26,"_118":126},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":870,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-09T06:18:33Z","2023-04-09T06:18:34Z",{"_163":148,"_164":148,"_165":148},"在使用Vue、React等前端框架时，我们都会发现项目中只有一个HTML文件，并且在该HTML中都存在一个根标签，起到了类似于容器的作用。容器内部的内容就由我们后续编写的每个视图决定，页面的切换就是容器中视图的切换。\n\n前端路由的实现原理简单来说，就是在不跳转或者刷新页面的前提下，为SPA应用中的每个视图匹配一个特殊的URL，之后的刷新、前进、后退等操作均通过这个特殊的URL实现。为实现上述要求，需要满足：\n\n改变URL且不会向服务器发起请求；\n\n可以监听到URL的变化，并渲染与之匹配的视图。\n\n主要有Hash路由和History路由两种实现方式。下文对两者的基本原理进行简单介绍，并分别实现了一个简易的路由Demo。\n\n### Hash路由\n原理就是通过键值对的形式保存路由及对应要执行的回调函数，当监听到页面hash发生改变时，根据最新的hash值调用注册好的回调函数，即改变页面。\n\n#### 创建路由\n```js\nclass Routers{\n constructor(){\n // 保存路由信息\n this.routes = {};\n this.currentUrl = '';\n window.addEventListener('load', this.refresh, false);\n window.addEventListener('hashchange', this.refresh, false);\n }\n\n // 用于注册路由的函数\n route = (path, callback) => {\n this.routes[path] = callback || function(){};\n }\n\n // 监听事件的回调，负责当页面hash改变时执行对应hash值的回调函数\n refresh = () => {\n this.currentUrl = location.hash.slice(1) || '/';\n this.routes[this.currentUrl]();\n }\n}\n\nwindow.Router = new Routers();\n```\n\n#### 注册路由\n使用route方法添加对应的路由及其回调函数即可。以下代码实现了一个根据不同hash改变页面颜色的路由，模拟了页面的切换，在实际的SPA应用中，对应的就是页面内容的变化了。\n\n```js\nvar content = document.querySelector('body');\n\nfunction changeBgColor(color){\n content.style.background = color;\n}\n\n// 添加路由\nRouter.route('/', () => {\n changeBgColor('yellow');\n});\nRouter.route('/red', () => {\n changeBgColor('red');\n});\nRouter.route('/green', () => {\n changeBgColor('green');\n});\nRouter.route('/blue', () => {\n changeBgColor('blue');\n});\n```\n\n\n### History路由\n在H5之前，浏览器的history仅支持页面之前的跳转，包括前进和后退等功能。\n\n在HTML5中，新增以下API：\n```js\nhistory.pushState();\t\t\t// 添加新状态到历史状态栈\nhistory.replaceState();\t\t// 用新状态代替当前状态\nhistory.state;\t\t\t\t\t\t// 获取当前状态对象\n```\n\nhistory.pushState()和history.replaceState()均接收三个参数：\n\n- state：一个与指定网址相关的状态对象，popstate事件触发时，该对象会传入回调函数。如果不需要这个对象，此处可以填null。\n- title：新页面的标题，但是所有浏览器目前都忽略这个值，因此这里可以填null。\n- url：新的网址，必须与当前页面处在同一个域。浏览器的地址栏将显示这个网址\n\n由于history.pushState()和 history.replaceState()都具有在改变页面URL的同时，不刷新页面的能力，因此也可以用来实现前端路由。\n\n#### 创建路由类\n```js\nclass Routers{\n constructor(){\n this.routes = {};\n window.addEventListener('popstate', e => {\n const path = e.state && e.state.path;\n this.routes[path] && this.routes[path]();\n })\n }\n\n init(path){\n history.replaceState({path: path}, null, path);\n this.routes[path] && this.routes[path]();\n }\n\n route(path, callback){\n this.routes[path] = callback || function(){};\n }\n\n go(path){\n history.pushState({path: path}, null, path);\n this.routes[path] && this.routes[path]();\n }\n}\n\nwindow.Router = new Routers();\n```\n\n\n#### 注册路由\n```js\nfunction changeBgColor(color){\n content.style.background = color;\n}\n\nRouter.route(location.pathname, () => {\n changeBgColor('yellow');\n});\nRouter.route('/red', () => {\n changeBgColor('red');\n});\nRouter.route('/green', () => {\n changeBgColor('green');\n});\nRouter.route('/blue', () => {\n changeBgColor('blue');\n});\n\nconst content = document.querySelector('body');\nRouter.init(location.pathname);\n```\n\n\n#### 触发事件\n在使用hash实现的路由中，我们通过hashchange事件来监听hash的变化，但是上述代码中history的改变本身不会触发任何事件，因此无法直接监听history的改变来改变页面。因此，对于不同的情况，我们选择不同的解决方案：\n\n- 点击浏览器的前进或者后退按钮：监听popstate事件，获取相应路径并执行回调函数\n- 点击a标签：阻止其默认行为，获取其href属性，手动调用history.pushState()，并执行相应回调。\n\n```js\nconst ul = document.querySelector('ul');\n\nul.addEventListener('click', e => {\n if(e.target.tagName === 'A'){\n e.preventDefault();\n Router.go(e.target.getAttribute('href'));\n }\n})\n```\n\n### 对比\n基于hash的路由：\n\n缺点：\n- 看起来比较丑\n- 会导致锚点功能失效\n\n优点： \n- 兼容性更好\n- 无需服务器配合\n",{"_54":876,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/269/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/269/timeline",{"_54":879,"_56":57,"_58":880,"_60":881,"_62":882,"_64":883,"_66":884,"_68":885,"_70":886,"_72":887,"_74":888,"_107":889,"_127":128,"_129":26,"_130":-5,"_131":891,"_133":892,"_155":148,"_149":894,"_151":895,"_154":-5,"_159":160,"_161":896,"_166":-5,"_167":897,"_169":898,"_181":900,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/268","https://api.github.com/repos/pro-collection/interview-question/issues/268/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/268/comments","https://api.github.com/repos/pro-collection/interview-question/issues/268/events","https://github.com/pro-collection/interview-question/issues/268",1659757296,"I_kwDOJGDC6c5i7eLw",268,"[Vue] 在 v-for 时给每项元素绑定事件需要用事件代理吗？为什么？",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[890],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":893,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-09T05:37:04Z","2023-04-09T05:42:21Z",{"_163":148,"_164":148,"_165":148},"### Vue 并没有在源码中做代理\r\n\r\nvue 并没有在源码中做代理，至少是 2.x 是没有做事件代理的。但是理论上来说使用事件代理性能会更好一点。\r\n\r\n阅读 vue 源码的过程中，并没有发现 vue 会自动做事件代理，但是一般给 v-for 绑定事件时，都会让节点指向同一个事件处理程序（第二种情况可以运行，但是 eslint 会警告），一定程度上比每生成一个节点都绑定一个不同的事件处理程序性能好，但是监听器的数量仍不会变，所以使用事件代理会更好一点。\r\n\r\nreact 是委托到 document 上, 然后自己生成了合成事件, 冒泡到 document 的时候进入合成事件, 然后他通过 getParent() 获取该事件源的所有合成事件, 触发完毕之后继续冒泡。但是一些特殊的比如focus这种必须放在input这些dom上。\r\n\r\n### 为何事件代理会让性能好一些 \r\n\r\n说一下我个人理解，先说结论，可以使用\r\n\r\n事件代理作用主要是 2 个\r\n\r\n1. 将事件处理程序代理到父节点，减少内存占用率\r\n2. 动态生成子节点时能自动绑定事件处理程序到父节点\r\n\r\n这里我生成了十万个 span 节点，通过 performance monitor 来监控内存占用率和事件监听器的数量，对比以下 3 种情况\r\n\r\n1. 不使用事件代理，每个 span 节点绑定一个 click 事件，并指向同一个事件处理程序\r\n```html\r\n

\r\n \r\n {{item}}\r\n \r\n

\r\n```\r\n\r\n2. 不使用事件代理，每个 span 节点绑定一个 click 事件，并指向不同的事件处理程序\r\n```html\r\n

\r\n \r\n {{item}}\r\n \r\n

\r\n```\r\n\r\n3. 使用事件代理\r\n```html\r\n

\r\n \r\n {{item}}\r\n \r\n

\r\n```\r\n\r\n可以通过 chrome devtools performance monitor 查看内存使用情况 \r\n\r\n可以看到使用事件代理无论是监听器数量和内存占用率都比前两者要少 \r\n\r\n### 为什么 Vue 不适用事件委托\r\n\r\n首先我们需要知道事件代理主要有什么作用？\r\n\r\n1. 事件代理能够避免我们逐个的去给元素新增和删除事件\r\n2. 事件代理比每一个元素都绑定一个事件性能要更好\r\n\r\n从vue的角度上来看上面两点\r\n\r\n- 在v-for中，我们直接用一个for循环就能在模板中将每个元素都绑定上事件，并且当组件销毁时，vue也会自动给我们将所有的事件处理器都移除掉。所以事件代理能做到的第一点vue已经给我们做到了 \r\n- 在v-for中，给元素绑定的都是相同的事件，所以除非上千行的元素需要加上事件，其实和使用事件代理的性能差别不大，所以也没必要用事件代理 \r\n\r\n",{"_54":899,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/268/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/268/timeline",{"_54":902,"_56":57,"_58":903,"_60":904,"_62":905,"_64":906,"_66":907,"_68":908,"_70":909,"_72":910,"_74":911,"_107":912,"_127":128,"_129":26,"_130":-5,"_131":915,"_133":916,"_155":148,"_149":918,"_151":919,"_154":-5,"_159":160,"_161":920,"_166":-5,"_167":921,"_169":922,"_181":924,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/261","https://api.github.com/repos/pro-collection/interview-question/issues/261/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/261/comments","https://api.github.com/repos/pro-collection/interview-question/issues/261/events","https://github.com/pro-collection/interview-question/issues/261",1659556289,"I_kwDOJGDC6c5i6tHB",261,"[Vue] 使用Proxy实现简易的vue双向数据绑定",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[913,914],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":744,"_68":745,"_54":746,"_113":747,"_115":125,"_117":26,"_118":126},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":917,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-08T15:28:09Z","2023-04-08T15:28:10Z",{"_163":148,"_164":148,"_165":148},"### proxy 的基本使用\n可以直接看这个链接： https://github.com/pro-collection/interview-question/issues/8\n\n使用proxy实现数据劫持\n```js\nlet data = {\n name: YoLinDeng,\n height: '176cm'\n}\n\nconst p = new Proxy(data, {\n get(target, prop) {\n return Reflect.get(...arguments)\n },\n set(target, prop, newValue) {\n return Reflect.set(...arguments)\n }\n})\n```\n\n\n### 关于vue中数据响应式的原理\n\n#### 对数据进行侦测\n\n* 在vue2.X中，实现一个`observe`类，对于对象数据，通过`Object.defineProperty`来劫持对象的属性，实现`getter`和`setter`方法，这样就可以在getter的时候知道谁（订阅者）读取了数据，即谁依赖了当前的数据，将它通过`Dep类`（订阅器）收集统一管理，在setter的时候调用Dep类中的`notify`方法通知所以相关的订阅者进行更新视图。如果对象的属性也是一个对象的话，则需要递归调用`observe`进行处理。\n* 对于数组则需要另外处理，通过实现一个拦截器类，并将它挂载到数组数据的原型上，当调用`push/pop/shift/unshift/splice/sort/reverse`修改数组数据时候，相当于调用的是拦截器中重新定义的方法，这样在拦截器中就可以侦测到数据改变了，并通知订阅者更新视图。\n* vue3中使用Proxy替代了Object.defineProperty，优点在于可以直接监听对象而非属性、可以直接监听数组的变化、多达13种拦截方法。缺点是兼容性还不够好。Proxy作为新标准将受到浏览器厂商重点持续的性能优化。\n\n#### 对模板字符串进行编译\n\n* 实现Compile解析器类，将`template`中的模板字符串通过正则等方式进行处理生成对应的ast（抽象语法树），通过调用定义的不同钩子函数进行处理，包括开始标签（`start`）并判断是否自闭和以及解析属性、结束标签（`end`）、文本（`chars`）、注释（`comment`）\n* 将通过html解析与文本解析的ast进行优化处理，在静态节点上打标记，为后面`dom-diff`算法中性能优化使用，即在对比前后vnode的时候会跳过静态节点不作对比。\n* 最后根据处理好的ast生产`render`函数，在组件挂载的时候调用`render`函数就可以得到虚拟dom。\n\n#### 虚拟dom\n\n* vnode的类型包括注释节点、文本节点、元素节点、组件节点、函数式组件节点、克隆节点，`VNode`可以描述的多种节点类型，它们本质上都是`VNode`类的实例，只是在实例化的时候传入的属性参数不同而已。\n* 通过将模板字符串编译生成虚拟dom并缓存起来，当数据发生变化时，通过对比变化前后虚拟dom，以变化后的虚拟dom为基准，更新旧的虚拟dom，使它和新的一样。把dom-diff过程叫做`patch`的过程，其主要做了三件事，分别是创建/删除/更新节点。\n* 对于子节点的更新策略，vue中为了避免双重循环数据量大时候造成时间复杂度高带来的性能问题，而选择先从子节点数组中4个特殊位置进行对比，分别是：新前与旧前，新后与旧后，新后与旧前，新前与旧后。如果四种情况都没有找到相同的节点，则再通过循环方式查找。\n\n### 实现简易的vue双向数据绑定\nvue的双向数据绑定主要是指，数据变化更新视图变化，视图变化更新数据。 \n\n**实现代码如下**\n```handlebars\n\n\n\n \n \n Document\n \n\n\n

\n {{name}}\n

\n \n {{test}}\n

\n \n\n\n```\n\n```js\nclass vue extends EventTarget {\n constructor(option) {\n super()\n this.option = option\n this._data = this.option.data\n this.el = document.querySelector(this.option.el)\n this.compileNode(this.el)\n this.observe(this._data)\n }\n // 实现监听器方法\n observe(data) {\n const context = this\n // 使用proxy代理，劫持数据\n this._data = new Proxy(data, {\n set(target, prop, newValue) {\n // 自定义事件\n let event = new CustomEvent(prop, {\n detail: newValue\n })\n // 发布自定义事件\n context.dispatchEvent(event)\n return Reflect.set(...arguments)\n }\n })\n }\n // 实现解析器方法，解析模板\n compileNode(el) {\n let child = el.childNodes\n let childArr = [...child]\n childArr.forEach(node => {\n if (node.nodeType === 3) {\n let text = node.textContent\n let reg = /\\{\\{\\s*([^\\s\\{\\}]+)\\s*\\}\\}/g\n if (reg.test(text)) {\n let $1 = RegExp.$1\n this._data[$1] && (node.textContent = text.replace(reg, this._data[$1]))\n // 监听数据更改事件\n this.addEventListener($1, e => {\n node.textContent = text.replace(reg, e.detail)\n })\n }\n } else if (node.nodeType === 1) { // 如果是元素节点\n let attr = node.attributes\n // 判断属性中是否含有v-model\n if (attr.hasOwnProperty('v-model')) {\n let keyName = attr['v-model'].nodeValue\n node.value = this._data[keyName]\n node.addEventListener('input', e => {\n this._data[keyName] = node.value\n })\n }\n // 递归调用解析器方法\n this.compileNode(node)\n }\n })\n }\n}\n```\n\n",{"_54":923,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/261/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/261/timeline",{"_54":926,"_56":57,"_58":927,"_60":928,"_62":929,"_64":930,"_66":931,"_68":932,"_70":933,"_72":934,"_74":935,"_107":936,"_127":128,"_129":26,"_130":-5,"_131":938,"_133":939,"_155":148,"_149":941,"_151":942,"_154":-5,"_159":160,"_161":943,"_166":-5,"_167":944,"_169":945,"_181":947,"_183":-5,"_184":-5,"_185":156},"https://api.github.com/repos/pro-collection/interview-question/issues/257","https://api.github.com/repos/pro-collection/interview-question/issues/257/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/257/comments","https://api.github.com/repos/pro-collection/interview-question/issues/257/events","https://github.com/pro-collection/interview-question/issues/257",1657684985,"I_kwDOJGDC6c5izkP5",257,"[React] 为什么不能在循环、条件或嵌套函数中调用 Hooks？",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[937],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":257,"_64":258,"_58":259,"_66":260,"_68":261,"_70":262,"_72":263,"_118":264,"_143":940,"_145":266,"_147":148,"_127":128,"_149":267,"_151":268,"_153":-5,"_154":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2023-04-06T15:59:44Z","2023-04-06T15:59:45Z",{"_163":148,"_164":148,"_165":148},"如果在条件语句中使用hooks，React会抛出 error。\n\n这与React Hooks的底层设计的数据结构相关，先抛出结论：**react用链表来严格保证hooks的顺序**。\n\n一个典型的useState使用场景：\n\n```js\nconst [name,setName] = useState('leo');\n\n......\n\nsetName('Lily');\n```\n\n那么hooks在这两条语句分别作了什么？\n\n![](https://pic.rmb.bdstatic.com/bjh/89d2fa7124b06495bbbfd4b5758bd6e5.png)\n\n上图是 `useState` 首次渲染的路径，其中，跟我们问题相关的是 `mountState` 这个过程，简而言之，这个过程初始化了一个hooks，并且将其追加到链表结尾。\n\n```js\n// 进入 mounState 逻辑\n\nfunction mountState(initialState) {\n\n // 将新的 hook 对象追加进链表尾部\n var hook = mountWorkInProgressHook();\n\n // initialState 可以是一个回调，若是回调，则取回调执行后的值\n\n if (typeof initialState === 'function') {\n\n // $FlowFixMe: Flow doesn't like mixed types\n\n initialState = initialState();\n }\n\n // 创建当前 hook 对象的更新队列，这一步主要是为了能够依序保留 dispatch\n\n const queue = hook.queue = {\n\n last: null,\n\n dispatch: null,\n\n lastRenderedReducer: basicStateReducer,\n\n lastRenderedState: (initialState: any),\n\n };\n\n // 将 initialState 作为一个“记忆值”存下来\n\n hook.memoizedState = hook.baseState = initialState;\n\n // dispatch 是由上下文中一个叫 dispatchAction 的方法创建的，这里不必纠结这个方法具体做了什么\n\n var dispatch = queue.dispatch = dispatchAction.bind(null, currentlyRenderingFiber$1, queue);\n\n // 返回目标数组，dispatch 其实就是示例中常常见到的 setXXX 这个函数，想不到吧？哈哈\n\n return [hook.memoizedState, dispatch];\n}\n```\n\n从这段源码中我们可以看出，mounState 的主要工作是初始化 Hooks。在整段源码中，最需要关注的是 `mountWorkInProgressHook` 方法，它为我们道出了 Hooks 背后的数据结构组织形式。以下是 `mountWorkInProgressHook` 方法的源码：\n\n```js\nfunction mountWorkInProgressHook() {\n\n // 注意，单个 hook 是以对象的形式存在的\n var hook = {\n\n memoizedState: null,\n\n baseState: null,\n\n baseQueue: null,\n\n queue: null,\n\n next: null\n\n };\n\n if (workInProgressHook === null) {\n // 这行代码每个 React 版本不太一样，但做的都是同一件事：将 hook 作为链表的头节点处理\n firstWorkInProgressHook = workInProgressHook = hook;\n } else {\n // 若链表不为空，则将 hook 追加到链表尾部\n workInProgressHook = workInProgressHook.next = hook;\n }\n // 返回当前的 hook\n return workInProgressHook;\n}\n\n```\n\n到这里可以看出，hook 相关的所有信息收敛在一个 hook 对象里，而 hook 对象之间以单向链表的形式相互串联。\n\n接着，我们来看更新过程\n\n![](https://pic.rmb.bdstatic.com/bjh/1cc5bd4c72e4f22d1aa828df3c831f2d.png)\n\n上图中，需要注意的是updateState的过程：按顺序去遍历之前构建好的链表，取出对应的数据信息进行渲染。\n\n我们把 mountState 和 updateState 做的事情放在一起来看：mountState（首次渲染）构建链表并渲染；updateState 依次遍历链表并渲染。\n\nhooks 的渲染是通过“依次遍历”来定位每个 hooks 内容的。如果前后两次读到的链表在顺序上出现差异，那么渲染的结果自然是不可控的。\n\n这个现象有点像我们构建了一个长度确定的数组，数组中的每个坑位都对应着一块确切的信息，后续每次从数组里取值的时候，只能够通过索引（也就是位置）来定位数据。也正因为如此，在许多文章里，都会直截了当地下这样的定义：Hooks 的本质就是数组。但读完这一课时的内容你就会知道，Hooks 的本质其实是链表。\n\n我们举个例子：\n\n```js\n let mounted = false;\n\nif(!mounted){\n // eslint-disable-next-line\n const [name,setName] = useState('leo');\n const [age,setAge] = useState(18);\n mounted = true;\n}\nconst [career,setCareer] = useState('码农');\nconsole.log('career',career);\n\n......\n\n

setName('Lily')}>\n 点我点我点我\n

\n```\n\n点击div后，我们期望的输出是 \"码农\"，然而事实上(尽管会error，但是打印还是执行)打印的为 \"Lily\"\n\n原因是，三个useState在初始化的时候已经构建好了一个三个节点的链表结构，依次为： `name('leo') --> age(18) --> career('码农')`\n\n每个节点都已经派发了一个与之对应的update操作，因此执行setName时候，三个节点就修改为了 `name('Lily') --> age(18) --> career('码农')`\n\n然后执行update渲染操作，从链表依次取出值，此时，条件语句的不再执行，第一个取值操作会从链表的第一个，也就是name对应的hooks对象进行取值：此时取到的为 `name:Lily`\n\n必须按照顺序调用从根本上来说是因为 useState 这个钩子在设计层面并没有“状态命名”这个动作，也就是说你每生成一个新的状态，React 并不知道这个状态名字叫啥，所以需要通过顺序来索引到对应的状态值\n",{"_54":946,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148,"_180":148},"https://api.github.com/repos/pro-collection/interview-question/issues/257/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/257/timeline","pagination",{"_950":951,"_163":952},"value",5,7,"actionData","errors"]