˙Ⱉ˙最近的工作一直在使用React,已经差不多五个月了,想给自己写些对react的一些思考和总结。也记录一下当初刚上手时的疑惑,方便后续自己回顾。
网上各种言论说 React 上手比 Vue 难,可能难就难不能深刻理解 JSX,或者对 ES6 的一些特性理解得不够深刻,导致觉得有些点难以理解,然后说 React 比较难上手,还反人类啥的,怀揣着敬畏之心,发现其实也没那么的复杂嘛…
为什么要引入 React
在写 React 的时候,你可能会写类似这样的代码:
1 | import React from 'react' |
头一次接触的时候肯定疑惑过,下面的代码都没有用到 React,为什么要引入 React 呢?
如果你把 import React from ‘react’ 删掉,还会报下面这样的错误:
那么究竟是哪里用到了这个 React,导致我们引入 React 会报错呢,不懂这个原因,那么就是 JSX 没有搞得太明白。
你可以讲上面的代码(忽略导入语句)放到在线 babel 里进行转化一下,发现 babel 会把上面的代码转化成:
1 | function A() { |
因为从本质上讲,JSX 只是为 React.createElement(component, props, ...children)
函数提供的语法糖。
为什么要用 className
而不用 class
- 设计理念
这个其实是因为React 一开始的理念是想与浏览器的 DOM API 保持一直而不是 HTML,因为 JSX 是 JS 的扩展,而不是用来代替 HTML 的,这样会和元素的创建更为接近。在元素上设置 class 需要使用 className 这个 API:1
2const element = document.createElement("div")
element.className = "hello" - 关键字不支持
浏览器问题,ES5 之前,在对象中不能使用保留字。以下代码在 IE8 中将会抛出错误:解构问题,当你在解构属性的时候,如果分配一个 class 变量会出问题:1
2
3
4
5const element = {
attributes: {
class: "hello"
}
}其他讨论可继续深度搜索:『有趣的话题,为什么jsx用className而不是class』1
2
3const { class } = { class: 'foo' } // Uncaught SyntaxError: Unexpected token }
const { className } = { className: 'foo' }
const { class: className } = { class: 'foo' }
为什么属性要用小驼峰
因为 JSX 语法上更接近 JavaScript 而不是 HTML,所以 React DOM 使用 camelCase(小驼峰命名)来定义属性的名称,而不使用 HTML 属性名称的命名约定。
来自 JSX 简介
为什么 constructor 里要调用 super 和传递 props
这是官网的一段代码,具体见:状态(State) 和 生命周期
1 | class Clock extends React.Component { |
而且有这么一段话,不仅让我们调用 super 还要把 props 传递进去,但是没有告诉我们为什么要这么做。
不知道你有没有疑惑过为什么要调用 super 和传递 props,接下来我们来解开谜题吧。
为什么要调用 super
其实这不是 React 的限制,这是 JavaScript 的限制,在构造函数里如果要调用 this
,那么提前就要调用 super,在 React 里,我们常常会在构造函数里初始化 state,this.state = xxx
,所以需要调用 super
。
为什么要传递 props`
你可能以为必须给 super
传入 props
,否则 React.Component
就没法初始化 this.props
:
1 | class Component { |
不过,如果你不小心漏传了 props,直接调用了 super(),你仍然可以在 render 和其他方法中访问 this.props(不信的话可以试试嘛˙Ⱉ˙)。
为啥这样也行?因为React 会在构造函数被调用之后,会把 props 赋值给刚刚创建的实例对象:
1 | const instance = new YourComponent(props); |
props
所以说不传也能用,是有原因的。
但这意味着你在使用 React 时,可以用 super()
代替 super(props)
了么?
那还是不行的,不然官网也不会建议你调用 props
了,虽然 React 会在构造函数运行之后,为 this.props
赋值,但在 super()
调用之后与构造函数结束之前, this.props
仍然是没法用的。
1 | // Inside React |
要是构造函数中调用了某个访问 props
的方法,那这个 bug 就更难定位了。因此强烈建议始终使用super(props)
,即使这不是必须的:
1 | class Button extends React.Component { |
上面的代码确保 this.props
始终是有值的。
如果你想避免以上的问题,你可以通过class
属性提案 来简化代码:
1 | class Clock extends React.Component { |
为什么组件用大写开头
前面以及说过了,JSX 是为 React.createElement(component, props, …children)
提供的语法糖,component 的类型是:string/ReactClass type,我们具体看一下在什么情况下会用到 string 类型,什么情况下用到 ReactClass type 类型
- string 类型react会觉得他是一个原生dom节点
- ReactClass type 类型 自定义组件
例如(string):在 jsx 中我们写一个
1 | <div></div> |
转换为js的时候就变成了
1 | React.createElement("div", null) |
例如(ReactClass type):在jsx中我们写一个
1 | function MyDiv() { |
转换为js的时候就变成了
1 | function MyDiv() { |
上边的例子中如果将MyDiv中的首字母小写,如下
1 | function myDiv() { |
转换为 js 的时候就变成了
1 | function MyDiv() { |
由于找不到 myDiv 这个 dom,所以就会报错。
为什么调用方法要 bind this
首先,你需要深刻的理解 JavaScript 中的 this
相信刚写 React 的时候,很多朋友可能会写类似这样的代码:
1 | class Foo extends React.Component { |
发现会报 this
是 undefined
的错,然后可能对事件处理比较疑惑,然后去看官网的事件处理有下面一段话:
你必须谨慎对待 JSX 回调函数中的 this
,在 JavaScript 中,class 的方法默认不会绑定this
。如果你忘记绑定 this.handleClick
并把它传入了 onClick
,当你调用这个函数的时候 this
的值为 undefined
。
这并不是 React 特有的行为;这其实与 JavaScript 函数工作原理有关。通常情况下,如果你没有在方法后面添加 ()
,例如 onClick={this.handleClick}
,你应该为这个方法绑定 this
。
然后你看了官网的例子和建议之后,知道需要为事件处理函数绑定 this
就能解决,像下面这样:
1 | class Foo extends React.Component { |
但是可能你没有去思考过为什么需要 bind this
?如果你不能理解的话,那就还是 js 的基础没有打好。
React 是如何处理事件的?
咱们先来了解一下 React 是如何处理事件的。
React 的事件是合成事件, 内部原理非常复杂,这里只把关键性,可以用来解答这个问题的原理部分进行介绍
上篇已经说过,jsx 实际上是 React.createElement(component, props, …children)
函数提供的语法糖,那么这段 jsx 代码:
1 | <button onClick={this.handleClick}> |
会被转化为:
1 | React.createElement("button", { |
了解了上面的,然后简单的理解 react 如何处理事件的,React 在组件加载(mount)和更新(update)时,将事件通过 addEventListener
统一注册到 document 上
,然后会有一个事件池存储了所有的事件,当事件触发的时候,通过 dispatchEvent
进行事件分发。
所以你可以简单的理解为,最终 this.handleClick
会作为一个回调函数调用。
理解了这个,然后再来看看回调函数为什么就会丢失 this
。
this
简单回顾
在函数内部,
this
的值取决于函数被调用的方式。
通过上面对事件处理的介绍,来模拟一下在类组件的 render 函数中, 有点类似于做了这样的操作:
1 | class Foo { |
你会发现最终结果输出的是 undefined
,那么我觉得你也可以理解为什么需要 bind this
了。(就是cb调用的时候,把this搞丢惹˙Ⱉ˙)
那么你可能会问:为什么React没有自动的把 bind
集成到 render
方法中呢?在 exec
调用回调的时候绑定进去,像这样:
1 | class Foo { |
因为 render
多次调用每次都要 bind
会影响性能,所以官方建议你自己在 constructor
中手动 bind
达到性能优化。
四种事件处理对比
对于事件处理的写法也有好几种,咱们来进行对比一下:
- 直接 bind this 型
就是像文章开始的那样,直接在事件那里 bind this1
2
3
4
5
6
7
8
9
10
11
12
13class Foo extends React.Component {
handleClick () {
this.setState({ xxx: aaa })
}
render() {
return (
<button onClick={this.handleClick.bind(this)}>
Click me
</button>
)
}
}
优点:写起来顺手,一口气就能把这个逻辑写完,不用移动光标到其他地方。
缺点:性能不太好,这种方式跟 react 内部帮你 bind 一样的,每次 render 都会进行 bind,而且如果有两个元素的事件处理函数式同一个,也还是要进行 bind,这样会多写点代码,而且进行两次 bind,性能不是太好。(不过其实这点性能往往不会是性能瓶颈的地方,如果你觉得顺手,这样写完全没问题)
- constuctor 手动 bind 型
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17class Foo extends React.Component {
constuctor(props) {
super(props)
this.handleClick = this.handleClick.bind(this)
}
handleClick () {
this.setState({ xxx: aaa })
}
render() {
return (
<button onClick={this.handleClick}>
Click me
</button>
)
}
}
优点:相比于第一种性能更好,因为构造函数只执行一次,那么只会 bind 一次,而且如果有多个元素都需要调用这个函数,也不需要重复 bind,基本上解决了第一种的两个缺点。
缺点:没有明显缺点,硬要说的话就是太丑了,然后不顺手。
- 箭头函数型
1
2
3
4
5
6
7
8
9
10
11
12
13class Foo extends React.Component {
handleClick () {
this.setState({ xxx: aaa })
}
render() {
return (
<button onClick={(e) => this.handleClick(e)}>
Click me
</button>
)
}
}
优点:顺手,好看。
缺点:每次 render 都会重复创建函数,性能会差一点。
- public class fields 型
这种 class fields还处于实验阶段,貌似目前还没有被纳入标准1
2
3
4
5
6
7
8
9
10
11
12
13class Foo extends React.Component {
handleClick = () => {
this.setState({ xxx: aaa })
}
render() {
return (
<button onClick={this.handleClick}>
Click me
</button>
)
}
}
优点:好看,性能好。
缺点:没有明显缺点,如果硬要说可能就是要多装一个 babel 插件来支持这种语法。
为什么要 setState
,而不是直接 this.state.xx = oo
如果从 vue 转到 React 可能会有这种疑问,因为 vue 修改状态都是直接改的。
如果我们了解 setState
的原理的话,可能就能解答这个问题了,setState
做的事情不仅仅只是修改了 this.state
的值,另外最重要的是它会触发 React 的更新机制,会进行 diff ,然后将 patch 部分更新到真实 dom 里。
如果你直接 this.state.xx == oo
的话,state
的值确实会改,但是改了不会触发 UI 的更新,那就不是数据驱动了。
那为什么 Vue 直接修改 data
可以触发 UI 的更新呢?因为 Vue 在创建 UI 的时候会把这些 data
给收集起来,并且在这些 data
的访问器属性 setter
进行了重写,在这个重写的方法里会去触发 UI 的更新。
setState
是同步还是异步相关问题
setState
是同步还是异步?
我的回答是执行过程代码同步的,只是合成事件和钩子函数的调用顺序在更新之前,导致在合成事件和钩子函数中没法立马拿到更新后的值,形式了所谓的“异步”,所以表现出来有时是同步,有时是“异步”。何时是同步,何时是异步呢?
只在合成事件和钩子函数中是“异步”的,在原生事件和setTimeout/setInterval
等原生 API 中都是同步的。简单的可以理解为被 React 控制的函数里面就会表现出“异步”,反之表现为同步。那为什么会出现异步的情况呢?
为了做性能优化,将state
的更新延缓到最后批量合并再去渲染对于应用的性能优化是有极大好处的,如果每次的状态改变都去重新渲染真实 dom,那么它将带来巨大的性能消耗。那如何在表现出异步的函数里可以准确拿到更新后的
state
呢?
通过第二个参数setState(partialState, callback)
中的callback
拿到更新后的结果。
或者可以通过给setState
传递函数来表现出同步的情况:1
2
3this.setState((state) => {
return { val: newVal }
})那表现出异步的原理是怎么样的呢?
在 React 的setState
函数实现中,会根据isBatchingUpdates
(默认是 false) 变量判断是否直接更新this.state
还是放到队列中稍后更新。然后有一个batchedUpdate
函数,可以修改isBatchingUpdates
为true,当
React 调用事件处理函数之前,或者生命周期函数之前就会调用batchedUpdate
函数,这样的话,setState
就不会同步更新this.state
,而是放到更新队列里面后续更新。
这样你就可以理解为什么原生事件和setTimeout/setinterval
里面调用this.state
会同步更新了吧,因为通过这些函数调用的 React 没办法去调用batchedUpdate
函数将isBatchingUpdates
设置为true
,那么这个时候setState
的时候默认就是false
,那么就会同步更新。
最后setState
是 React 非常重要的一个方法,值得大家好好去研究一下他的原理。
参考文章
React 中为什么要 bind this
《React 状态管理与同构实践》