对 React 组件状态的定义
状态, 即 State, 在一个应用系统中, 如果一个值(Value)会因为在某个时态发生改变, 即认为这个值(Value)是一个状态,
对于不会随时态发生变化的 State, 我们则称为值， 基于这点, 可以将组件分为无状态有值, 无状态无值, 有状态有值,
有状态无值 四类 UI 组件. 由此我们可以推测出, 在一个应用系统中, 不仅仅是状态的管理更是对值的管理.
PureUIComponent(无状态无值 UI 组件)
<div class="div-style">
</div>
没有自身状态, 同时也不接受外部传值的纯 UI 组件, 典型的例如 Icon, Canvas 画布, Svg 图形等
StatelessComponent(无状态有值 UI 组件)
<div>
{title}
</div>
没有自身状态, 不随时态变化发生变化, 但接受外部传值, 典型的例如 Button, Header
ShakyComponent(有状态无值 UI 组件)
class ShakyComponent extends Component{
state = {height:1000}
render(){
<div style={height:this.state.height}>
<button onClick={this.setState({height:2000})} />
</div>
}
}
UnchastityComponent(有自身状态且接受传值的 UI Component)
class UnchastityComponent extends Component{
state = {height:1000}
constructor(props){
super(props)
}
render(){
<div style={height:this.state.height}>
<button onClick={this.setState({height:2000})}>
{}
</ button>
</div>
}
}
事实上, 当需求发生变化, 组件类型也会从 PureUIComponent 切换到 StatelessComponent, 甚至切换到
UnchastityComponent, 所以组件的类型变换存在两种路径, 第一种 Pure => Stateless => Shaky => Unchastity
第二种 Unchastity => Shaky => Stateless => Pure
在大多数的应用系统中, 我们可能会开发大量的 UnchastityComponent, 那 UnchastityComponent 存在什么问题呢?
UC(便于书写, 简称, 下同), UC 就像一个不稳定的炸药, 随时都会破坏你的应用系统, 因为它自身产生状态, 同时又接受
外部传值, 很多情况下, 初始的内部状态可能在后续的时态中变成了外部传值, 而组件还在继续生产状态, 这种冲突我称为
状态失控 :
图中 state 中的 a 在用户的一些操作之后可能被记录下来, 然后通过外部传值重新回到这个组件, 这个过程在应用系统中
很普遍, 然而在一个复杂的应用系统中, 这种状态失控会让我们很难界定一个 state 的归属, 毫无疑问, 你也可以不关心这个
凭借我们的经验, 和视觉上的认知, 就设计一堆的 UC , 但之后, 当你开始实现代码, 持续迭代, 寻找 bug 的时候, 你会发
越来越多的状态失控需要处理, 这不仅让之前的设计花费的成本毫无意义, 也增加了我们后续的开发成本.
So, 为了解决这个问题, 我们需要一种方式, 或者一些准则来解决它, 在组件类型定义中, 我们知道组件存在 4 种状态,
最容易维护的无疑是 Pure, 没有状态, 不接受传值, 和视觉天然契合, 但除非你有一个极其智能的系统, 能够自发的去抓取
Pure 来组成应用系统, 不然我们还是需要, 至少是在简单的场景下, Stateless, 相对于 Pure, Stateless 接受一些
外部传值, 虽然这些 Value 有潜在转化成 State 的可能性, 但至少, 它们在不转化之前, 还是和视觉的契合度相当高,
所有的 Value 都能够观察到, 显然 Pure 和 Stateless 的设计成本很低, 因为非常贴近我们的视觉效果, 根据视觉稿
我们就能轻松设计出来, 如果所有组件都是 Pure 和 Stateless , 那整个应用系统一定很容易维护. 但现实很残酷,
在 90 %的应用系统中, 我们还是需要 Shaky, 无论是转场, Tab, Scroll, List, Filter, Form, 只要这个应用系统
接受用户的操作, Actions 就会触发组件不断的生产形形色色的状态, 而状态一旦产生又可能回流产生一个个 Value, 一旦
我们疏于设计, 就会制造出 UC, 从而由一个 UC 制造更多的 UC. 最终摧毁整个应用系统.
真正的状态管理者?
为了管理复杂的状态流, 从生产状态到回流制造 Value, React 定义了 Flux 架构, 从而有了 Redux, 无可否认 Redux
为我们提供了非常棒的状态管理工具 action 和 reducer, 但并不能解决我上面提到的问题, UC 的产生. 事实上, 真正的
状态管理者应该是开发者自身.
状态管理的准则
拒绝制造 UC
现在我们已经很清楚 UC 是什么, 自然我们也知道如何去拒绝制造 UC, 当我们设计出一个 UC 的时候, 你就该考虑拆分,
并把 UC 拆成 Shaky 和 Statelss, 除非很明确, 不然在这一个阶段, 我们可能不必拆出 Pure, 毕竟一切都还未知不是, 谁知道产品会出什么幺蛾子 :}(
使用数据化的组件
React 在 16.3 中创造性的为我们提供了新的 Context API, 这也为状态拆分和管理提供了一种新的思路, 数据化的组件 Provide 和 Consume, 这意味着我们可以放弃使用 HOC 来剥离状态,
直接使用声明式的方式来剥离组件的状态, 这给 Shaky 到 Stateless 转换提供了一种良好的模式
class Button extends Component {
state = {title:'Button'}
render(){
renturn(
<button>{this.state.title}</buton>
)
}
}
此时态的 Button 是一个 Shaky, 为了将它转换为 Stateless, 我们需要使用 connect, 通过 HOC 来剥离 Shaky 中的 State 让 Button 变成 Stateless
const Button = (props) =>{
renturn(
<button>{props.title}</buton>
)
}
const ButtonConnected = connect(state=>{title:state.title})(Button)
如果是声明式的话, 类似的伪代码应该是这样
<Connect>
<Button />
</Connect>
声明式的好处是没有隐式转换, 同时在设计上我们对数据和组件进行了一致的描述, 基于这点, 在最初设计的时候, Button 就会被设计成一个 Stateless, 而不是直到内部的 title 会转换成外部注入的值得时候才考虑去重构代码. 数据组件化帮我们理清了组件设计的思路, 避免了一些模糊的边界导致我们设计出不必要的 Shaky 甚至 Unchastity 组件
最后
扯了一堆有的没的, 后续再继续聊聊如何在实际的应用系统开发中, 去实践组件设计的准则和思路吧 :{}
