(1)Redux 和 Vuex区别
通俗点理解就是,vuex 弱化 dispatch,通过commit进行 store状态的一次更变;取消了action概念,不必传入特定的 action形式进行指定变更;弱化reducer,基于commit参数直接对数据进行转变,使得框架更加简易;
(2)共同思想
本质上∶ redux与vuex都是对mvvm思想的服务,将数据从视图中抽离的一种方案。
(1)setState() setState()用于设置状态对象,其语法如下:
setState(object nextState[, function callback])
合并nextState和当前state,并重新渲染组件。setState是React事件处理函数中和请求回调函数中触发UI更新的主要方法。
(2)replaceState() replaceState()方法与setState()类似,但是方法只会保留nextState中状态,原state不在nextState中的状态都会被删除。其语法如下:
replaceState(object nextState[, function callback])
总结: setState 是修改其中的部分状态,相当于 Object.assign,只是覆盖,不会减少原来的状态。而replaceState 是完全替换原来的状态,相当于赋值,将原来的 state 替换为另一个对象,如果新状态属性减少,那么 state 中就没有这个状态了。
React为我们提供了PropTypes以供验证使用。当我们向Props传入的数据无效(向Props传入的数据类型和验证的数据类型不符)就会在控制台发出警告信息。它可以避免随着应用越来越复杂从而出现的问题。并且,它还可以让程序变得更易读。
import PropTypes from 'prop-types';
class Greeting extends React.Component {
render() {
return (
<h1>Hello, {this.props.name}</h1>
);
}
}
Greeting.propTypes = {
name: PropTypes.string
};
当然,如果项目汇中使用了TypeScript,那么就可以不用PropTypes来校验,而使用TypeScript定义接口来校验props。
使用了装饰模式,高阶组件的运用:
function withWindowWidth(BaseComponent) {
class DerivedClass extends React.Component {
state = {
windowWidth: window.innerWidth,
}
onResize = () => {
this.setState({
windowWidth: window.innerWidth,
})
}
componentDidMount() {
window.addEventListener('resize', this.onResize)
}
componentWillUnmount() {
window.removeEventListener('resize', this.onResize);
}
render() {
return <BaseComponent {...this.props} {...this.state}/>
}
}
return DerivedClass;
}
const MyComponent = (props) => {
return <div>Window width is: {props.windowWidth}</div>
};
export default withWindowWidth(MyComponent);
装饰模式的特点是不需要改变 被装饰对象 本身,而只是在外面套一个外壳接口。JavaScript 目前已经有了原生装饰器的提案,其用法如下:
@testable
class MyTestableClass {
}
这三者是目前react解决代码复用的主要方式:
(1)HOC 官方解释∶
高阶组件(HOC)是 React 中用于复用组件逻辑的一种高级技巧。HOC 自身不是 React API 的一部分,它是一种基于 React 的组合特性而形成的设计模式。
简言之,HOC是一种组件的设计模式,HOC接受一个组件和额外的参数(如果需要),返回一个新的组件。HOC 是纯函数,没有副作用。
// hoc的定义
function withSubscription(WrappedComponent, selectData) {
return class extends React.Component {
constructor(props) {
super(props);
this.state = {
data: selectData(DataSource, props)
};
}
// 一些通用的逻辑处理
render() {
// ... 并使用新数据渲染被包装的组件!
return <WrappedComponent data={this.state.data} {...this.props} />;
}
};
// 使用
const BlogPostWithSubscription = withSubscription(BlogPost,
(DataSource, props) => DataSource.getBlogPost(props.id));
HOC的优缺点∶
(2)Render props 官方解释∶
"render prop"是指一种在 React 组件之间使用一个值为函数的 prop 共享代码的简单技术
具有render prop 的组件接受一个返回React元素的函数,将render的渲染逻辑注入到组件内部。在这里,"render"的命名可以是任何其他有效的标识符。
// DataProvider组件内部的渲染逻辑如下
class DataProvider extends React.Components {
state = {
name: 'Tom'
}
render() {
return (
<div>
<p>共享数据组件自己内部的渲染逻辑</p>
{ this.props.render(this.state) } </div>
);
}
}
// 调用方式
<DataProvider render={data => (
<h1>Hello {data.name}</h1>
)}/>
由此可以看到,render props的优缺点也很明显∶
(3)Hooks 官方解释∶
Hook是 React 16.8 的新增特性。它可以让你在不编写 class 的情况下使用 state 以及其他的 React 特性。通过自定义hook,可以复用代码逻辑。
// 自定义一个获取订阅数据的hook
function useSubscription() {
const data = DataSource.getComments();
return [data];
}
//
function CommentList(props) {
const {data} = props;
const [subData] = useSubscription();
...
}
// 使用
<CommentList data='hello' />
以上可以看出,hook解决了hoc的prop覆盖的问题,同时使用的方式解决了render props的嵌套地狱的问题。hook的优点如下∶
需要注意的是:hook只能在组件顶层使用,不可在分支语句中使用。、
(1)props
props是一个从外部传进组件的参数,主要作为就是从父组件向子组件传递数据,它具有可读性和不变性,只能通过外部组件主动传入新的props来重新渲染子组件,否则子组件的props以及展现形式不会改变。
(2)state
state的主要作用是用于组件保存、控制以及修改自己的状态,它只能在constructor中初始化,它算是组件的私有属性,不可通过外部访问和修改,只能通过组件内部的this.setState来修改,修改state属性会导致组件的重新渲染。
(3)区别
在 HTML 中,表单元素如 <input>
、<textarea>
和<select>
通常维护自己的状态,并根据用户输入进行更新。当用户提交表单时,来自上述元素的值将随表单一起发送。
而 React 的工作方式则不同。包含表单的组件将跟踪其状态中的输入值,并在每次回调函数(例如onChange
)触发时重新渲染组件,因为状态被更新。以这种方式由 React 控制其值的输入表单元素称为受控组件。
整个应用的state被存储在一个object tree中,并且这个object tree 之存在唯一一个store中
唯一改变state的方式是触发action,action是一个用于描述已经发生时间的对象,这个保证了视图和网络请求都不能直接修改state,相反他们只能表达想要修改的意图
相同点: 组件是 React 可复用的最小代码片段,它们会返回要在页面中渲染的 React 元素。也正因为组件是 React 的最小编码单位,所以无论是函数组件还是类组件,在使用方式和最终呈现效果上都是完全一致的。
我们甚至可以将一个类组件改写成函数组件,或者把函数组件改写成一个类组件(虽然并不推荐这种重构行为)。从使用者的角度而言,很难从使用体验上区分两者,而且在现代浏览器中,闭包和类的性能只在极端场景下才会有明显的差别。所以,基本可认为两者作为组件是完全一致的。
不同点:
通过 redux 和 react context 配合使用,并借助高阶函数,实现了 react-redux
在一个组件传入的props更新时重新渲染该组件常用的方法是在componentWillReceiveProps
中将新的props更新到组件的state中(这种state被成为派生状态(Derived State)),从而实现重新渲染。React 16.3中还引入了一个新的钩子函数getDerivedStateFromProps
来专门实现这一需求。
(1)componentWillReceiveProps(已废弃)
在react的componentWillReceiveProps(nextProps)生命周期中,可以在子组件的render函数执行前,通过this.props获取旧的属性,通过nextProps获取新的props,对比两次props是否相同,从而更新子组件自己的state。
这样的好处是,可以将数据请求放在这里进行执行,需要传的参数则从componentWillReceiveProps(nextProps)中获取。而不必将所有的请求都放在父组件中。于是该请求只会在该组件渲染时才会发出,从而减轻请求负担。
(2)getDerivedStateFromProps(16.3引入)
这个生命周期函数是为了替代componentWillReceiveProps
存在的,所以在需要使用componentWillReceiveProps
时,就可以考虑使用getDerivedStateFromProps
来进行替代。
两者的参数是不相同的,而getDerivedStateFromProps
是一个静态函数,也就是这个函数不能通过this访问到class的属性,也并不推荐直接访问属性。而是应该通过参数提供的nextProps以及prevState来进行判断,根据新传入的props来映射到state。
需要注意的是,如果props传入的内容不需要影响到你的state,那么就需要返回一个null,这个返回值是必须的,所以尽量将其写到函数的末尾:
static getDerivedStateFromProps(nextProps, prevState) {
const {type} = nextProps;
// 当传入的type发生变化的时候,更新state
if (type !== prevState.type) {
return {
type,
};
}
// 否则,对于state不进行任何操作
return null;
}
PureComponent表示一个纯组件,可以用来优化React程序,减少render函数执行的次数,从而提高组件的性能。
在React中,当prop或者state发生变化时,可以通过在shouldComponentUpdate生命周期函数中执行return false来阻止页面的更新,从而减少不必要的render执行。React.PureComponent会自动执行 shouldComponentUpdate。
不过,pureComponent中的 shouldComponentUpdate() 进行的是浅比较,也就是说如果是引用数据类型的数据,只会比较不是同一个地址,而不会比较这个地址里面的数据是否一致。浅比较会忽略属性和或状态突变情况,其实也就是数据引用指针没有变化,而数据发生改变的时候render是不会执行的。如果需要重新渲染那么就需要重新开辟空间引用数据。PureComponent一般会用在一些纯展示组件上。
使用pureComponent的好处:当组件更新时,如果组件的props或者state都没有改变,render函数就不会触发。省去虚拟DOM的生成和对比过程,达到提升性能的目的。这是因为react自动做了一层浅比较。
<link> <route></route>
类组件中的优化手段
PureComponent
作为基类。React.memo
高阶函数包装组件。shouldComponentUpdate
生命周期函数来自定义渲染逻辑。方法组件中的优化手段
useMemo
。useCallBack
。其他方式
Suspense
和 lazy 进行懒加载,例如:import React, { lazy, Suspense } from "react";
export default class CallingLazyComponents extends React.Component {
render() {
var ComponentToLazyLoad = null;
if (this.props.name == "Mayank") {
ComponentToLazyLoad = lazy(() => import("./mayankComponent"));
} else if (this.props.name == "Anshul") {
ComponentToLazyLoad = lazy(() => import("./anshulComponent"));
}
return (
<div>
<h1>This is the Base User: {this.state.name}</h1>
<Suspense fallback={<div>Loading...</div>}>
<ComponentToLazyLoad />
</Suspense>
</div>
)
}
}
React 基于虚拟 DOM 和高效 Diff 算法的完美配合,实现了对 DOM 最小粒度的更新。大多数情况下,React 对 DOM 的渲染效率足以业务日常。但在个别复杂业务场景下,性能问题依然会困扰我们。此时需要采取一些措施来提升运行性能,其很重要的一个方向,就是避免不必要的渲染(Render)。这里提下优化的点:
在 React 类组件中,可以利用 shouldComponentUpdate或者 PureComponent 来减少因父组件更新而触发子组件的 render,从而达到目的。shouldComponentUpdate 来决定是否组件是否重新渲染,如果不希望组件重新渲染,返回 false 即可。
在函数组件中,并没有 shouldComponentUpdate 这个生命周期,可以利用高阶组件,封装一个类似 PureComponet 的功能
React.memo 是 React 16.6 新的一个 API,用来缓存组件的渲染,避免不必要的更新,其实也是一个高阶组件,与 PureComponent 十分类似,但不同的是, React.memo只能用于函数组件。
react
和 vue
都是基于 vdom
的前端框架,之所以用 vdom
是因为可以精准的对比关心的属性,而且还可以跨平台渲染vdom
,而是通过 jsx
这种接近 html
语法的 DSL
,编译产生 render function
,执行后产生 vdom
vdom
的渲染就是根据不同的类型来用不同的 dom api
来操作 dom
vdom
。class
组件就创建实例然后调用 render
方法拿到 vdom
。vue
的那种 option
对象的话,就调用 render
方法拿到 vdom
vdom
产生逻辑的封装,函数
、class
、option
对象甚至其他形式都可以react
和 vue
最大的区别在状态管理方式上,vue
是通过响应式,react
是通过 setState
的 api
。我觉得这个是最大的区别,因为它导致了后面 react
架构的变更react
的 setState
的方式,导致它并不知道哪些组件变了,需要渲染整个 vdom
才行。但是这样计算量又会比较大,会阻塞渲染,导致动画卡顿。所以 react
后来改造成了 fiber
架构,目标是可打断的计算dom
了,所以把渲染分为了 render
和 commit
两个阶段,render
阶段通过 schedule
调度来进行 reconcile
,也就是找到变化的部分,创建 dom
,打上增删改的 tag
,等全部计算完之后,commit
阶段一次性更新到 dom
vdom
也被改造成了 fiber
的数据结构,有了 parent
、sibling
的信息fiber
既指这种链表的数据结构,又指这个 render
、commit
的流程reconcile
阶段每次处理一个 fiber
节点,处理前会判断下 shouldYield
,如果有更高优先级的任务,那就先执行别的commit
阶段不用再次遍历 fiber
树,为了优化,react
把有 effectTag
的 fiber
都放到了 effectList
队列中,遍历更新即可dom
操作前,会异步调用 useEffect
的回调函数,异步是因为不能阻塞渲染dom
操作之后,会同步调用 useLayoutEffect
的回调函数,并且更新 ref
commit
阶段又分成了 before mutation
、mutation
、layout
这三个小阶段,就对应上面说的那三部分理解了
vdom
、jsx
、组件本质
、fiber
、render(reconcile + schedule)
+commit(before mutation、mutation、layout)
的渲染流程,就算是对react
原理有一个比较深的理解
下面展开分析
为什么 react
和 vue
都要基于 vdom
呢?直接操作真实 dom
不行么?
考虑下这样的场景:
dom api
对真实 dom
做增删改,如果已经渲染了一个 dom
,后来要更新,那就要遍历它所有的属性,重新设置,比如 id
、clasName
、onclick
等。dom
的属性是很多的:JS
对象表示不就行了?vdom
,是它的第一个好处。vdom
之后,就没有和 dom
强绑定了,可以渲染到别的平台,比如 native
、canvas
等等。vdom
的第二个好处。vdom
就是用 JS
对象表示最终渲染的 dom
的,比如:{
type: 'div',
props: {
id: 'aaa',
className: ['bbb', 'ccc'],
onClick: function() {}
},
children: []
}
然后用渲染器把它渲染出来,但是要让开发去写这样的 vdom
么?那肯定不行,这样太麻烦了,大家熟悉的是 html
那种方式,所以我们要引入编译的手段
dsl
是 domain specific language
,领域特定语言的意思,html
、css
都是 web
领域的 dsl
vdom
太麻烦了,所以前端框架都会设计一套 dsl
,然后编译成 render function
,执行后产生 vdom
。vue
和 react
都是这样这套 dsl 怎么设计呢?前端领域大家熟悉的描述
dom
的方式是html
,最好的方式自然是也设计成那样。所以vue
的template
,react
的jsx
就都是这么设计的。vue
的template compiler
是自己实现的,而react
的jsx
的编译器是babel
实现的,是两个团队合作的结果。
编译成 render function
后再执行就是我们需要的 vdom
。接下来渲染器把它渲染出来就行了。那渲染器怎么渲染 vdom
的呢?
渲染 vdom
也就是通过 dom api
增删改 dom
。比如一个 div
,那就要 document.createElement
创建元素,然后 setAttribute
设置属性,addEventListener
设置事件监听器。如果是文本,那就要 document.createTextNode
来创建。所以说根据 vdom
类型的不同,写个 if else
,分别做不同的处理就行了。没错,不管 vue
还是 react
,渲染器里这段 if else
是少不了的:
switch (vdom.tag) {
case HostComponent:
// 创建或更新 dom
case HostText:
// 创建或更新 dom
case FunctionComponent:
// 创建或更新 dom
case ClassComponent:
// 创建或更新 dom
}
react
里是通过tag
来区分vdom
类型的,比如HostComponent
就是元素,HostText
就是文本,FunctionComponent
、ClassComponent
就分别是函数组件和类组件。那么问题来了,组件怎么渲染呢?这就涉及到组件的原理了:
我们的目标是通过
vdom
描述界面,在react
里会使用jsx
。这样的jsx
有的时候是基于state
来动态生成的。如何把state
和jsx
关联起来呢?封装成function
、class
或者option
对象的形式。然后在渲染的时候执行它们拿到vdom
就行了。
这就是组件的实现原理:
switch (vdom.tag) {
case FunctionComponent:
const childVdom = vdom.type(props);
render(childVdom);
//...
case ClassComponent:
const instance = new vdom.type(props);
const childVdom = instance.render();
render(childVdom);
//...
}
如果是函数组件,那就传入 props
执行它,拿到 vdom
之后再递归渲染。如果是 class
组件,那就创建它的实例对象,调用 render
方法拿到 vdom
,然后递归渲染。所以,大家猜到 vue
的 option
对象的组件描述方式怎么渲染了么?
{
data: {},
props: {}
render(h) {
return h('div', {}, '');
}
}
没错,就是执行下 render
方法就行:
const childVdom = option.render();
render(childVdom);
大家可能平时会写单文件组件 sfc
的形式,那个会有专门的编译器,把 template
编译成 render function
,然后挂到 option 对象的
render` 方法上
所以组件本质上只是对产生 vdom
的逻辑的封装,函数的形式、option
对象的形式、class
的形式都可以。就像 vue3
也有了函数组件一样,组件的形式并不重要。基于 vdom
的前端框架渲染流程都差不多,vue 和 react 很多方面是一样的。但是管理状态的方式不一样,vue
有响应式,而 react
则是 setState
的 api
的方式。真说起来,vue 和 react 最大的区别就是状态管理方式的区别,因为这个区别导致了后面架构演变方向的不同。
react
是通过setState
的api
触发状态更新的,更新以后就重新渲染整个vdom
。而vue
是通过对状态做代理,get
的时候收集以来,然后修改状态的时候就可以触发对应组件的render
了。
有的同学可能会问,为什么 react
不直接渲染对应组件呢?
想象一下这个场景:
父组件把它的 setState
函数传递给子组件,子组件调用了它。这时候更新是子组件触发的,但是要渲染的就只有那个组件么?明显不是,还有它的父组件。同理,某个组件更新实际上可能触发任意位置的其他组件更新的。所以必须重新渲染整个 vdom
才行。
那 vue
为啥可以做到精准的更新变化的组件呢?因为响应式的代理呀,不管是子组件、父组件、还是其他位置的组件,只要用到了对应的状态,那就会被作为依赖收集起来,状态变化的时候就可以触发它们的 render
,不管是组件是在哪里的。这就是为什么 react
需要重新渲染整个 vdom
,而 vue
不用。这个问题也导致了后来两者架构上逐渐有了差异。
react15
的时候,和 vue
的渲染流程还是很像的,都是递归渲染 vdom
,增删改 dom
就行。但是因为状态管理方式的差异逐渐导致了架构的差异。react
的 setState
会渲染整个 vdom
,而一个应用的所有 vdom
可能是很庞大的,计算量就可能很大。浏览器里 js
计算时间太长是会阻塞渲染的,会占用每一帧的动画、重绘重排的时间,这样动画就会卡顿。作为一个有追求的前端框架,动画卡顿肯定是不行的。但是因为 setState
的方式只能渲染整个 vdom
,所以计算量大是不可避免的。那能不能把计算量拆分一下,每一帧计算一部分,不要阻塞动画的渲染呢?顺着这个思路,react
就改造为了 fiber
架构。优化的目标是打断计算,分多次进行,但现在递归的渲染是不能打断的,有两个方面的原因导致的:
第一个问题的解决还是容易想到的:
dom
了,只找到变化的部分,打个增删改的标记,创建好 dom
,等全部计算完了一次性更新到 dom
就好了。react
把渲染流程分为了两部分: render
和 commit
。render
阶段会找到 vdom
中变化的部分,创建 dom
,打上增删改的标记,这个叫做 reconcile
,调和。reconcile
是可以打断的,由 schedule
调度。dom
,叫做 commit
。react
就把之前的和 vue
很像的递归渲染,改造成了 render(reconcile + schdule) + commit
两个阶段的渲染。react
和 vue
架构上的差异才大了起来。第二个问题,如何打断以后还能找到父节点、其他兄弟节点呢?
现有的 vdom
是不行的,需要再记录下 parent
、silbing
的信息。所以 react
创造了 fiber
的数据结构。
children
信息外,额外多了 sibling
、return
,分别记录着兄弟节点、父节点的信息。fiber
。(fiber
既是一种数据结构,也代表 render + commit
的渲染流程) react
会先把 vdom
转换成 fiber
,再去进行 reconcile
,这样就是可打断的了。function workLoop() {
while (wip) {
performUnitOfWork();
}
if (!wip && wipRoot) {
commitRoot();
}
}
react
里有一个 workLoop 循环,每次循环做一个 fiber
的 reconcile
,当前处理的 fiber
会放在 workInProgress
这个全局变量上。wip
为空了,那就执行 commit
阶段,把 reconcile
的结果更新到 dom
。fiber
的 reconcile
是根据类型来做的不同处理。当处理完了当前 fiber
节点,就把 wip
指向 sibling
、return
来切到下个 fiber
节点。:function performUnitOfWork() {
const { tag } = wip;
switch (tag) {
case HostComponent:
updateHostComponent(wip);
break;
case FunctionComponent:
updateFunctionComponent(wip);
break;
case ClassComponent:
updateClassComponent(wip);
break;
case Fragment:
updateFragmentComponent(wip);
break;
case HostText:
updateHostTextComponent(wip);
break;
default:
break;
}
if (wip.child) {
wip = wip.child;
return;
}
let next = wip;
while (next) {
if (next.sibling) {
wip = next.sibling;
return;
}
next = next.return;
}
wip = null;
}
函数组件和
class
组件的reconcile
和之前讲的一样,就是调用render
拿到vdom
,然后继续处理渲染出的vdom
:
function updateClassComponent(wip) {
const { type, props } = wip;
const instance = new type(props);
const children = instance.render();
reconcileChildren(wip, children);
}
function updateFunctionComponent(wip) {
renderWithHooks(wip);
const { type, props } = wip;
const children = type(props);
reconcileChildren(wip, children);
}
reconcile
,那每次处理之前判断一下是不是有更高优先级的任务,就能实现打断了。fiber
节点的 reconcile
之前,都先调用下 shouldYield
方法:function workLoop() {
while (wip && shouldYield()) {
performUnitOfWork();
}
if (!wip && wipRoot) {
commitRoot();
}
}
shouldYiled
方法就是判断待处理的任务队列有没有优先级更高的任务,有的话就先处理那边的 fiber
,这边的先暂停一下。fiber
架构的 reconcile
可以打断的原理。通过 fiber
的数据结构,加上循环处理前每次判断下是否打断来实现的。render
阶段(reconcile + schedule
),接下来就进入 commit
阶段了。reconcile
阶段并不会真正操作 dom
,只会创建 dom
然后打个 effectTag
的增删改标记。commit
阶段就根据标记来更新 dom
就可以了。commit
阶段要再遍历一次 fiber
来查找有 effectTag
的节点,更新 dom
么?effectList
。react
会在 commit
阶段遍历 effectList
,根据 effectTag
来增删改 dom
。dom
创建前后就是 useEffect
、useLayoutEffect
还有一些函数组件的生命周期函数执行的时候。useEffect
被设计成了在 dom
操作前异步调用,useLayoutEffect
是在 dom
操作后同步调用。dom
了,这时候如果来了个 effect
同步执行,计算量很大,那不是把 fiber 架构带来的优势有毁了么?effect
是异步的,不会阻塞渲染。useLayoutEffect
,顾名思义是想在这个阶段拿到一些布局信息的,dom 操作完以后就可以了,而且都渲染完了,自然也就可以同步调用了。react
把 commit
阶段也分成了 3
个小阶段。before mutation
、mutation
、layout
。mutation
就是遍历 effectList
来更新 dom
的。before mutation
,会异步调度 useEffect
的回调函数。layout
阶段了,因为这个阶段已经可以拿到布局信息了,会同步调用 useLayoutEffect
的回调函数。而且这个阶段可以拿到新的 dom
节点,还会更新下 ref
。react
的新架构,render
、commit
两大阶段都干了什么就理清了。该方法当props
发生变化时执行,初始化render
时不执行,在这个回调函数里面,你可以根据属性的变化,通过调用this.setState()
来更新你的组件状态,旧的属性还是可以通过this.props
来获取,这里调用更新状态是安全的,并不会触发额外的render
调用。
使用好处: 在这个生命周期中,可以在子组件的render函数执行前获取新的props,从而更新子组件自己的state。 可以将数据请求放在这里进行执行,需要传的参数则从componentWillReceiveProps(nextProps)中获取。而不必将所有的请求都放在父组件中。于是该请求只会在该组件渲染时才会发出,从而减轻请求负担。
componentWillReceiveProps在初始化render的时候不会执行,它会在Component接受到新的状态(Props)时被触发,一般用于父组件状态更新时子组件的重新渲染。
<>
<span id="name" ref={this.spanRef}>{this.state.title}</span>
<span>{ this.spanRef.current ? '有值' : '无值' }</span>
</>
不可以,render 阶段 DOM 还没有生成,无法获取 DOM。DOM 的获取需要在 pre-commit 阶段和 commit 阶段:
super
并将 props
作为参数传入的作用是啥? 在调用 super()
方法之前,子类构造函数无法使用this
引用,ES6 子类也是如此。将 props
参数传递给 super()
调用的主要原因是在子构造函数中能够通过this.props
来获取传入的 props
。
传递 props
class MyComponent extends React.Component {
constructor(props) {
super(props);
console.log(this.props); // { name: 'sudheer',age: 30 }
}
}
没传递 props
class MyComponent extends React.Component {
constructor(props) {
super();
console.log(this.props); // undefined
// 但是 Props 参数仍然可用
console.log(props); // Prints { name: 'sudheer',age: 30 }
}
render() {
// 构造函数外部不受影响
console.log(this.props); // { name: 'sudheer',age: 30 }
}
}
上面示例揭示了一点。props
的行为只有在构造函数中是不同的,在构造函数之外也是一样的。
React V15 在渲染时,会递归比对 VirtualDOM 树,找出需要变动的节点,然后同步更新它们, 一气呵成。这个过程期间, React 会占据浏览器资源,这会导致用户触发的事件得不到响应,并且会导致掉帧,导致用户感觉到卡顿。
为了给用户制造一种应用很快的“假象”,不能让一个任务长期霸占着资源。 可以将浏览器的渲染、布局、绘制、资源加载(例如 HTML 解析)、事件响应、脚本执行视作操作系统的“进程”,需要通过某些调度策略合理地分配 CPU 资源,从而提高浏览器的用户响应速率, 同时兼顾任务执行效率。
所以 React 通过Fiber 架构,让这个执行过程变成可被中断。“适时”地让出 CPU 执行权,除了可以让浏览器及时地响应用户的交互,还有其他好处:
核心思想: Fiber 也称协程或者纤程。它和线程并不一样,协程本身是没有并发或者并行能力的(需要配合线程),它只是一种控制流程的让出机制。让出 CPU 的执行权,让 CPU 能在这段时间执行其他的操作。渲染的过程可以被中断,可以将控制权交回浏览器,让位给高优先级的任务,浏览器空闲后再恢复渲染。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。