开发者普遍认为状态是组件的一部分, 但是同时却又在剥离状态上不停的造轮子, 这不是很矛盾么?
对于一个最简单的文本组件而言
代码语言：javascript复制function Text(){
const [text, setText] = useState('载入')
return (){
<p>{text}</p>
}
}你觉得应该把 text 从 Text 组件中剥离么? 如果你的直觉告诉你不应该这么做, 那为何要使用 redux mobx jotai 等等一系列稀奇古怪的状态管理库来让我们的代码变得更复杂?
所以 why?
还不是 React 自己的锅!!!
因为 React 在组件状态上给出了双重定义, 内敛的 state 和开放的 props.
同时因为 jsx 的限制导致组件通信只能依赖 props.
有人会说还有 context, 但如果你为组件通信单独增加一层 provide, 那随着应用膨胀, 你的状态会被 xml 结构割得四分五裂, 最后只剩下单一 store 这颗有毒药丸.
因为 React 天生状态同步上的缺陷, 才让状态管理这件事在 React 社区如此发达, 这其实是病态的.
想想战国时期群雄逐鹿吧. 还不是周天子失仪, 看看 Vue 就没有这么多狗屁倒灶的事.
状态管理生态的病态繁荣让整个 React 生态变得混乱.
不同状态管理库之间潜在的集成成本, 以及围绕这些状态管理打造的组件库又需要考虑集成. 看看 Route5 吧, 我觉得官网的 React 和 Redux 集成方案根本不够. 毕竟还有好几个库在那等着呢...
从 React 自身角度来看, 只要解决两个问题, 就没有所谓的状态管理了.
组件内部通信
jsx 下的组件结构无非两种, 包含和平级, 对于包含嵌套的结构, 单一 store 是可行的, 要解决的无非是内部的 jsx 片段之间如何共享和同步状态. 其实很简单只要给这些 jsx 片段绑定上一个共同的 context 就行了,
代码语言：javascript复制import {createComponent} from 'structured-react-hook'
const Component = createComponent({
initState:{
A:'A',
B:'B',
M:'M',
},
view:{
renderB(){
return(
<>
<div>{this.state.M}</div>
<div>{this.state.B}</div>
</>
)
},
renderA(){
return(
<>
<div>{this.state.M}</div>
<div>{this.state.A}</div>
</>
)
},
render(){
return(
<>
<div>{this.state.M}</div>
<div>{this.view.renderB()}</div>
<div>{this.view.renderA()}</div>
</>
)
}
}
})参考 前端进阶面试题详细解答
一个组件可以切分任一的 jsx 片段到 view 里, 同时将状态放在 initState 里管理, 在运行时让 render 函数的 this.state 指向 initState 就行了, 当然内部有些魔法, 这就不提了.
当然组件大了一定需要平行切割, 不然会遇到性能和维护上的问题. 对于平行组件如何让他们彼此共享和同步状态呢?
代码语言：javascript复制const ComponentA = createComponent({
name:'ComponentA',
initState:{
A:'A'
},
view:{
render(){
return(
<div>{this.combination.ComponentB.state.B}</div>
)
}
}
})
const ComponentB = createComponent({
name:'ComponentB',
initState:{
B:'B'
},
view:{
render(){
return(
<div>{this.combination.ComponentA.state.A}</div>
)
}
}
})就这么简单, 只要让每个组件的实例能在彼此的 this 上互相感知, 操作和共享状态并不是难事.
这样对于 jsx 内平行的组件来说再也不需要为了通信而烦恼了. 无论跨越多少层, 最终我都会找到你.
所以解决这两个问题, 还需要额外的状态管理么?
至少在我看来状态管理是个伪命题, 组件和状态本身就是不可分割的一部分, 把状态视为组件的核心, 只要解决了组件的问题, 状态管理自然也就不是问题了
但是只要 React 官方不作为, 状态管理社区的病态繁荣还将继续持续下去
