我从今年 8 月份开始接手两个项目,项目均是使用 meteor+react。项目中组件的统一风格都是无状态组件。随后因为为了要契合项目编码风格,我也统一全部使用无状态组件。
经过几个月的开发,也做了几个新项目。其中发现挺多问题的,希望 V 友 帮我解惑,说说你们的看法。
1、经常会发现一个组件要传递 7-8 个状态,再加 5-6 个 action,特别是类似 form 表单的这种组件,这样组件入口要传递十几个参数+状态+数据,不但代码难看,而且容易出错和混淆。另外给这些状态命名也是让人头疼的事情。
2、为了管理状态必须或可能会用到 redux、reactive-dict 等类似状态管理的功能,一个 form 组件 7-8 个状态,多几个 form 组件全局状态可能就会有几十个。redux 还好,像 reactive-dict 这种没有结构的状态管理经常会发现有状态名冲突的情况,甚至有时候为了给状态起个名字要想半天。
3、状态因为不在组件内部,生命周期是从创建一直存在的,很多初始化工作要做在无状态组件的外面,避免我们在给无状态组件传递某个状态的时候有默认值或者上一次用过的状态信息。这样一来一个状态要初始化、要赋值、要销毁,且三个动作有可能不在同一个组件中完成,出错几率非常大。
4、action 和组件分离,写代码的时候文件切换来切换去的,非常麻烦。
为什么一直推崇无状态组件,他给开发到底带来了什么便捷,从哪个角度看优势显而易见?我以上说的算是缺点吗?如果不是如何避免呢?是否有更好的实现?
1
sensui7 2017-12-18 23:59:29 +08:00 via iPhone 1
我理解的状态就是全局变量一样的东西,app 级的,把这些变量放在各个组件内部相当于,各个函数内部直接使用了全局变量。
无状态组件就是传递参数的过程。 声明:本人不会 react,只会 vue 在 vuex 里,可以定义 module,各个状态会在 module 名字下,可以减少冲突。 通过 mapGetters 等方法,基本与使用组件内状态按键数量差不多。 至于 props 传递多,可以直接传递一个对象啊。反正你这个状态在父组件里也是要打字吧。传的时候就一个对象而已。 |
2
weishijun14 2017-12-19 00:43:26 +08:00 via Android 2
无状态的优点是纯函数,简单,可复用性高。但是,你没有必要为了无状态而无状态。 需要用到生命周期的时候就该用 class。需要用到 state 的时候就用 class。过于纠结无状态是没有意义的。
|
3
zachguo 2017-12-19 01:58:18 +08:00 via Android 1
@weishijun14 同意。不要为了用 SFC 和 Redux 而去用。
Flux 架构大部分 app 都是用不到的,把表格组件也 flux 化的是走火入魔,高耦合带来的那些麻烦得不偿失。 |
4
nmgwddj OP @weishijun14 我现在也有这种考虑,一个 form 表单为了做成无状态那个叫费劲儿啊。看来以后真得改改策略了。
|