许多人在学习 React 时会有这样一个疑问,不断看到 React 官方团队言论,或者说各路大佬都是在说 React 是函数式编程,我们写组件确实写的是组件,但问题就在于,我们写的组件是有内部状态,这样的函数就不是纯函数了,这怎么能算是函数式编程呢?
想不通。
今天这篇文章,就来跟大家解释一下,为什么 React 的函数式组件,其实就是纯函数。
UI = f(state)
一、hook 的特性
我们在声明一个函数式组件时,常常会使用到 hook 来声明一些状态或者方法,但是我们在使用 hook 时,你会发现 hook 会有一些奇怪的规则,那么就是不能把 hook 放到条件判断中去。
if (a === 1) {
const [count, setCount] = useState(0)
}
然后有的人就很不理解这个现象。于是把这个情况定性为 React 的设计缺陷。但这真的是设计缺陷吗?
我们只需要换个思路,你就能对这个现象豁然开朗。
二、hook 存在哪?
在初学阶段,我们会很自然的认为,当我们使用 useState 在函数内部定义了一个状态时,那么这个状态一定是保存在这个函数内部的。
function Demo() {
const [count, setCount] = useState(0)
...
}
然后理解得多了,才发现并不是这样。每一个函数的状态都被存在了另外一个模块里(Fiber tree)。也就是说,只要 React 允许,我们甚至可以在别的组件访问到任意一个组件里的状态。当然 React 对这种情况做了限制,只允许通过特定的语法来做到这个事情。
函数组件中的所有的 hook 都是从外部传入的。
三、state 其实是参数
我们再来看一下这个公式。
UI = f(state)
这个时候我们会恍然发现,虽然 state 在函数内部定义/获取了,但是很明显,React 是期望大家把他当成外部传入的参数来理解的。
例如我们有这样一个函数。
function Counter({x}) {
const [count, setCount] = useState(0)
return (
{x + count}
)
}
他可以等价于。
function Counter({x}, [count = 0, setCount]) {
return (
{x + count}
)
}
这个时候我们就明朗了,函数,原来还是纯函数。但是为什么语法不这样设计呢,不是更好理解吗?当然是因为参数太多了写不下了呀,因此 React 把传参的行为,下放到了函数内部,通过 hook 的方式来实现。
四、重新审视 hook
如果 state 是外部传入的参数,那么此时我们就要重新审视一下为什么不能把 hook 放到条件判断中去了。
例如:
function Counter({x}) {
if (a === 0) {
const [loading, setLoading] = useState(false)
}
const [count, setCount] = useState(0)
return (
{x + count}
)
}
所以,useState 是外部传参,那么参数本来就应该有严格的顺序要求,这个时候如果第一个参数因为不符合条件而在代码逻辑里消失了,那第二个参数,不就变成第一个参数了吗?
这个时候代码逻辑中,就会把第二个参数当成第一个参数去使用,这不就乱了吗?
当我们调用 setState 时,表示入参正在发生变化,函数自然也会重新执行。
五、总结
hook 存放在函数外部,因此不属于函数内部的状态。我们在理解函数式组件是纯函数时,应该把 hook 当成参数去看待,这样很多现象就非常自然了。
函数式编程更加侧重于把逻辑解耦拆分成不同的函数,然后通过函数组合的形式去构建一个完整的逻辑,例如我们非常常见的 map 方法
function func(item) {
return item + 1
}
var newArr = arr.map(func)
所以理解函数式编程,会对逻辑封装解耦的能力要求比较高,在这种情况下,理解函数式编程确实会存在一定的门槛。所以最后思考一个问题,为什么 state 一定要是不可变数据?