3.1通用schema设计
通用 Schema 设计
Schema 本质上就是一个 JSON 格式的定义块，通过抽象属性定义来表达页面和组件的布局、属性配置、依赖关系、表达式解析，如果在偏向业务也有页面路由、多语种、数据源、权限等等各种各样的抽象声明。 因此，我们也将刚刚提到的内容统称为 Schema 协议，它也属于元数据结构模型的范畴。
整个协议的主体采取 JSON 方式的原因：
- 方便存储，可以存储到服务端中形成记录；
- 方便操作，跨平台解析；
- 结构简单，通俗易懂，方便开发者查阅。
Schema 协议第一个版本先预留了如下几个领域区块，分别是依赖管理、国际化(多语种)、状态管理、数据源、生命周期以及页面结构等耳熟能详的结构定义。
协议版本(version)
- major: 如果包含 Break Change(破坏更新)的内容;
- minor: 当你产出了一个新的功能的时候（无破坏更新）;
- patch: 当你修复了一个 BUG 问题的时候（无破坏更新）。
依赖管理(library)
- 用于维护国际化项目时需要进行多语种的文案切换带来的业务诉求
- 参考业内成熟 i18n 的方案
状态管理(store)
- 维护一份页面上的状态。方便后续做绑定通信和事件广播的实现
- 跨模块、跨页面这种全局状态管理，当然随之而来的是这块的配置会更加复杂，包括 Schema 的设计与配置的形式
数据源(dataSource)
在大多数业务场景当中，页面的元素结构渲染并不是根据静态数据来渲染的，而是通过获取相关接口中的远程数据来展示。所以数据源与远端挂钩，可以是远程的 JSON 文件，也可以是一个 fetch 请求，主要的目的是为了帮助页面组件支持动态渲染数据的能力。
一个请求包含以下几个重要的内容，请求资源 URI、Request、Header、Response => params | query | body ，所以在定义数据源的时候，我们将其抽象成如下结构：
ts
const i18n: SchemaModelConfig['dataSource'] = [
{
key: 'string|uuid',
name: 'getUserList',
request: {
url: 'https://localhost:3000/user/list',
params: {
pageSize: 10,
current: 1,
},
method: 'GET',
body: {},
header: {}
...AxiosInstanceConfig
}
}
]
// 最终会抽象成一个函数调用来动态的执行。
lowcodeSandBox?.loadDataSource('getUserList', ...其他参数): Promise<any>生命周期(lifeCycles)
一个项目的使用中有初始化、使用中、销毁等多个不同的生命周期，每个状态需要做的事情也不同，比如在程序初始化时会加载或者配置后续使用中需要的数据、资源等，同理对于低代码平台应用而言，搭建页面时与传统项目一样，同样需要自定义一套生命周期来帮助更好管理产物的拉取、Dom 渲染、数据更新等操作。
页面结构(htmlBody)
与 虚拟 DOM 相似，本质上是对于当前页面渲染的抽象结构，便于跨平台之间的转换，为后续运行时渲染和动态出码垫定基础，提供后续结构化转换的能力。