最近在团队内部review代码的过程中,引发了关于受控组件设计的一些思考。
关于受控组件,在刚接触React开发的时候,就了解到了这个概念,大体的实现就是给组件提供一个value, 一个onChange,value 用于渲染当前的UI视图,在用户触发操作,
需要更新value的时候,组件调用onChange,由上层组件负责更新状态。整体设计的一个关键点就是:
受控组件内部不维护任何相关的状态,状态都由外部传入
对于状态的更新,提供onChange回调
组件的这种设计方式,对于对接方来说,有付出,也有收益,
付出,就是指顶层组件需要维护相关的状态,并定义状态更新的回调(其实这也算不上付出。。。)
收益,就是指组件的扩展性和灵活性提高了,对于组件来说,我给你什么,你就渲染什么,而且状态由顶层的组件维护,在任何的时刻,都可以监视到
当前的状态,对于一些需要扩展验证规则,以及其他特殊限制的情况,再适合不过。
(最近Beisen开发了一批新的组件,在对接过程中,已经体验过非受控组件的痛苦了)
所以,在提供一些模块,供其他人对接的情况下,尽量将组件设计为受控模式,并统一提供value与onChange回调。
当状态更新时,由组件内部处理状态,并传给onChagne回调。
这种设计,对于一些状态单一的组件来讲,是非常合适的。如果需要提供的是一个比较复杂的组件,有多个状态,比如