contextAPI

被彻底移除了就无法使用了那么为什么要彻底移除这个contextAPI的使用方式呢因为它对性能的影响会比较的大它会影响整个子树的一个更新过程它嵌套的context提供者是需要进行一个数据的合并的

嵌套组件中如果父子两者都提供相同的变量会进行一个合并越接近里层越会被选择也就是说在孙子消费变量的时候选择父亲的舍弃爷爷的

定位到

packages/react-reconciler/src/ReactFiberBeginWork.js#L1522

在这里有这个判断

packages/react-reconciler/src/ReactFiberContext.js#L115

要去推入

didPerformWorkStackCursor.current;

}回顾到

packages/react-reconciler/src/ReactFiberContext.js#L36//

cursor

用来记录我们当前的我们更新到某一个节点之后它应该可以拿到的context对应的所有值

let

createCursor(emptyContextObject);//

cursor

代表着我们在更新到某一个节点的时候它这个context是否有变化这么一个情况

let

操作可以看上述判断成立的条件下的代码即便有符合跳过更新的操作依然

push

(isLegacyContextProvider(Component))

{pushLegacyContextProvider(workInProgress);}break;}

contextAPI

最主要的就是来看在classcomponent的更新过程当中如果它是一个contextprovider那么它要执行的操作是

isContextProvider

来表示它是一个context的提供者只有声明了这个之后它才会作为一个context的provider来提供子树上面的context如果不这么声明即便在class里面提供了

getChildContext

pushContextProvider(workInProgress:

Fiber):

instance.__reactInternalMemoizedMergedChildContext)

Remember

挂载到全局变量上push(contextStackCursor,

workInProgress);push(didPerformWorkStackCursor,didPerformWorkStackCursor.current,workInProgress,);return

true;

classComponent它的state它的props都应该是没有任何变化的

这个时候,

any,nextProps,renderExpirationTime:

ExpirationTime,

(isLegacyContextProvider(Component))

{hasContext

true;pushLegacyContextProvider(workInProgress);}

else

false;}prepareToReadContext(workInProgress,

instance

instance.constructClassInstance(workInProgress,Component,nextProps,renderExpirationTime,);mountClassInstance(workInProgress,Component,nextProps,renderExpirationTime,);shouldUpdate

true;}

resumeMountClassInstance(workInProgress,Component,nextProps,renderExpirationTime,);}

else

updateClassInstance(current,workInProgress,Component,nextProps,renderExpirationTime,);}return

finishClassComponent(current,workInProgress,Component,shouldUpdate,hasContext,renderExpirationTime,);

push

{invalidateContextProvider(workInProgress,

Component,

bailoutOnAlreadyFinishedWork(current,workInProgress,renderExpirationTime,);}const

instance

RerenderReactCurrentOwner.current

workInProgress;let

Component.getDerivedStateFromError

function)

{stopProfilerTimerIfRunning(workInProgress);}}

else

{ReactCurrentFiber.setCurrentPhase(render);nextChildren

instance.render();if

||(debugRenderPhaseSideEffectsForStrictMode

workInProgress.mode

{instance.render();}ReactCurrentFiber.setCurrentPhase(null);}

else

match.forceUnmountCurrentAndReconcile(current,workInProgress,nextChildren,renderExpirationTime,);}

else

{reconcileChildren(current,workInProgress,nextChildren,renderExpirationTime,);}//

Memoize

instance.workInProgress.memoizedState

instance.state;//

{invalidateContextProvider(workInProgress,

Component,

invalidateContextProvider(workInProgress,

Component,

invalidateContextProvider(workInProgress:

Fiber,type:

workInProgress.stateNode;invariant(instance,Expected

have

processChildContext(workInProgress,type,previousContext,);instance.__reactInternalMemoizedMergedChildContext

mergedContext;//

order.pop(didPerformWorkStackCursor,

workInProgress);pop(contextStackCursor,

workInProgress);//

changed.push(contextStackCursor,

mergedContext,

workInProgress);push(didPerformWorkStackCursor,

didChange,

{pop(didPerformWorkStackCursor,

workInProgress);push(didPerformWorkStackCursor,

didChange,

__reactInternalMemoizedMergedChildContext之后pop

2次push

(!warnedAboutMissingGetChildContext[componentName])

{warnedAboutMissingGetChildContext[componentName]

true;warningWithoutStack(false,%s.childContextTypes

specified

it.,componentName,componentName,);}}return

parentContext;}let

{ReactCurrentFiber.setCurrentPhase(getChildContext);}startPhaseTimer(fiber,

执行这个

{ReactCurrentFiber.setCurrentPhase(null);}for

(let

childContextTypes,%s.getChildContext():

key

childContextTypes.,getComponentName(type)

忽略if

Unknown;checkPropTypes(childContextTypes,childContext,child

context,name,//

unstable_renderSubtreeIntoContainer()

and

API.ReactCurrentFiber.getCurrentFiberStackInDev,);}//

mergereturn

总结来说父子孙三个组件在更新子组件的时候先去push了一个它之前存在的这个属性

因为我们不知道这个组件它是否要更新不管它是否要更新都要先都要执行

push

对于子组件来说它的所有子树所获取到的context肯定是经过子组件和上层的父组件合并的

context

__reactInternalMemoizedMergedChildContext

来说需要去改变它didChange

的这个方法它是用来判断这个组件是否可以跳过更新的一个非常关键的一个值,

true会导致我们每一个组件都需要去更新而最终导致整个性能变得非常的差所以这就是

context

注意还有一种情况是这样的父子孙三层组件有一个子组件没有儿子组件

也就是有多个子组件其中有的子组件没有下层组件这时候这类子组件拿到的是父组件原来的而非合并过的

比如说我们随便挑一个

getUnmaskedContext(workInProgress,

ctor,

getMaskedContext(workInProgress,

...

后者在应用中我们自己的代码里用于设定接收上层属性的前者就是要去读取某一个新的

contextAPI

对于react来说它即将把所有context相关的东西呢都放在新的contextAPI里面

contextType

getUnmaskedContext(workInProgress,

ctor,

true)这个方法来去读取用在这一个组件上面它所对应的context属性function

getUnmaskedContext(workInProgress:

Fiber,Component:

Function,didPushOwnContextIfProvider:

boolean,

的一个情况在调用update之前那么肯定是已经调用过push了

previousContext这个

pushContextProvider给它赋值的这个值就比如说在更新

子组件

value子组件提供的value是给自己子树也就是孙组件及之后使用的子组件要用context的话应该是去读取父组件提供的

context子组件要去获取父组件提供的context要去调用

getUnmaskedContext

这个方法而如果组件同时是一个provider那它肯定已经push过了所以组件必须返回

previousContext

contextprovider当然没有执行过push只需要执行当前这个cursor即可

getMaskedContext(workInProgress:

Object,

instance.__reactInternalMemoizedUnmaskedChildContext

unmaskedContext)

instance.__reactInternalMemoizedMaskedChildContext;}//

context

Unknown;checkPropTypes(contextTypes,context,context,name,ReactCurrentFiber.getCurrentFiberStackInDev,);}//

Cache

中获得当前组件需要读取的属性也就是说当前组件需要什么指定什么context中就返回什么

Class

如何去提供这个context以及它如何去获取这个context的一个过程

push

packages/react-reconciler/src/ReactFiberCompleteWork.js#L540

function

(isLegacyContextProvider(Component))

{popLegacyContext(workInProgress);}break;}//

...

packages/react-reconciler/src/ReactFiberContext.js#L124

function

{pop(didPerformWorkStackCursor,

fiber);

packages/react-reconciler/src/ReactFiberContext.js#L215

function

pushContextProvider(workInProgress:

Fiber):

workInProgress);push(didPerformWorkStackCursor,didPerformWorkStackCursor.current,workInProgress,);return

true;

contextStackCursor这就是我之前说过的push

context-stack

假设整个树形结构下面的每一个节点它都是一个classcomponent这个时候我们更新然后

App

classcomponent它要更新的过程中肯定要获取这个App和和div提供的context合并之后的那个对象对App更新的过程中它调用了push然后在div执行更新的时候它先去获取App

push

作为它更新的时候要用的那个context它自己也要去push一个contextpush的时候要跟App提供的context进行一个合并这个时候游标已经到了第二个context了,

第二个是App和和div合并的这两个值都是在stack栈里面有存着的只不过现在的

contextStackCursor

这个游标指向的是div它合并过之后的那个context这个context是提供给Input渲染更新的时候它要获取的那个值就这么一层一层下来之后到最后更新

input

这个节点的时候它拿到的context是上面这三个组件它合并过的

context对于List的更新它不需要Input合并进去它只需要App和div它们合并之后的那个

context

的时候执行到每个节点要执行对应的pop所以这个时候就可以对节点

push

的位置可以一一对应起来这样的话就不会造成整个stack里面的这个顺序混淆

childContextTypes