阅读 626

对React一些原理的理解

随着项目开发的深入,不可避免了遇到了一些问题。刚开始出现问题时很懵,不知道该怎么解决,原因就是对React的原理理解的不够透彻,不知道问题出在哪。在解决问题的过程中,也逐渐深入了解了React的一些原理,这篇文章就来分享一下我对React一些原理的理解。

注意 这篇文章并不是教程,只是我对React原理的一些个人理解,欢迎与我一起讨论。文章不对的地方,还请读者费心指出^-^

概述

本文是《使用React技术栈的一些收获》系列文章的第二篇(第一篇在这里,介绍如何开始构建React大型项目),简单介绍了React一些原理,包括React合成事件系统、组件的生命周期以及setState()

React合成事件系统

React快速的原因之一就是React很少直接操作DOM,浏览器事件也是一样。原因是太多的浏览器事件会占用很大内存。

React为此自己实现了一套合成系统,在DOM事件体系基础上做了很大改进,减少了内存消耗,简化了事件逻辑,最大化解决浏览器兼容问题。

其基本原理就是,所有在JSX声明的事件都会被委托在顶层document节点上,并根据事件名和组件名存储回调函数(listenerBank)。每次当某个组件触发事件时,在document节点上绑定的监听函数(dispatchEvent)就会找到这个组件和它的所有父组件(ancestors),对每个组件创建对应React合成事件(SyntheticEvent)并批处理(runEventQueueInBatch(events)),从而根据事件名和组件名调用(invokeGuardedCallback)回调函数。

因此,如果你采用下面这种写法,并且这样的P标签有很多个:

 listView = list.map((item,index) => {
    return (        
        <p onClick={this.handleClick} key={item.id}>{item.text}</p>
  )})复制代码

That's OK,React帮你实现了事件委托。我之前因为不了解React合成事件系统,还显示的使用了事件委托,现在看来是多此一举的。

由于React合成事件系统模拟事件冒泡的方法是构建一个自己及父组件队列,因此也带来一个问题,合成事件不能阻止原生事件,原生事件可以阻止合成事件。用 event.stopPropagation() 并不能停止事件传播,应该使用 event.preventDefault()

如果你想详细了解React合成事件系统,移步blog.csdn.net/u013510838/…

组件的生命周期(以父子组件为例)

为了搞清楚组件生命周期,构造一个父组件包含子组件并且重写各生命周期函数的场景:

 class Child extends React.Component {
  constructor() {
    super()
    console.log('Child was created!')
  }
  componentWillMount(){
    console.log('Child componentWillMount!')
  }
  componentDidMount(){
    console.log('Child componentDidMount!')
  }
  componentWillReceiveProps(nextProps){
    console.log('Child componentWillReceiveProps:'+nextProps.data )
  }
  shouldComponentUpdate(nextProps, nextState){
    console.log('Child shouldComponentUpdate:'+ nextProps.data)
    return true
  }
  componentWillUpdate(nextProps, nextState){
    console.log('Child componentWillUpdate:'+ nextProps.data)
  }
  componentDidUpdate(){
    console.log('Child componentDidUpdate')
  }
  render() {
    console.log('render Child!')
    return (      
      <h1>Child recieve props: {this.props.data}</h1>      
    );
  }
}

class Father extends React.Component {
  // ... 前面跟子组件一样
  handleChangeState(){
    this.setState({randomData: Math.floor(Math.random()*50)})
  }
  render() {
    console.log('render Father!')
    return (
      <div>
        <Child data={this.state.randomData} />
        <h1>Father State: { this.state.randomData}</h1>      
        <button onClick={this.handleChangeState}>切换状态</button>
      </div>
    );
  }
}

React.render(
  <Father />,
  document.getElementById('root')
);复制代码

结果如下:刚开始![Alt text](https://ooo.0o0.ooo/2017/06/28/595398ee54b1a.png)

调用父组件的setState后:![Alt text](https://ooo.0o0.ooo/2017/06/28/595398ff8a44a.png)

在Jsbin上试试看

有一张图能说明这之间的流程(图片来源):![Alt text](https://ooo.0o0.ooo/2017/06/28/595398b92d076.png)

setState并不奇怪

有一个能反映问题的场景:

 ...
state = {
	count: 0
}
componentDidMount() {
  this.setState({count: this.state.count + 1})
  this.setState({count: this.state.count + 1})
  this.setState({count: this.state.count + 1})
}
...复制代码

看起来state.count被增加了三次,但结果是增加了一次。这并不奇怪:

React快的原因之一就是,在执行this.setState()时,React没有忙着立即更新state,只是把新的state存到一个队列(batchUpdate)中。上面三次执行setState只是对传进去的对象进行了合并,然后再统一处理(批处理),触发重新渲染过程,因此只重新渲染一次,结果只增加了一次。这样做是非常明智的,因为在一个函数里调用多个setState是常见的,如果每一次调用setState都要引发重新渲染,显然不是最佳实践。React官方文档里也说了:

Think of setState() as a request rather than an immediate command to update the component.

setState() 看作是重新render的一次请求而不是立刻更新组件的指令。

那么调用this.setState()后什么时候this.state才会更新?答案是即将要执行下一次的render函数时。

这之间发生了什么?setState调用后,React会执行一个事务(Transaction),在这个事务中,React将新state放进一个队列中,当事务完成后,React就会刷新队列,然后启动另一个事务,这个事务包括执行 shouldComponentUpdate 方法来判断是否重新渲染,如果是,React就会进行state合并(state merge),生成新的state和props;如果不是,React仍然会更新this.state,只不过不会再render了。

开发人员对setState感到奇怪的原因可能就是按照上述写法并不能产生预期效果,但幸运的是我们改动一下就可以实现上述累加效果:这归功于setState可以接受函数作为参数:

setState(updater, [callback])

 ...
state = {
	score: 0
}
componentDidMount() {
    this.setState( (prevState) => ({score : prevState.score + 1}) )
    this.setState( (prevState) => ({score : prevState.score + 1}) )
    this.setState( (prevState) => ({score : prevState.score + 1}) )
  } 复制代码

}这个updater可以为函数,该函数接受该组件前一刻的 state 以及当前的 props 作为参数,计算和返回下一刻的 state。

你会发现达到增加三次的目的了: 在Jsbin上试试看

这是因为React会把setState里传进去的函数放在一个任务队列里,React 会依次调用队列中的函数,传递给它们前一刻的 state。

另外,不知道你在jsbin上的代码上注意到没有,调用setStateconsole.log(this.state.score)输出仍然为0,也就是this.state并未改变,并且只render了一次。

总结

学习一个框架或者工具,我觉得应该了解以下几点:

  1. 它是什么?能做什么?

  2. 它存在的理由是什么?解决了什么样的问题、满足了什么样的需求?

  3. 它的适用场景是什么?优缺点是什么?

  4. 它怎么用?最佳实践是什么?

  5. 它的原理是什么?

  6. ...

通过对React一些原理的简单了解,就懂得了React为什么这么快速的原因之一,也会在问题出现时知道错在什么地方,知道合理的解决方案。


关注下面的标签,发现更多相似文章
评论