内容简介:我们都知道,新的React Hook系统在社区中引起的反响很大。我们已经尝试和测试过,并且对它及其潜力感到十分兴奋。当你想到hooks时会觉得他们很神奇,不暴露你的实例,React就能管理你的组件(不使用this关键字)。那么React到底是怎么做到的呢?今天我将会深入React hooks的实现来让我们更加了解它。这个神奇的特性存在的问题是,一旦出现问题就很难调试,因为它有复杂的堆栈跟踪支持。因此,通过深入理解React hooks的系统,我们就可以在遇到问题时非常快的解决它们,甚至可以提前避免错误发生。
我们都知道,新的React Hook系统在社区中引起的反响很大。我们已经尝试和测试过,并且对它及其潜力感到十分兴奋。当你想到hooks时会觉得他们很神奇,不暴露你的实例,React就能管理你的组件(不使用this关键字)。那么React到底是怎么做到的呢?
今天我将会深入React hooks的实现来让我们更加了解它。这个神奇的特性存在的问题是,一旦出现问题就很难调试,因为它有复杂的堆栈跟踪支持。因此,通过深入理解React hooks的系统,我们就可以在遇到问题时非常快的解决它们,甚至可以提前避免错误发生。
在我开始之前,我首先要声明我并不是React的开发者/维护者,因此,大家不要太信任我的观点。我确实非常深入地研究了React hooks的实现,但是无论如何我也不能保证这就是hooks的实际实现原理。话虽如此,我已经用React源码来支持我的观点,并尝试着使我的论点尽可能的真实。
首先,让我们进入需要确保hooks在React的作用域调用的机制,因为你现在可能知道如果在没有正确的上下文调用钩子是没有意义的:
The dispatcher
dispatcher 是包含了hooks函数的共享对象。它将根据ReactDom的渲染阶段来动态分配或者清除,并且确保用户无法在 React 组件外访问hooks。 请参阅实现
我们可以在渲染根组件前通过简单的切换来使用正确的dispatcher,用一个叫做enableHooks的标志来开启/禁用;这意味这从技术上来说,我们可以在运行时开启/禁用挂钩。React 16.6.x就已经有了试验性的实现,只不过它是被禁用的。 请参阅实现
当我们执行完渲染工作时,我们将dispatcher 置空从而防止它在ReactDOM的渲染周期之外被意外调用。这是一种可以确保用户不做傻事的机制。 请参阅实现
dispatcher 在每一个 hook 调用中 使用resolveDispatcher()这个函数来调用。就像我之前说的,在React的渲染周期之外调用是毫无意义的,并且React会打印出警告信息“Hooks只能在函数组件的主体内部调用” 请参照实现
let currentDispatcher const dispatcherWithoutHooks = { /* ... */ } const dispatcherWithHooks = { /* ... */ } function resolveDispatcher() { if (currentDispatcher) return currentDispatcher throw Error("Hooks can't be called") } function useXXX(...args) { const dispatcher = resolveDispatcher() return dispatcher.useXXX(...args) } function renderRoot() { currentDispatcher = enableHooks ? dispatcherWithHooks : dispatcherWithoutHooks performWork() currentDispatcher = null } 复制代码
到此为止既然我们已经看过了这种简单的封装机制,我希望我们转到本文的核心 - Hooks。我想向您介绍一个新概念:
The hooks queue
在使用场景之后,hooks表示为在调用顺序下链接在一起的节点。它们被表示成这样是因为hooks并不是简单的创建然后又把它遗留下来。它们有一种可以让他们变成它们自己的机制。一个Hook有几个我希望你可以在深入研究实现之前记住的属性:
- 它的初始状态在首次渲染时被创建。
- 她的状态可以即时更新。
- React会在之后的渲染中记住hook的状态
- React会根据调用顺序为您提供正确的状态
- React会知道这个hook属于哪个Fiber。
因此,我们需要重新思考我们查看组件状态的方式。到目前为止,我们认为它就像是一个普通的对象:
{ foo: 'foo', bar: 'bar', baz: 'baz', } 复制代码
但是在处理hook时,它应该被视为一个队列,其中每个节点代表一个状态的单个模型:
{ memoizedState: 'foo', next: { memoizedState: 'bar', next: { memoizedState: 'bar', next: null } } } 复制代码
可以在实现中查看单个hook节点的模式。你会看到hook有一些额外的属性,但是理解钩子如何工作的关键在于memoizedState和next。其余属性由useReducer()hook专门用于缓存已经调度的操作和基本状态,因此在各种情况下,还原过程可以作为后备重复: · baseState - 将给予reducer的状态对象。 · baseUpdate- 最近的创建了最新baseState的调度操作。 · queue - 调度操作的队列,等待进入reducer。
不幸的是,我没有设法很好地掌握reducer hook,因为我没有设法重现任何边缘情况,所以我不觉得舒服去精心设计。我只能说,reducer 的实现是如此不一致,在代码注释中甚至指出,“不知道这些是否都是所需的语义”; 所以我该如何确定?!
所以回到hooks,在每个函数组件调用之前,将调用一个名为prepareHooks()的函数,其中当前fiber及其hooks队列中的第一个hook节点将被存储在全局变量中。这样,只要我们调用一个hook函数(useXXX()),就会知道要在哪个上下文中运行。
let currentlyRenderingFiber let workInProgressQueue let currentHook // Source: https://github.com/facebook/react/tree/5f06576f51ece88d846d01abd2ddd575827c6127/react-reconciler/src/ReactFiberHooks.js:123 function prepareHooks(recentFiber) { currentlyRenderingFiber = workInProgressFiber currentHook = recentFiber.memoizedState } // Source: https://github.com/facebook/react/tree/5f06576f51ece88d846d01abd2ddd575827c6127/react-reconciler/src/ReactFiberHooks.js:148 function finishHooks() { currentlyRenderingFiber.memoizedState = workInProgressHook currentlyRenderingFiber = null workInProgressHook = null currentHook = null } // Source: https://github.com/facebook/react/tree/5f06576f51ece88d846d01abd2ddd575827c6127/react-reconciler/src/ReactFiberHooks.js:115 function resolveCurrentlyRenderingFiber() { if (currentlyRenderingFiber) return currentlyRenderingFiber throw Error("Hooks can't be called") } // Source: https://github.com/facebook/react/tree/5f06576f51ece88d846d01abd2ddd575827c6127/react-reconciler/src/ReactFiberHooks.js:267 function createWorkInProgressHook() { workInProgressHook = currentHook ? cloneHook(currentHook) : createNewHook() currentHook = currentHook.next workInProgressHook } function useXXX() { const fiber = resolveCurrentlyRenderingFiber() const hook = createWorkInProgressHook() // ... } function updateFunctionComponent(recentFiber, workInProgressFiber, Component, props) { prepareHooks(recentFiber, workInProgressFiber) Component(props) finishHooks() } 复制代码
一旦更新完成,一个叫做finishHooks()的函数将被调用,其中hooks队列中第一个节点的引用将存储在渲染完成的fiber对象的memoizedState属性中。这意味着hooks队列及其状态可以在外部被定位到:
const ChildComponent = () => { useState('foo') useState('bar') useState('baz') return null } const ParentComponent = () => { const childFiberRef = useRef() useEffect(() => { let hookNode = childFiberRef.current.memoizedState assert(hookNode.memoizedState, 'foo') hookNode = hooksNode.next assert(hookNode.memoizedState, 'bar') hookNode = hooksNode.next assert(hookNode.memoizedState, 'baz') }) return ( <ChildComponent ref={childFiberRef} /> ) } 复制代码
让我们更具体一点,谈谈各个hooks,从最常见的state hook开始:
State hooks
你将惊讶的了解到useState hook使用的useReducer只是为它提供了一个预定义的reducer处理程序 请参阅实现 。这意味着实际上useState返回的结果是一个reducer状态和一个action dispatcher。我希望你看一下state hook使用的reducer处理程序:
function basicStateReducer(state, action) { return typeof action === 'function' ? action(state) : action; } 复制代码
正如预期的那样,我们可以直接为action dispatcher提供新的状态; 但你会看那个吗?!我们还可以为dispatcher提供一个动作函数,该函数将接收旧状态并返回新状态。这意味着,当你将状态设置器传递到子组件时,你可以改变当前父组件的状态,不需要作为一个不同的prop传递下去。举个例子:
const ParentComponent = () => { const [name, setName] = useState() return ( <ChildComponent toUpperCase={setName} /> ) } const ChildComponent = (props) => { useEffect(() => { props.toUpperCase((state) => state.toUpperCase()) }, [true]) return null } 复制代码
最后,effect hooks - 它对组件的生命周期及其工作方式产生了重大影响:
Effect hooks
Effect hooks 的行为略有不同,并且有一个额外的逻辑层,我接下来会解释。同样,在我深入了解实现之前,我希望你能记住effect hooks的属性:
- 它们是在渲染时创建的,但它们在绘制后运行。
- 它们将在下一次绘制之前被销毁。
- 它们按照已经被定义的顺序执行。
请注意,我使用的是“绘制”术语,而不是“渲染”。这两个是不同的东西,我看到最近React Conf中的许多发言者使用了错误的术语!即使在官方的React文档中,他们也会说“在渲染屏幕之后”,在某种意义上应该更像“绘制”。render方法只创建fiber节点,但没有绘制任何东西。
因此,应该有另一个额外的队列保持这些effect,并应在绘制后处理。一般而言,fiber保持包含effect节点的队列。每种effect都是不同的类型,应在适当的阶段处理:
· 在变化之前调用实例的getSnapshotBeforeUpdate()方法 请参阅实现 。 ·执行所有节点的插入,更新,删除和ref卸载操作 请参阅实现 。 ·执行所有生命周期和ref回调。生命周期作为单独的过程发生,因此整个树中的所有放置,更新和删除都已经被调用。此过程还会触发任何特定渲染的初始effects 请参阅实现 。 ·由useEffect() hook 安排的effects - 基于实现也被称为“passive effects” (也许我们应该在React社区中开始使用这个术语?!)。
当涉及到hook effects时,它们应该存储在fiber的一个名为 updateQueue的属性中,并且每个effect node应该具有以下模式 请参阅实现 :
· tag - 一个二进制数,它将决定effect的行为(我将尽快阐述)。 · create- 绘制后应该运行的回调。 · destroy- 从create()返回的回调应该在初始渲染之前运行。 · inputs - 一组值,用于确定是否应销毁和重新创建effect。 · next - 函数组件中定义的下一个effect的引用。
除了tag属性外,其他属性都非常简单易懂。如果你已经很好地研究了hooks,你就会知道React为你提供了几个特殊的hooks:useMutationEffect()和useLayoutEffect()。这两种效果在内部使用useEffect(),这实际上意味着它们创建了一个effect节点,但它们使用不同的tag值。
标签由二进制值组合而成 请参阅实现 :
const NoEffect = /* */ 0b00000000; const UnmountSnapshot = /* */ 0b00000010; const UnmountMutation = /* */ 0b00000100; const MountMutation = /* */ 0b00001000; const UnmountLayout = /* */ 0b00010000; const MountLayout = /* */ 0b00100000; const MountPassive = /* */ 0b01000000; const UnmountPassive = /* */ 0b10000000; 复制代码
这些二进制值的最常见用例是使用管道(|)将这些位按原样添加到单个值。然后我们可以使用&符号(&)检查标签是否实现某种行为。如果结果为非零,则表示tag实现了指定的行为。
以下是React支持的hook effect类型及其标签 请参阅实现 :
Default effect — UnmountPassive | MountPassive. Mutation effect — UnmountSnapshot | MountMutation. Layout effect — UnmountMutation | MountLayout. 以下是React如何检查行为实现 请参阅实现 :
if ((effect.tag & unmountTag) !== NoHookEffect) { // Unmount } if ((effect.tag & mountTag) !== NoHookEffect) { // Mount } 复制代码
因此,基于我们刚刚学到的关于effect hooks的内容,我们实际上可以在外部向某个fiber注入effect:
function injectEffect(fiber) { const lastEffect = fiber.updateQueue.lastEffect const destroyEffect = () => { console.log('on destroy') } const createEffect = () => { console.log('on create') return destroy } const injectedEffect = { tag: 0b11000000, next: lastEffect.next, create: createEffect, destroy: destroyEffect, inputs: [createEffect], } lastEffect.next = injectedEffect } const ParentComponent = ( <ChildComponent ref={injectEffect} /> ) 复制代码
就是这样!你从这篇文章中最大的收获是什么?你将如何在你的React应用程序中使用这些新知识?很想看到有趣的评论!
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- ReactNative源码解析-初识源码
- Spring源码系列:BeanDefinition源码解析
- Spring源码分析:AOP源码解析(下篇)
- Spring源码分析:AOP源码解析(上篇)
- 注册中心 Eureka 源码解析 —— EndPoint 与 解析器
- 新一代Json解析库Moshi源码解析
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
企业应用架构模式
Martin Fowler / 王怀民、周斌 / 机械工业出版社 / 2010-4 / 59.00元
《企业应用架构模式》作者是当今面向对象软件开发的权威,他在一组专家级合作者的帮助下,将40多种经常出现的解决方案转化成模式,最终写成这本能够应用于任何一种企业应用平台的、关于解决方案的、不可或缺的手册。《企业应用架构模式》获得了2003年度美国软件开发杂志图书类的生产效率奖和读者选择奖。《企业应用架构模式》分为两大部分。第一部分是关于如何开发企业应用的简单介绍。第二部分是《企业应用架构模式》的主体......一起来看看 《企业应用架构模式》 这本书的介绍吧!