比较赞成文章的举例,合理运用高阶组件或修饰器来实现状态传递。 但是如果偏要用无状态组件,又要加上声明周期,未免太过牵强。 所以在开发中,考虑使用无状态组件的业务模块,要属于颗粒度细,无副作用的组件。 所谓细颗粒度,很好理解。假设我们有一个完整的搜索组件,其中包含了输入框、搜索按钮,清空。 那么: 输入框组件负责:响应输入事件,事件中返回内容;<Input onChange={} defaultValue={}/> 按钮组件负责:点击状态,点击事件反馈;<SearchButton onClick={} loading={false}/> 清空:干涉输入框组件的内容; 如果你再有一点强迫症,写的时候可以完全按照上面也分出3个组件完成(具体不演示) 巧妙的是每一个子组件只是传入一个东西,传出一个东西。不涉及生命周期,不耦合于业务代码,不影响系统。甚至可以服用在其他业务上。 此时无状态组件的意义显露出来。
比较赞成文章的举例,合理运用高阶组件或修饰器来实现状态传递。
但是如果偏要用无状态组件,又要加上声明周期,未免太过牵强。
所以在开发中,考虑使用无状态组件的业务模块,要属于颗粒度细,无副作用的组件。
所谓细颗粒度,很好理解。假设我们有一个完整的搜索组件,其中包含了输入框、搜索按钮,清空。
那么:
输入框组件负责:响应输入事件,事件中返回内容;
<Input onChange={} defaultValue={}/>
按钮组件负责:点击状态,点击事件反馈;
<SearchButton onClick={} loading={false}/>
清空:干涉输入框组件的内容;
如果你再有一点强迫症,写的时候可以完全按照上面也分出3个组件完成(具体不演示)
巧妙的是每一个子组件只是传入一个东西,传出一个东西。不涉及生命周期,不耦合于业务代码,不影响系统。甚至可以服用在其他业务上。
此时无状态组件的意义显露出来。