关于前端:配置可视化基于formrender的无代码配置服务一

6次阅读

共计 1939 个字符,预计需要花费 5 分钟才能阅读完成。

背景

有些业务场景 须要产品或经营去配置 JSON 数据 提供给开发去应用(前面有理论业务场景的阐明),原有的业务流程,非开发人员(前面间接以产品指代)把数据交给开发,再由开发去更新 JSON 数据。对于产品来说,间接接触 JSON 数据并不敌对,一是搞不懂 JSON;二是容易出错,影响现网数据。

基于此要解决 2 个方面的问题:

  1. 如何让产品也能更敌对地去配置各类数据?
  2. 如何尽可能减少数据谬误?

表单兴许是个能够承受的计划,有题目、有各类交互的 UI 组件 …,比间接让产品间接在 Monaco Editor 手写 JSON 来的好一点;表单自身也反对数据校验,是否必填、最大值最小值、数据格式、正则匹配 …

而且对于表单这类 UI 来说,无论是 react、vue 都有很多比拟成熟的 基于 JSON Schema 的表单 UI 库,比方,阿里开源的一站式中后盾表单解决方案:form-render,上述须要的性能根本都有了,接入也不便。

长处

  1. 通过表单 UI 实现数据配置的交互,更容易被非开发人员承受。
  2. 配置 JSON Schema 的时候,开发能够依据各个字段标准编辑好 校验逻辑,在配置数据的时候就能间接查看出谬误(相似于 typescript 在编译时会执行动态类型的查看)。
  3. 交互束缚,爱护数据结构,防止误操作毁坏数据结构,导致线上数据呈现问题。无效爱护数据安全,比方给产品提供个 Checkbox 去勾选须要的数据,总比让产品间接写一个数组要好得多。
  4. 自定义表单组件 (如 form-render 的 widget),开发能够自定义表单组件,功能型组件如:CDN 图片上传裁剪组件、链接生成组件、 数据预填充组件(指先填写局部字段,再拉从后盾拉取其余相干的数据填充到表单内,如输出某个用户的 uin,组件会主动拉取到这个 uin 相干的个人信息填到表单中)

性能

后盾

提供 cdn 和申请接口两种拉取形式:

CDN

CDN 的速度好一点,对服务器压力也没那么大,并且可能缓存下来,但在更新上会有提早(须要刷新)。所以实用于绝对固定的数据。

申请接口

申请接口在速度略微慢一点,但好在数据足够实时,并且可能反对 数据半配置化。数据半配置化是指,后盾在接管到表单提交的数据后,对局部字段再做一层标准化的解决。

举个例子:

当初须要一份每周作者投票数排行榜的数据,产品填好或主动生成一些根本字段后(如作者们的头像链接、昵称、形容等用户个人信息),再给须要实时更新的字段(如票数)抉择相应的标识选项,去告知后盾这个字段须要后盾另外拉取并填充到数据内能力返回给申请方。

须要留神的是:抉择相应的标识选项这个能力也个别是通过 widget 开发的,但和 数据预填充组件 的区别在于,这个 widget 次要是为了告知后盾去实现相干逻辑填充数据,而不是在前端间接拉取数据主动填在表单内(如下面提到的用户个人信息能够通过用户 uin 去拉)。

前端

数据列表页

入口页,辨别测试环境和正式环境,能够通过域名或者其余形式辨别。

原型图如下:

顶部栏:

  1. 表单 id:主动生成,作为获取数据(包含用于形容表单 UI 的 JSON Schema、表单填写的理论数据等)的惟一标识
  2. 创建人
  3. 备注
  4. 数据预览:展现数据,超过 xx 字数展现局部
  5. 状态:编辑中、公布、已删除
  6. 以后版本号
  7. 创立工夫
  8. 类型:表单:在生成的表单内填写;默认:在 Monaco Editor 间接填 JSON 数据

操作栏:

  1. 编辑 schema:跳转表单编辑页,如果类型不是表单,置灰不可用
  2. 编辑数据:表单页或者数据页,取决于创立时怎么抉择
  3. 删除:使数据生效
  4. 历史版本:版本记录、版本回退、版本比照高亮、以后版本:以数据库数据为准,并且通过和 CDN 链接的数据做比照,判断 CDN 是否更新

表单编辑页

应用 fr-generator,反对手动导入导出 JSON Schema。编辑生成的 schema 要存储起来,用于下次编辑时可能间接显示表单 UI,同时须要申请数据库数据,把数据回填到表单内。

表单页

左侧为表单,通过表单 id 拉取相应的 Schema 由 form-render 渲染 UI;右侧实时展现以后表单的 JSON 数据。左侧表单数据变更时,右侧 JSON 数据实时更新并高亮差别。同时反对 JSON 数据导入导出。

数据页

基于 Monaco Editor 实现,实用于开发本人疾速填写一些数据应用。

总结

本文次要是介绍背景和性能。

其实还有很多细节没有讲,比方,后盾接口的数据结构是如何定义的,使其可能反对较为通用的数据(如 JSON Schema 也是用同一个接口去读写)读写需要;后盾服务又是如何实现的,具体用的什么技术栈;平台的权限治理又是如何实现等细节。

同时很多问题也值得思考,比方,如何对正式环境和测试环境的数据做隔离;是否用表单 hook 的形式代替掉数据预填充组件,使其更简洁易扩大;如何实现不同表单之间的数据联动等相干问题。

后续还会有其余文章去聊一下这些细节和问题。

正文完
 0