React学习之路 API原理篇 一
在React中常使用的API原理
setState的原理,为什么是异步的?
dan神给出的两个理由:
(1)保证内部数据的统一
console.log(this.state.value) // 0this.setState({ value: this.state.value + 1 });
console.log(this.state.value) // 1
this.setState({ value: this.state.value + 1 });
console.log(this.state.value) // 2
在上面一段代码中,在state中,setState同步是可以的。但是到了props传值时,也同步setState的模式就会有问题。
console.log(this.props.value) // 0this.props.onIncrement();
console.log(this.props.value) // 0
this.props.onIncrement();
console.log(this.props.value) // 0
父节点传递给子节点的props是不能同步刷新的,setState同步re-render是很差的机制,这一点已经成为了共识。无法同步re-render,就无法同步刷新this.props,无法保证子节点拿到的props和父节点的state一致。破坏了内部数据统一。
(2)setState异步更新状态使得并发更新组件成为可能
首先我们在这里讨论是否同步刷新state有一个前提那就是我们默认更新节点是遵循特定的顺序的。但是按默认顺序更新组件在以后的react中可能就变了。
在以后的react的更新机制中,我们可能加入setState优先级这一概念。
举个例子:比如你现在正在打字,那么TextBox组件需要实时的刷新。但是当你在输入的时候,来了一个信息,这个时候,可能让信息延后刷新可能更符合交互。
异步rendering不仅仅是性能上的优化,而且这可能是react组件模型在发生的根本性的改变。
当然这个理由,可能是react发展的一个方向,目前还没有实现。
总结:
① setState 只在合成时间啊你和钩子函数中是“异步”的,在原生时间事件和setTimeout 中都是同步的。
② setState 的“异步”并不是说内部由异步代码实现,其实本身执行的过程和代码都是同步的,只是在合成事件和钩子函数的调用顺序在更新之前,导致在合成事件和钩子函数中没法立马拿到更新后的值,形成了所有的“异步“,解决这个问题,setState中接受第二个参数callback,在此回调函数中可以拿到更新后的值。
③ setState的批量更新优化也是建立在”异步“(合成事件 钩子函数)之上的,在原生事件和setTimeout 中不会批量更新,在”异步“中如果对同一个值进行多次setState,setState的批量更新策略会对其进行覆盖,取最后一次的执行的,如果是同时setState多个不同的值,在更新时会对其进行合并批量更新。
React 的生命周期
在React 的开发中,我接触过的一些同事来看,对生命周期的理解并不是很明确。何时会re-render。
在组件初始化后进入componentWillMount,这时还是虚拟DOM,render后才会有真实DOM。这时组件处在稳定的状态等待操作改变state进行re-render。
此时进行操作修改state,即使代码中未写shouldComponentUpdate,但react还是会走完下边的生命周期,react会去比较该修改后的state 和原来的state 是否一致,一致返回false,就停止不往下走,就不进行re-render;否则返回true继续往下走,走到render 进行re-render 进行重新渲染视图。
以上是 React学习之路 API原理篇 一 的全部内容, 来源链接: utcz.com/z/382892.html