Autorun中更完备的逻辑编写能力

[janryWang]

背景

大家都知道，@formily/reactive是比Mobx支持了更多能力的，最直接的就是，用户可以在autorun中既响应数据，又能操作数据，也就是说，autorun本身就是一个状态机模型了，但是，有一个问题，我们光有响应和操作，却没有创建，那就无法实现更复杂的逻辑了，因为autorun本身是会无限重复执行的函数体，就跟React渲染函数一样，那如何实现在autorun没被销毁前的持久引用创建呢？

Reactive方案

其实完全可以参考一下React的useMemo，我们也可以提供类似的API：

autorun(()=>{
  const obs = autorun.memo(()=>observable({
      aa:123
  }),[])
  
})

autorun.memo就作为一个持久引用创建方法，只有autorun本身被dispose或者memo依赖的参数发生变化的时候才会重新创建引用

那么，我们这里就解决了引用创建的问题。不过我们需要注意，memo函数内部是不会track数据的，要track数据必须基于dependencies数组来追踪

但是，另一个问题，memo是autorun同步执行的，也就是说它内部的计算会阻塞当前autorun流程，那如果我们希望有一个无阻塞模式呢？

同样可以参考React的useEffect，我们也可以提供类似的API：

autorun(()=>{
  const obs = autorun.memo(()=>observable({
      aa:123
  }),[])
  autorun.effect(()=>{
    //do somthing
  },[])
})

这样就解决了在Autorun过程中，从创建数据，到响应数据，再到操作数据，同时操作数据还能支持异步或者复杂计算的能力

对于用memo创建observable对象的语法比较繁琐，我们还能进一步优化，可以这样：

autorun(()=>{
  const obs = autorun.observable({
      aa:123
  },[])
  autorun.effect(()=>{
    //do somthing
  },[])
})

Schema方案

根据以上方案，我们其实可以在Schema协议中透出几个内置变量，$observable /$memo/$effect

x-reactions="{{function(){
  const model = $observable({
    keyword:''
  }),[])

  $effect(()=>{
    fetchDataSource({keyword:model.keyword}).then((data)=>{
      $self.dataSource = data
    })
  },[model.keyword])

  $effect(()=>{

  },[$self.value])
}}}"

考虑到Schema场景上，比如用户想在onSearch/onFocus或者其他事件中操作数据，我们还能再提供一个$props函数方便让x-reactions更好的与组件自身事件做通讯

x-reactions="{{function(){
  const model = $observable({
    keyword:''
  }),[])

  $props({
     onSearch(keyword){
        model.keyword = keyword
      }
  },[])

  $effect(()=>{
    fetchDataSource({keyword:model.keyword}).then((data)=>{
      $self.dataSource = data
    })
  },[model.keyword])

}}}"

其实$props就是

$memo(()=>$self.setComponentProps({
   onSearch(){
   
   }
}),[])

[janryWang]

这么做的一个目的主要就是为了让formily x-reactions具备更强大的逻辑编写能力，而不仅仅只是一个数据消费方

[janryWang]

大家开发formily大部分都是纯源码模式开发，如果x-reactions搞不定的，在外面随便处理一下就行了，我这边其实需求来源是设计器，设计器需要一个有逻辑闭环的能力

[liuweiGL]

formily

我的观点是 x-reactions 只适合用于一些简单的字段联动，而不适合编写复杂的业务代码。

1. 字符串对代码校验以及格式化都是不友好的。
2. debug 不友好。

designable

这一块我还没有真正意义上的使用过，不过我觉得这可能是一个很好的能力，能省去很多自定义组件的封装。

[janryWang]

我的考虑，主要是设计器场景，因为源码模式写大量的字符串表达式是非常难以维护的，但是设计器场景不一样，可以精确的控制某个代码块的编辑能力，什么代码提示，格式化，都能享受到

[liuweiGL]

恩，在设计器中用户其实感知不到这是一个字符串吧？

[janryWang]

对

[ananiy]

有必要手动声明依赖吗 并且这个是在具体的reaction上面挂载持久的observable吧

autorun(self => {
self.$observable.xx = observable({})
self.$autorun(() => {...})
})