许多人在学习 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 (
<div>{x + count}</div>
)
}他可以等价于。
function Counter({x}, [count = 0, setCount]) {
return (
<div>{x + count}</div>
)
}这个时候我们就明朗了，函数，原来还是纯函数。但是为什么语法不这样设计呢，不是更好理解吗？当然是因为参数太多了写不下了呀，因此 React 把传参的行为，下放到了函数内部，通过 hook 的方式来实现。
四、重新审视 hook
如果 state 是外部传入的参数，那么此时我们就要重新审视一下为什么不能把 hook 放到条件判断中去了。
例如：
function Counter({x}) {
if (a === 0) {
const [loading, setLoading] = useState(false)
}
const [count, setCount] = useState(0)
return (
<div>{x + count}</div>
)
}所以，useState 是外部传参，那么参数本来就应该有严格的顺序要求，这个时候如果第一个参数因为不符合条件而在代码逻辑里消失了，那第二个参数，不就变成第一个参数了吗？
这个时候代码逻辑中，就会把第二个参数当成第一个参数去使用，这不就乱了吗？
当我们调用 setState 时，表示入参正在发生变化，函数自然也会重新执行。
五、总结
hook 存放在函数外部，因此不属于函数内部的状态。我们在理解函数式组件是纯函数时，应该把 hook 当成参数去看待，这样很多现象就非常自然了。
函数式编程更加侧重于把逻辑解耦拆分成不同的函数，然后通过函数组合的形式去构建一个完整的逻辑，例如我们非常常见的 map 方法
function func(item) {
return item + 1
}
var newArr = arr.map(func)所以理解函数式编程，会对逻辑封装解耦的能力要求比较高，在这种情况下，理解函数式编程确实会存在一定的门槛。所以最后思考一个问题，为什么 state 一定要是不可变数据？
