表单设计器下个版本会存在Break Change!

[janryWang]

因为设计器领域本人也是在探索和学习，虽然在designable层面，目前的模型划分和设计，基本上算是比较完备灵活的版本了，
但是，在落到表单设计器层面上，还是存在一些设计上的问题：
第一：createDesignableField把很多拖拽行为，文案绑定的事情给做了，定制性很差，无法给每个拖拽源定制更灵活的designerProps
第二：还是因为第一点，文案绑定的作用域其实都是在Field组件上的，所以非常容易出现文案冲突，因为Field组件是个复合组件，内部的属性文案，更多的是取决于x-component，当然，这么说其实也不太完备，其实应该是取决于拖拽源节点
第三：想要把createDesignableField创建出来的DesignableField集成到designable的页面搭建场景，并不容易，比如：用户有可能想要完全定制基于拖拽源节点的propsSchema，目前内部强制约定了一些基础配置，且无法扩展，这个是个很严重的问题

总之，目前的表单设计器版本，还是比较初级的版本，主要还是为了想让用户尝鲜才放出来的，下面针对以上问题，是我最近探索出来的解决方案：

1. createDesignableField，仅仅只支持注册components画布组件，移除其他属性API，比如：

  componentsIcon?: Record<string, React.ReactNode>
  componentsSourceIcon?: Record<string, React.ReactNode>
  componentsPropsSchema?: Record<string, ISchema>
  dropFormItemComponents?: ComponentNameMatcher[]
  dropReactionComponents?: ComponentNameMatcher[]
  selfRenderChildrenComponents?: ComponentNameMatcher[]
  inlineChildrenLayoutComponents?: ComponentNameMatcher[]
  inlineLayoutComponents?: ComponentNameMatcher[]
  restrictChildrenComponents?: Record<string, ComponentNameMatcher[]>
  restrictSiblingComponents?: Record<string, ComponentNameMatcher[]>

2. 所有组件行为控制都聚合在注册拖拽源的时候标记，提供designerProps让用户定制：

GlobalDragSource.appendSourcesByGroup('inputs', [
  {
    componentName: 'DesignableField',
    designerProps: {
      title: '输入框',
      allowAppend(){...} //一个allowAppend可以解决第一点移除的所有配置问题，后面还会增加一个allowDrop
    },
    props: {
      title: 'Input',
      type: 'string',
      'x-decorator': 'FormItem',
      'x-component': 'Input',
    },
  }
)

3. 所有组件文案都聚合在注册拖拽源的时候标记，提供designerLocales给用户定制：

GlobalDragSource.appendSourcesByGroup('inputs', [
  {
    componentName: 'DesignableField',
    designerProps: {
      title: '输入框',
      allowAppend(){...}
    },
    designerLocales:{
        "zh-CN":{
             title:"xxx",
             settings:{...}
         }
    },
    props: {
      title: 'Input',
      type: 'string',
      'x-decorator': 'FormItem',
      'x-component': 'Input',
    },
  }
)

4. 字段默认Schema，提供createSchemaFromFieldTemplate API给用户组合使用，而不是内置在createDesignableField中，比如：

GlobalDragSource.appendSourcesByGroup('inputs', [
  {
    componentName: 'DesignableField',
    designerProps: {
      title: '输入框',
      allowAppend(){...},
      propsSchema:createSchemaFromFieldTemplate({
         //这里的schema就是具体x-component所对应的组件属性配置，它内部会自动包裹上字段级的基础配置，如果用户不想走这种模板，直接传原始json-schema即可
         type:"object",
         properties:{...}
      })
    },
    designerLocales:{
        "zh-CN":{
             title:"xxx",
             settings:{...}
         }
    },
    props: {
      title: 'Input',
      type: 'string',
      'x-decorator': 'FormItem',
      'x-component': 'Input',
    },
  }
)

5. 暴露内部预设schema集合，方便用户定制组合

这么设计了之后，formily设计器内部自身的架构也会变得清晰起来，可维护性会大大提升

考虑一种场景，用户想基于表单设计器定制一个无代码设计器，比如把响应器配置换成更易用，用户接受程度更好的业务定制配置形式，以这种形式是很容易做扩展定制的

[chenshuichao]

Great!

[chenshuichao]

这么重构以后，确实改进很大。

[chenshuichao]

下个版本，是指2.0的RC5吗

[janryWang]

对

[chenshuichao]

太好呀！

[chenshuichao]

其实，schema方面，我建议可以简化一下。
设计思路可以借鉴spring 对config文件的处理。
引入默认配置的概念。

[janryWang]

没懂，这是标准formily schema，有什么问题呢

[kaketsu]

大佬催更，这个改动预计啥时候能上线呀

[janryWang]

这两天有点忙，还没来得及搞……等一等

[GadflyX]

想知道如果现在用 designable，等到版本升级后使用方需要做些什么么？

[janryWang]

如果你没有使用createDesignableField的其他属性，基本上是平滑过渡