标准化CRUD作用域变量规范

[janryWang]

想必用过formily的同学应该都知道，在自增列表中，如果每一行有几个相邻字段间的联动，我们正常应该如何实现了吧？

{
  properties:{
    aa:{
       type:"string"
    },
    bb:{
       type:"string",
       'x-reactions':{
           dependencies:['.aa'],
           fulfill:{
              state:{ 
                 value:"{{$deps[0]}}"
              }
           }
       }
    }
  }
}

发现没，好复杂！
说实话，在协议中的联动协议，用x-reactions并不太优雅，那更优雅的方式是什么呢？

{
  properties:{
    aa:{
       type:"string"
    },
    bb:{
       type:"string",
      'x-value':"{{$record.aa}}"
    }
  }
}

哇，是不是很神奇，其实现在已经支持了，在formily antd /next两个包中，只要是内部使用了ArrayBase的组件，都能享受到这个内置作用域变量，
当然，除了$record，我还提供了$index，所以后面有人再问，删除按钮想要基于索引动态隐藏咋做，你就给它说：

{
  'x-visible':"{{$index === $records.length - 1}}"
}

诶？可惜，$records我还没提供，所以，这就是我接下来要讲的内容了

标准化CRUD作用域变量规范

首先，变量名标准化

1. $record 代表任何列表记录对象
2. $lookup 代表父级记录对象(与$record.$lookup的区别是如果$record为非对象数据，则需要通过$lookup获取)
3. $index 代表任何列表记录当前索引值
4. $records 代表任何列表数据
5. $record.$lookup 代表父级记录对象，可以层层往上找
6. $record.$index 代表当前记录对象的索引，同样可以层层往上找，比如$record.$lookup.$index or $record.$lookup.$lookup.$index

同时，$record，还有一个内置属性$lookup，可以获取它上级$record，也有内置属性$index，方便往上层层查找

这样我们能做什么？

其实我们甚至可以把整个表单数据也当做一个$record，因为它本身就是在维护数据库一张表的记录，那么，我们就能标准化到Form组件

在渲染的时候，会把它当前层级的对象或表单数据作为$record下发下去，这样就能做到用formily协议描述整个页面的时候，Form组件内部的任意节点获取到的$record都是子表单数据

当然如果它内部有ArrayField，在ArrayField某一行里的字段获取到的就是ArrayField内部的$record了

那如果我们还是想拿表单级别的record怎么拿呢？那就得使用$record.$lookup了

所以，我们有了formily协议，也有了标准化的CRUD作用域变量规范，貌似，我们好像不需要x-reactions了？？？

那主动联动怎么搞？可以这样

{
   "x-component-props":{
     "onChange":"{{$record.bb = 123}}" //或者$self.query(`array.${$index}.*(aa,cc)`).forEach(t=>t.reset())
   }

}

是不是真的不需要x-reactions了呢？

我觉得真的不需要了，可能后面formily3.0，直接移除也说不准

然后就是怎么让这套标准落地下去了。

首先，我会在@formily/react中提供一个组件，叫做RecordListScope，它用于注入$records，主要在自增组件或者表格组件中使用

然后我还会提供一个叫做RecordScope，主要用于注入$record/$index，主要在渲染每一行或者每个单元格的时候使用

好了，大家看看，这样的协议如何，是否优雅呢？

[yiyunwan]

x-reactions移除没必要，后面还会有低代码场景可以用到的，不过这个方案很赞，我现阶段是通过动态注入data实现的，即在变动时将record直接递归注入子元素的所有data中，有了这个就可以把这个代码移除了

[yiyunwan]

我觉得不止$record.$parent 还可以$record.$root吧

[janryWang]

$root就是$form

[yiyunwan]

了解了

[weilaiqishi]

能不能让小程序也支持一些简单的表达式

[janryWang]

$parent改名$lookup，因为从CRUD语义上来看的话，父级不是指父级UI节点，也不是指父字段，相反它是属于父模型，所以应该以模型语义来表达

[Mistruth]

这样写级联会更舒服一点，不过定义成{{ }}后，是否无法描述异步表达式的场景？

[liuweiGL]

这个无法完全替代 x-reactions 吧，比如这种联动还是 reactions 更灵活：

     'x-reactions': {
          dependencies: ['contractType'],
          effects: ['onFieldInputValueChange'],
          fulfill: {
            state: {
              value: undefined
            }
          }
        }

[janryWang]

可以

{
   'x-component-props':{
      onChange:"{{(value)=>$form.query('xxx').take(target=>target.value = value)}}"
   }
}

[liuweiGL]

恩恩，没想到可以这样。。。

不过 x-reactions 在联动方面还是有优势的：

1. 可维护行更好，语义方面非常棒，虽然写法比较啰嗦。
2. 一对多联动时应该也更方便，字符串里面写代码我觉得是最不应该推荐的编码方式，维护起来简直是灾难。

我认为 变量作用域 跟 x-reactions 虽然有重叠的地方，但还是各有各的长处。变量作用域 适合用来处理 schema 支持的属性，x-reactions 因为可以很方便的入侵到 field 的 state 里面去，所以处理 schema 不支持的属性更加得心应手。

[janryWang]

如果是纯源码模式开发，主动联动模式我个人是不太推荐写在字段级别的，我个人更喜欢在顶层effects维护，如果是搭建场景的话，字符串代码编写维护性其实还好

[chhpt]

当有多个依赖，以及包含复杂的 JS 逻辑时，x-reactions 还是无法被替换的，要用字符串表达式替代完整的 JS 函数还是比较困难的，写着写着，字符串表达式可能就变成了字符串形式的函数