[enhancement] Bind the this context to the methods on FormState and FieldState

[yinxulai]

First. i want reduce communication costs. so, then i use Chinese describe this issue.

因为并不是所有的 FormState 使用场景中消费者都是标准的 Form 组件，所以不一定有、且不一定需要有对应的 bindXX 方法，就会碰到下面的问题：

const anyState = new FieldState<any>()
...
<AnyComponent onAnyDateChange={anyState.onChange}>
...

当前的实现中，未对 FormState and FieldState 上面的方法绑定 this 上下文，从而当如上使用时，会发生错误.

例如这些地方：

• https://github.com/qiniu/formstate-x/blob/0fb4603cca1b8008d53306f9dbd89b4bb87c291b/src/formState.ts#L139
• https://github.com/qiniu/formstate-x/blob/0fb4603cca1b8008d53306f9dbd89b4bb87c291b/src/formState.ts#L168

我们是否应该为这些方法绑定所在的 this 上下文？

[nighca]

@yinxulai 绝大部分情况下我们不需要手工去做绑定的事情，那样往往会要求我们直接接触 _value / onChange，所以使用 bindInput 或基于 bindInput 来实现一个合适的 bind 函数来做绑定的事情是推荐的做法；

从这个角度考虑，这里提到的提前 bind this 以方便直接使用 onChange 的收益会比较低，我倾向不做；这个 issue 可以先放一阵看看

[yinxulai]

1. 不应该仅从绝大部分情况&推荐做法的出发点认为的收益较低而所以不做
2. 为什么不在可以预期的安全范围&合理的使用方式内提供使用者尽可能的自由和便利
3. 为什么不能使用很低的成本尽可能提升在 “一旦脱离绝大部分，用不了推荐做法就会让本来轻松的事情需要额外的检查和保护” 的情况下的开发者体验？
4. bind 比不 bind 收益大
5. 与 formstate 表现不一致

[nighca]

1. 不应该仅从绝大部分情况&推荐做法的出发点认为的收益较低而所以不做

@yinxulai 为啥不应该..

2. 为什么不在可以预期的安全范围&合理的使用方式内提供使用者尽可能的自由和便利

工具做得越少，使用者越自由；工具做得越多，使用者可能越便利；这边是在权衡：

• 收益：少部分 case 下的少量便利
• 代价：1. 工具本身的复杂度提升 2. 所有人群的少量自由（无法选择不 bind 了）

3. 为什么不能使用很低的成本尽可能提升在 “一旦脱离绝大部分，用不了推荐做法就会让本来轻松的事情需要额外的检查和保护” 的情况下的开发者体验？

JavaScript 语言就是不默认 bind 的，这个不能说是用 formstate-x 带来的“额外的检查或保护”；另外自己做 bind 或者写成箭头函数，也都比较轻松

4. bind 比不 bind 收益大

如上所说，有收益有代价；一般来说，增加 feature 这样的事情，都是默认不做（因为可以去做的 feature 太多了），有充分的理由才去做

5. 与 formstate 表现不一致

formstate 预期 <fooInput value={state.value} onChange={state.onChange}> 是正常用法，这一点跟 formstate-x 不太一样；

不过这点确实导致了不一致，我想一下（考虑到 value -> _value 已经导致 field state 绑定输入组件的写法不一致了）

[yinxulai]

• 收益：少部分 case 下的少量便利
• 代价：1. 工具本身的复杂度提升 2. 所有人群的少量自由（无法选择不 bind 了）

仔细想想这个 onChange 其实没有修改 this 的潜在需求，所以很难想到说有 "选择不 bind" 的情况

其他几个，我的主要观点是认为：

仅从 bind 这个事儿上来说，牺牲了很少的自由或者说代价（也就是你说的无法选择不 bind），换来了相对更多的便利，所以权衡下来觉得还是 bind 更舒服。

[nighca]

仔细想想这个 onChange 其实没有修改 this 的潜在需求，所以很难想到说有 "选择不 bind" 的情况

嗯所以是少量自由

仅从 bind 这个事儿上来说，牺牲了很少的自由或者说代价（也就是你说的无法选择不 bind）

主要的代价不是“无法选择不 bind”，是“工具复杂度的提升”（你一旦做了 bind 的事情，你以后就得一直保证这个）

换来了相对更多的便利，所以权衡下来觉得还是 bind 更舒服。

因为我在项目里几乎没有直接 <fooInput value={state.value} onChange={state.onChange}> 这么用过，所以比较难体会这边你说的“相对更多地便利”..

如果你的项目里确实存在不止一处这样的 case，你可以提个 PR 来加下 bind；不过

项目里确实存在不止一处这样的 case

这事儿可能本身是有问题的