Que's Blog

WebFrontEnd Development

0%

react生命周期分析

发表于 阅读次数：
开始读react代码。续上一篇继续分析生命周期。

目标

这一节分析一下react的声明周期

这里直接引用一下现有图片,图片来自这里

思考

这里需要认真思考一下的是:

  • 钩子函数在一个组件里是按怎样的数据形式保存的
  • 调用的时机在react内部是如何进行的
  • 钩子函数是在哪些模块内被触发调用的
  • 如何进行方便的调试和验证

步骤

我们还是依照测试文件直接debug。

目标文件为ReactComponentLifeCycle-test.js。这是react框架自带的lifecycle测试文件，我们不需要自己去写测试用例和DEMO。

初始化 Initialization

组件的props&&state初始化实质上和DOM无关，和更新相关生命周期也无关。

这里找到了ReactES6Class-test.js。使用下面的断言进行debug查看组件初始化环节。

1
2
3
4
5
6
7
8
9
10
11
12
it('renders based on state using initial values in this.props', () => {
  class Foo extends React.Component {
    constructor(props) {
      super(props);
      this.state = {bar: this.props.initialValue};
    }
    render() {
      return <span className={this.state.bar} />;
    }
  }
  test(<Foo initialValue="foo" />, 'SPAN', 'foo');
});

我们在super(props)这里打一个断点开始debug,断点到了之后step into。然后点下一步直接跳到了src/isomorphic/modern/class/ReactBaseClasses.js。不过ES6这里定义过于简单了(直接走了构造器将props和state挂在上面了)看不出太深入的，所以我们继续向下深入render。

1
2
3
4
5
6
7
8
function ReactComponent(props, context, updater) {
  this.props = props;
  this.context = context;
  this.refs = emptyObject;
  // We initialize the default updater but the real one gets injected by the
  // renderer.
  this.updater = updater || ReactNoopUpdateQueue;
}

这里断点放在render的return这一行，到了之后step into, 然后进入了src/isomorphic/classic/element/ReactElementValidator.js，光标放到line243点run to cursor,然后step into。这样就到了src/isomorphic/classic/element/ReactElement.js。

props这一块其实还是很容易理解，babel对jsx转换时候就将props传入了。

这个图其实说得很清晰了，我们主要分析state的处理。

getInitialState这个发生在组件产生之后，挂载之前。它是在mountComponentIntoNode中，具体一点的话，它的调用路径是这样的:

1
2
3
4
5
mountComponentIntoNode
	-> ReactReconciler.mountComponent
		-> internalInstance.mountComponent
			-> ReactCompositeComponent.mountComponent
				-> ReactCompositeComponent._constructComponent

之前对这个render是如何渲染到dom有过分析，完整的流程是这样的:

1
2
3
4
5
6
7
ReactMount.render
	-> ReactMount._renderSubtreeIntoContainer
		->  ReactMount._renderNewRootComponent
			-> ReactUpdates.batchedUpdates
				-> ReactUpdates.batchedMountComponentIntoNode
					-> mountComponentIntoNode
						-> ReactMount._mountImageIntoNode

具体一些来说，我们的分析环节是在mountComponentIntoNode中，排除ReactMount._mountImageIntoNode调用之外的地方。

回顾一下

mountComponentIntoNode做了这些事:

  • 调用ReactReconciler.mountComponent生成markup标记内部含有{children: markup数组, node:HTMLElement}
  • 调用ReactMount._mountImageIntoNode渲染markup

ReactReconciler.mountComponent生成markup这一节在之前分析过，详细看之前的分析，这里只就关键的引用代码instantiateReactComponent做说明。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
function instantiateReactComponent(node, shouldHaveDebugID) {
  var instance;
  if (node === null || node === false) {
    instance = ReactEmptyComponent.create(instantiateReactComponent);
  } else if (typeof node === 'object') {
    var element = node;
    var type = element.type;
    if (typeof type !== 'function' && typeof type !== 'string') {
      var info = '';
      info += getDeclarationErrorAddendum(element._owner);
      invariant(
        false,
        'Element type is invalid: expected a string (for built-in components) ' +
          'or a class/function (for composite components) but got: %s.%s',
        type == null ? type : typeof type,
        info,
      );
    }

    // Special case string values
    if (typeof element.type === 'string') {
      instance = ReactHostComponent.createInternalComponent(element);
    } else if (isInternalComponentType(element.type)) {
      instance = new element.type(element);
      if (!instance.getHostNode) {
        instance.getHostNode = instance.getNativeNode;
      }
    } else {
      instance = new ReactCompositeComponentWrapper(element);
    }
  } else if (typeof node === 'string' || typeof node === 'number') {
    instance = ReactHostComponent.createInstanceForText(node);
  } else {
    invariant(false, 'Encountered invalid React node of type %s', typeof node);
  }

  instance._mountIndex = 0;
  instance._mountImage = null;
  return instance;
}

之前我们说到过instance = ReactHostComponent.createInternalComponent(element);的情况，然而我们关注的getInitialState，事情恰好发生在instance = new ReactCompositeComponentWrapper(element);

回顾instantiateReactComponent，看看ReactCompositeComponentWrapper的定义

1
2
3
4
5
6
7
8
9
10
var ReactCompositeComponentWrapper = function(element) {
  this.construct(element);
};
Object.assign(
  ReactCompositeComponentWrapper.prototype,
  ReactCompositeComponent,
  {
    _instantiateReactComponent: instantiateReactComponent,
  },
);

此时，生成markup的代码实质上是调用ReactCompositeComponent.mountComponent

1
2
3
4
5
6
7
var markup = internalInstance.mountComponent(
    transaction,
    hostParent,
    hostContainerInfo,
    context,
    parentDebugID,
);

然而这个例子这里存在internalInstance.mountComponent被调用了两次的问题

第一次渲染

第一次渲染是TopLevelWrapper组件的渲染

在ReactCompositeComponent.mountComponent节点的函数中,可以看到inst.state = initialState = null

而这个inst是_constructComponent的返回值，所以最终的定义就在这个函数内部了，重点跟踪一下这个引用好了。

这个函数内部引用了ReactCompositeComponent._constructComponentWithoutOwner,这里核心代码引用到了Component(publicProps, publicContext, updateQueue) ,
这里的Component是_currentElement.type的引用，debugger断点打过来，最简单的元素初始渲染这里是TopLevelWrapper实例(同时也是Component实例)。
可以看到此时initialState === undefined,所以它最后被赋值为null了。

第一次定义state这里 仅仅相当于是一个初始化流程。最终定义还是看后面的定义

第二次渲染

到了第二次时候 也就是performInitialMount内执行到

1
2
3
4
5
6
7
8
var markup = ReactReconciler.mountComponent(
    child,
    transaction,
    hostParent,
    hostContainerInfo,
    this._processChildContext(context),
    debugID,
);

这一块代码时候触发的(关于这个第一次和第二次这个，可以参考后面提到的『jsx到js的转换 』)。

此时child是ReactCompositeComponentWrapper实例所以markup生成还是调用ReactCompositeComponent.mountComponent。

这时候就是我们的Foo组件了。这里获取实例使用了ReactReconciler._constructComponent,它又调用了_constructComponentWithoutOwner。它大致代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
_constructComponentWithoutOwner: function(
  doConstruct,
  publicProps,
  publicContext,
  updateQueue,
) {
  var Component = this._currentElement.type;
  if (doConstruct) {
    if (__DEV__) {
	  // ... 略
    } else {
      return new Component(publicProps, publicContext, updateQueue);
    }
  }
},

我们在之前代码里面可以找到this._currentElement = element,所以它实质上调用的是ReactElement实例的type属性。这个属性在这里对应的是我们的Foo函数。而Foo在构造器里面对state做了定义。这里就是state数据被录入的根源环节。

但是Initialization此刻还没有完毕。继续往下走，直到ReactCompositeComponent.js line252-320这几行都执行完毕，我们的Initialization环节才正式完毕

1
2
3
4
5
6
7
8
9
10
11
12
13
inst.props = publicProps;
inst.context = publicContext;
inst.refs = emptyObject;
inst.updater = updateQueue;

this._instance = inst;

ReactInstanceMap.set(inst, this);

var initialState = inst.state;
if (initialState === undefined) {
  inst.state = initialState = null;
}

by the way,我们再往下走一些，可以看到

1
2
3
4
5
6
7
if (inst.componentDidMount) {
  if (__DEV__) {
	// 略略略...
  } else {
    transaction.getReactMountReady().enqueue(inst.componentDidMount, inst);
  }
}

是的componentDidMount在初始化完毕后就接着被调用了。

PS:上面提到了type属性，这里再次温习一下jsx到js的转换防止一知半解。

jsx到js的转换

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
class Bar extends React.Component {
  constructor(props) {
    super(props);
  }
  render() {
    return <div>{this.props.name}</div>
  }
}
class Foo extends React.Component {
  constructor(props) {
    super(props);
    this.state = {bar: this.props.initialValue};
  }
  render() {
    return <span className={this.state.bar}>
      <Bar name="test"/>
    </span>;
  }
}

ReactDOM.render(
  <Foo className="test" />, 
  mountNode
)

// 此时<Foo className={this.state.bar} />在大体的结构上会转换成:
React.createElement( // a
	React.createElement( // b
        "span",
        { className: this.state.bar },
        React.createElement( // c
            React.createElement( // d
                "div",
                null,
                this.props.name
      		)
        , { name: "test" })
    ),
	{ className: "test" }
}

这里需要注意的是:

  • React.createElement返回值是一个ReactElement对象, 但是它本身则是一个Function
  • 对 a|b|c标记的createElement来说，他们的返回值的type是一个Function，对应的是组件的定义函数
  • 对 a|b|c标记的createElement来说，他们的第一个参数并不真的就是直接传入React.createElement这个函数，而是组件的定义函数的转译(bable处理),它里面一定会有一个render，render里面会调用React.createElement()返回一个ReactElement对象
  • 而对于d标记的createElement来说，它的返回值是一个ReactElement对象。

关于这个render的调用。参见ReactCompositeComponent.performInitialMount

1
2
3
4
// If not a stateless component, we now render
if (renderedElement === undefined) {
    renderedElement = this._renderValidatedComponent();
}

一路跟进引用最终你会发现render在这里被调用了。

挂载 Mounting

componentWillMount

这个函数在ReactCompositeComponent.performInitialMount中

1
2
3
4
5
6
7
8
9
10
11
12
if (inst.componentWillMount) {
  if (__DEV__) {
	// 略略略...
  } else {
    inst.componentWillMount();
  }
  // When mounting, calls to `setState` by `componentWillMount` will set
  // `this._pendingStateQueue` without triggering a re-render.
  if (this._pendingStateQueue) {
    inst.state = this._processPendingState(inst.props, inst.context);
  }
}

componentDidMount

这个不再废话,参见上文的『第二次渲染』。ReactCompositeComponent.mountComponent中

render

render这个也不再说了,参见『 jsx到js的转换』。ReactCompositeComponent.performInitialMount中，更细致一些，那就是在ReactCompositeComponent._renderValidatedComponent中。

更新 Updation

更新这个环节的钩子函数需要配合分析: 当收到新的props、state时，会发生什么？

不然就会发生这些钩子函数好找，但是何时会被触发却不明确的问题。

我们之前分析过render的流程，所以这里顺便也分析一下，update的流程。

State更新

观察State更新需要对这个更新是怎样被唤起的，所以会分为之前和之后两个环节。

Before 更新之前

这里使用这个测试用例(ReactES6Class-test.js里面)来测试观察state更新环节来对整体逻辑做初步概览。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
it('setState through an event handler', () => {
  class Foo extends React.Component {
    constructor(props) {
      super(props);
      this.state = {bar: props.initialValue};
    }
    handleClick() {
      this.setState({bar: 'bar'});
    }
    render() {
      return (
        <Inner name={this.state.bar} onClick={this.handleClick.bind(this)} />
      );
    }
  }
  test(<Foo initialValue="foo" />, 'DIV', 'foo');
  attachedListener();
  expect(renderedName).toBe('bar');
});

这个setState的调用的定义在：

1
2
3
4
5
6
7
ReactComponent.prototype.setState = function(partialState, callback) {
  // 略略略...
  this.updater.enqueueSetState(this, partialState);
  if (callback) {
    this.updater.enqueueCallback(this, callback, 'setState');
  }
};

step in方式进入了ReactUpdateQueue.enqueueSetState，进行了一些验证后，将这个state纯对象push进入了internalInstance._pendingStateQueue数组，然后调用ReactUpdates.enqueueUpdate(internalInstance)来更新这个组件。

1
2
3
4
5
6
7
8
9
10
11
function enqueueUpdate(component) {
  ensureInjected();
  if (!batchingStrategy.isBatchingUpdates) {
    batchingStrategy.batchedUpdates(enqueueUpdate, component);
    return;
  }
  dirtyComponents.push(component);
  if (component._updateBatchNumber == null) {
    component._updateBatchNumber = updateBatchNumber + 1;
  }
}

这个函数的调用有些绕而且看起来必要性不高因为ReactDefaultBatchingStrategy.batchedUpdates在此时必然会执行到transaction.perform(callback, null, a, b, c, d, e)——实质上它是callback(a, b, c, d, e)的事务版本，执行有前后置条件。最后调用自身将component推到dirtyComponents进行更新标记。

1
2
3
4
5
6
7
8
9
10
batchedUpdates: function(callback, a, b, c, d, e) {
  var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates;
  ReactDefaultBatchingStrategy.isBatchingUpdates = true;
  // The code is written this way to avoid extra allocations
  if (alreadyBatchingUpdates) {
    return callback(a, b, c, d, e);
  } else {
    return transaction.perform(callback, null, a, b, c, d, e);
  }
}

在这个debug环节，transaction.perform基本就是一个大体的调用终点了。But,这个更新Component的调用去哪儿了？

这里不得不说事务概念了，ReactDefaultBatchingStrategy的事物实例是有两个事务注册的:

1
2
3
4
5
6
7
8
9
10
var RESET_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: function() {
    ReactDefaultBatchingStrategy.isBatchingUpdates = false;
  },
};
var FLUSH_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates),
};

我们都更新环节就是在ReactUpdates.flushBatchedUpdates.bind(ReactUpdates)这里。

1
2
3
4
5
6
7
8
9
10
var flushBatchedUpdates = function() {
  while (dirtyComponents.length || asapEnqueued) {
    if (dirtyComponents.length) {
      var transaction = ReactUpdatesFlushTransaction.getPooled();
      transaction.perform(runBatchedUpdates, null, transaction);
      ReactUpdatesFlushTransaction.release(transaction);
    }
    // 略略略...
  }
};

这样，当我们处理好了函数执行之后，组件也会随之被runBatchedUpdates更新。这其中还有很多细节，但是这里仅仅做好整理逻辑梳理即可，暂时不做细致分析(但是很显然，相关更新的钩子函数会在里面)。

After 正式开始

继续上一步分析。在这个例子中，执行到runBatchedUpdates后，这里的更新最终会执行到ReactCompositeComponent.updateComponent。所以后面的生命周期函数都会在这里一一展现。这里回顾一下更新环节生命周期的顺序。

1
2
3
4
shouldComponentUpdate
	-> componentWillUpdate
		-> render
			-> componentDidUpdate

shouldComponentUpdate

ReactCompositeComponent line 838-860

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
if (!this._pendingForceUpdate) {
  if (inst.shouldComponentUpdate) {
    if (__DEV__) {
		// 略略略...
    } else {
      shouldUpdate = inst.shouldComponentUpdate(
        nextProps,
        nextState,
        nextContext,
      );
    }
  } else {
    if (this._compositeType === CompositeTypes.PureClass) {
      shouldUpdate =
        !shallowEqual(prevProps, nextProps) ||
        !shallowEqual(inst.state, nextState);
    }
  }
}

这一步生命周期完成之后我们进入了ReactCompositeComponent._performComponentUpdate(具体流程参见ReactCompositeComponent.updateComponent)

componentWillUpdate

ReactCompositeComponent line 955-965

1
2
3
4
5
6
7
if (inst.componentWillUpdate) {
  if (__DEV__) {
    // 略略略...
  } else {
    inst.componentWillUpdate(nextProps, nextState, nextContext);
  }
}

render

ReactCompositeComponent line 973

1
this._updateRenderedComponent(transaction, unmaskedContext);

componentDidUpdate

ReactCompositeComponent line 975-1002

这一步还是很好理解，如果有定义这个函数，那么就通过事务机制再render完成之后执行componentDidUpdate。至此State更新环节的流程就完整、畅通了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
if (hasComponentDidUpdate) {
  if (__DEV__) {
    // 略略略...
  } else {
    transaction
      .getReactMountReady()
      .enqueue(
        inst.componentDidUpdate.bind(
          inst,
          prevProps,
          prevState,
          prevContext,
        ),
        inst,
      );
  }
}

Props更新

props引起的更新可能会不太容易理解。

setState这个是一个函数理解它的触发没有太大难度。这里回顾一下props和state的区别: state是组件内部的状态，是可以修改；而props是父组件上传下来的，他不能在组件内部被修改。

Before 更新之前

为了辅助说明，这里还是使用上面提到过的测试用例，但是我们这里换个角度来看这个用例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
it('setState through an event handler', () => {
  class Foo extends React.Component {
    constructor(props) {
      super(props);
      this.state = {bar: props.initialValue};
    }
    handleClick() {
      this.setState({bar: 'bar'});
    }
    render() {
      return (
        <Inner name={this.state.bar} onClick={this.handleClick.bind(this)} />
      );
    }
  }
  test(<Foo initialValue="foo" />, 'DIV', 'foo');
  attachedListener();
  expect(renderedName).toBe('bar');
});

稍微分析一下这个测试用例，可以看到Inner组件在handleClick被触发以后，它的this.props.name的值从foo变为了bar。所以我们这里重点分析一下，这个变化是如何最终反应到DOM上的。

在一切开始之前，我们还是得回顾，这个this.props.name到底是如何传递到Inner组件上的——this.setState，是的，就是this.setState。

回顾一下state的钩子函数触发顺序:

1
2
3
4
shouldComponentUpdate
	-> componentWillMount
		-> render
			-> componentDidUpdate

实际上此时，对于Inner来讲，它在State钩子函数的render环节，我们就开始了一轮Props的更新生命周期函数。

在这个环节中，有几个特别关键的地方值得深思(理解它有助于深入理解React)。

  • 『jsx到js的转换』 环节里面jsx 转换为React.createElement的结构，和提到的相关的注意项
  • React.createElement嵌套的层级问题，它不仅仅可以从TopLevelWrapper开始渲染，实际上，他可以从任意中间的任何一个React.createElement开始渲染
  • 为什么说React是最小局部更新？除了调度和算法的作用，React.createElement嵌套结构可以从任何环节开始向下级渲染，是一个非常关键的机制，它极大程度上缩小了需要更新到DOM的数据。

以上可能是最重要的，如果没有理解上面的那么值得卡在这里琢磨。

After 正式开始

如果上面的准备就绪了可以继续下面的了。回顾一下，当state触发的生命周期开始render环节的时候，会执行ReactCompositeComponent line 973的代码这里仅仅是比State多一个componentWillReceiveProps。

1
this._updateRenderedComponent(transaction, unmaskedContext);

这里直接在测试用例的attachedListener()这一行打一个断点,待它停住以后，在render里面打一个断点，最后点执行。当它再次停住以后，这样我们就捕获了state之后的render环节。最后将光标定位到ReactCompositeComponent line 973，点run to corsur，我们就对程序进行了精准的捕获。

接下来它的调用栈:

1
2
3
4
ReactCompositeComponent._updateRenderedComponent
	-> ReactReconciler.receiveComponent
		-> internalInstance.receiveComponent
			-> ReactCompositeComponent.updateComponent

到这个环节生命周期函数的调用就简单多了。先看整体的生命周期:

1
2
3
4
5
componentWillReceiveProps
	->shouldComponentUpdate
		-> componentWillUpdate
			-> render
				-> componentDidUpdate

componentWillReceiveProps

ReactCompositeComponent.updateComponent内, ReactCompositeComponent.js line 823-833

1
2
3
4
5
6
7
if (willReceive && inst.componentWillReceiveProps) {
  if (__DEV__) {
	// 略
  } else {
    inst.componentWillReceiveProps(nextProps, nextContext);
  }
}

shouldComponentUpdate

ReactCompositeComponent.updateComponent内, ReactCompositeComponent.js line 838-860

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
if (!this._pendingForceUpdate) {
  if (inst.shouldComponentUpdate) {
    if (__DEV__) {
	  // 略
    } else {
      shouldUpdate = inst.shouldComponentUpdate(
        nextProps,
        nextState,
        nextContext,
      );
    }
  } else {
    if (this._compositeType === CompositeTypes.PureClass) {
      shouldUpdate =
        !shallowEqual(prevProps, nextProps) ||
        !shallowEqual(inst.state, nextState);
    }
  }
}

componentWillUpdate

ReactCompositeComponent.updateComponent 调用了ReactCompositeComponent._performComponentUpdate。

这个生命周期执行在这个函数内, 代码定位line955-965

1
2
3
4
5
6
7
if (inst.componentWillUpdate) {
  if (__DEV__) {
    // 略
  } else {
    inst.componentWillUpdate(nextProps, nextState, nextContext);
  }
}

render

ReactCompositeComponent._performComponentUpdate内

1
this._updateRenderedComponent(transaction, unmaskedContext);

componentDidUpdate

ReactCompositeComponent._performComponentUpdate内

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
if (hasComponentDidUpdate) {
  if (__DEV__) {
	// 略
  } else {
    transaction
      .getReactMountReady()
      .enqueue(
        inst.componentDidUpdate.bind(
          inst,
          prevProps,
          prevState,
          prevContext,
        ),
        inst,
      );
  }
}

卸载

卸载这个环节的生命周期就比较好理解了。

我们的render环节会调用一个ReactCompositeComponent._updateRenderedComponent。

这个函数又一个非常显眼的逻辑分支。

1
2
3
4
5
6
7
8
9
10
11
12
if (shouldUpdateReactComponent(prevRenderedElement, nextRenderedElement)) {
    ReactReconciler.receiveComponent(
        prevComponentInstance,
        nextRenderedElement,
        transaction,
        this._processChildContext(context),
    );
} else {
    var oldHostNode = ReactReconciler.getHostNode(prevComponentInstance);
    ReactReconciler.unmountComponent(prevComponentInstance, false);
    // 略
}

ReactReconciler.receiveComponent这个方法里面调用了internalInstance.unmountComponent(safely),它可以对各种组件实例的unmountComponent进行调用。

常规来说，我们最常用到的是是ReactCompositeComponent.unmountComponent。其中内容不再赘述。

总结

至此整个React的声明周期分析也算完整了。我们整体的分析了初次渲染、更新、卸载过程中的生命周期函数式如何被调用、在哪里调用，以及涉及到相关知识点，乃至如何进行方便的调试。