Open yinxulai opened 4 years ago
@yinxulai 绝大部分情况下我们不需要手工去做绑定的事情,那样往往会要求我们直接接触 _value
/ onChange
,所以使用 bindInput
或基于 bindInput
来实现一个合适的 bind 函数来做绑定的事情是推荐的做法;
从这个角度考虑,这里提到的提前 bind this
以方便直接使用 onChange
的收益会比较低,我倾向不做;这个 issue 可以先放一阵看看
bind
比不 bind
收益大
- 不应该仅从绝大部分情况&推荐做法的出发点认为的收益较低而所以不做
@yinxulai 为啥不应该..
- 为什么不在可以预期的安全范围&合理的使用方式内提供使用者尽可能的自由和便利
工具做得越少,使用者越自由;工具做得越多,使用者可能越便利;这边是在权衡:
bind
了)
- 为什么不能使用很低的成本尽可能提升在 “一旦脱离绝大部分,用不了推荐做法就会让本来轻松的事情需要额外的检查和保护” 的情况下的开发者体验?
JavaScript 语言就是不默认 bind 的,这个不能说是用 formstate-x 带来的“额外的检查或保护”;另外自己做 bind
或者写成箭头函数,也都比较轻松
bind
比不bind
收益大
如上所说,有收益有代价;一般来说,增加 feature 这样的事情,都是默认不做(因为可以去做的 feature 太多了),有充分的理由才去做
- 与 formstate 表现不一致
formstate 预期 <fooInput value={state.value} onChange={state.onChange}>
是正常用法,这一点跟 formstate-x
不太一样;
不过这点确实导致了不一致,我想一下(考虑到 value -> _value
已经导致 field state 绑定输入组件的写法不一致了)
- 收益:少部分 case 下的少量便利
- 代价:1. 工具本身的复杂度提升 2. 所有人群的少量自由(无法选择不
bind
了)
仔细想想这个 onChange
其实没有修改 this
的潜在需求,所以很难想到说有 "选择不 bind
" 的情况
仅从 bind
这个事儿上来说,牺牲了很少的自由或者说代价(也就是你说的无法选择不 bind
),换来了相对更多的便利,所以权衡下来觉得还是 bind
更舒服。
仔细想想这个
onChange
其实没有修改this
的潜在需求,所以很难想到说有 "选择不bind
" 的情况
嗯所以是少量自由
仅从
bind
这个事儿上来说,牺牲了很少的自由或者说代价(也就是你说的无法选择不bind
)
主要的代价不是“无法选择不 bind
”,是“工具复杂度的提升”(你一旦做了 bind
的事情,你以后就得一直保证这个)
换来了相对更多的便利,所以权衡下来觉得还是
bind
更舒服。
因为我在项目里几乎没有直接 <fooInput value={state.value} onChange={state.onChange}>
这么用过,所以比较难体会这边你说的“相对更多地便利”..
如果你的项目里确实存在不止一处这样的 case,你可以提个 PR 来加下 bind
;不过
项目里确实存在不止一处这样的 case
这事儿可能本身是有问题的
因为并不是所有的
FormState
使用场景中消费者都是标准的 Form 组件,所以不一定有、且不一定需要有对应的bindXX
方法,就会碰到下面的问题:当前的实现中,未对
FormState
andFieldState
上面的方法绑定this
上下文,从而当如上使用时,会发生错误.例如这些地方:
我们是否应该为这些方法绑定所在的
this
上下文?