@formily/reactive action/batch语义变化

[janryWang]

感觉也是受了mobx的影响，action与batch现在的语义是一样的，只不过action是作为高阶函数而存在，这个总感觉怪怪的，还记得formily为啥不用Mobx的一大原因就是因为action内部不能track数据，所以reactive就支持了track，但是问题来了，

如果真的就只是单纯的action(动作)，那还track它内部的数据，其实也是不合理，因为我们要保证动作的纯粹性，收集依赖的话，会导致动作内部的逻辑不可预测，那对于formily的需求而言，其实就是：

需要一个单纯的batch模式，而非全部action，所以这么看来，action与batch的区别就不应该是高阶函数和非高阶函数的语义了，而应该是，batch与batch+untrack的语义区别，至于高阶和非高阶，那应该是action/batch都应该支持高阶绑定模式，

那么最终的API应该是这样：

//只做batch，不阻止track
interface batch {
   <T>(callback?:()=>T):T //原地batch
   scope<T>(callback?:()=>T):T //原地局部batch
   bound<T extends (...args:any[])=>any>(callback:T,context?:any):T //高阶绑定
}

//batch+untrack
interface action {
   <T>(callback?:()=>T):T //原地action
   scope<T>(callback?:()=>T):T //原地局部action
   bound<T extends (...args:any[])=>any>(callback:T,context?:any):T //高阶绑定

}

显然，这样会带来break change，对用户的影响可能是，用户使用了action，但是希望内部收集依赖，升级后不会再收集，还有一个影响会比较大，直接使用action的用户需要改成action.bound

[atzcl]

个人是支持这种细分用法的，但是不太理解这里的意思

还有一个影响会比较大，直接使用action的用户需要改成action.bound

是要将现在的 action 变成 mobx 的 runInAction ，action.bound 则是现在的 action ?

[janryWang]

是要将现在的 action 变成 mobx 的 runInAction ，action.bound 则是现在的 action ?

对

[janryWang]

一个动作的定义，就是一次纯粹的数据操作，不应该对外界有隐式的副作用影响，这个是从抽象概念来给它的约定，但是batch的定义，它就是用于收敛一组操作序列，批量执行

[fishedee]

弱弱地问一下，不太理解需求的来源是什么，为什么要在batch里面既做批量set，以及收集track的行为？

[atzcl]

弱弱地问一下，不太理解需求的来源是什么，为什么要在batch里面既做批量set，以及收集track的行为？

之前也对

mobx 不支持 action 内部进行依赖收集

这里的需求有些疑惑，好像在我的日常使用里面，都没有需求是要在 batch/action 里面做依赖收集的

[atzcl]

onFieldReact内部是在autorun里的，autorun本身会走batch模式，如果套一个类似mobx的runInAction，就没法收集依赖了

类似这种情况，不应该是需要自己组装一个 batch + track 吗，而不是收敛在底层中

[janryWang]

这是因为你平时开发很少用autorun，但是Formily 的reactions就是基于autorun的，这里面会有大量的数据操作，比如form.setFieldState('*(aa,bb)',()=>xxx)，这种是既存在查询，也存在操作的，而且查询是需要收集变化，操作又希望批量操作

[fishedee]

我觉得新设计总体上没有问题，action与batch理应要合并在一起了。只是区分track与非track的地方可以在接口名称更改吗，例如改为:

//只做batch，不阻止track
interface batch {
(callback?:()=>T):T //原地batch
scope(callback?:()=>T):T //原地局部batch
bound<T extends (...args:any[])=>any>(callback:T,context?:any):T //高阶绑定
}

//batch+untrack
interface batch_untrack {
(callback?:()=>T):T //原地action
scope(callback?:()=>T):T //原地局部action
bound<T extends (...args:any[])=>any>(callback:T,context?:any):T //高阶绑定
}

这样原来用action接口的用户都会编译不过，而且，接口语义上也比较清晰

[janryWang]

感觉改名字，就有点违背mobx的哲学了，这里我个人感觉mobx对action的定位还是很清晰的，之前对它的挑战其实只是需要一个纯粹的batch api而已，而不是改掉action的语义

[ananiy]

action默认就应该是batched

class Store {
  a = 1;
  b = 1;

  setAB() {
    this.a = 2;
    this.b = 2;
  }
}

这里setAB只执行一次reaction是很符合用户的心智的, 一个action只渲染一次

至于在autorun里面track依赖, 我觉得应该有个叫runInAutorun的新api...

[janryWang]

上面已经说了呀，action = batch + untrack

batch是batch，就是纯粹的批量操作，不阻碍收集

[gwsbhqt]

好像在实践中很少需要在action中做依赖收集的，但是确实存在极个别案例。
所以我比较支持提供两个api，即(batch+track)和(batch+untrack)。
至于命名什么的我觉得问题都不大，只需要在文档中清楚表示就好。
这次action/batch breaking change影响的用户估计不会太多，毕竟现在大部分使用的action其实都不涉及到track。

不过特别希望能够统一define的语义，即

class Store {
    constructor() {
        define(this, {
            ref: observable.ref,
            batch: batch.bound, // batch + track
            action: action.bound, // batch + untrack
        })
    }
}

导出多两个observable的api

class Store {
    constructor() {
        define(this, {
            ref: observable.ref,
            batch: observable.batch, // batch + track
            action: observable.action, // batch + untrack
        })
    }
}

[janryWang]

为什么要多导出这两个API呢？是觉得写起来太麻烦？
这个我不太推荐，因为observable的静态属性都是用于创建observable数据的，action这种是属于创建方法。。。

[gwsbhqt]

按我的理解的话observable静态属性是用于创建响应式的“东西”的，如果说被batch.bound修饰后的方法具有依赖收集的能力的话，那么observable.batch应该说的过去。
其实我就是觉得在define的一堆observable.xxx中突然出现几个xxx.bound，有点突兀。而且可有时候之前写惯了batch/action会忘记写.bound了。