# 设计理念

# 基本架构

在 ZodUI 的设计理念中，目标是让一切都由数据与类型驱动，在此基础上将组件的组织设计成了分层结构。

从外到内来看，我们可以将组件分为以下几个层级：

• Composer：胶水层，组件的组织者，负责组件的组织与展示

  常见的胶水层组件有：List、Tabs、Steps、CollapseCard、Form 等

  同时胶水层也可以嵌套自己或者其他的 Composer 进行展示，从而形成更复杂的组件

• Descriptor: 描述层，负责对数据进行描述，以便于 Composer 进行组织

  常见的描述层组件有：List.Item、Tabs.TabPane、Steps.Step、CollapseCard.Panel、Form.Item 等

• Switcher: 切换层，按照 Schema 的值、类型是否多态来进行切换，并提供相关封装后的操作 API

  常见的切换层组件有：Monad、Complex、Multiple 等

• Unit: 单元层，负责对数据进行展示或者控制

  常见的单元层组件有：Controller、Viewer、UnitRender 等

层次结构如下：

Composer
  Descriptor/Composer
    Switcher
      Unit

# 关于框架

为了方便实现对多种前端框架的支持，比如在通用逻辑上的复用、基本样式上的重用、以及插件管理机制上的统一，可以将部分逻辑抽象为独立的模块进行维护。

# 插件注册管理

对于插件的注册与管理实际上在多种框架下并没有太大的差别，而这段逻辑不断在多个框架下进行重复开发是不值得的。

在抽象的基础上，同时需要考虑对多种框架的兼容，以及用户在使用时候的 tree shaking 需求

# 通用的类型系统

对于类型系统来说，其实现的本质是对数据的描述，因此对于不同的框架来说，其实现的本质是一致的。

基于最基础的组件来说，都是对一个函数进行 props 输入，再得到框架预期的输出，在通用层面上我们对框架预期的输出并不关心，这个由各个框架的兼容系统负责并处理。

# 数据同步

每一个前端框架为了实现自己对 D-V 模型的响应式设计，都有着自己的数据状态系统。 而我们的部分逻辑独立于其系统外部进行管理，部分耦合于系统内部进行管理。 于是可以将独立于各个系统外部的部分抽象出来，以便于在不同的框架下进行复用。 然后再经过不同的适配器，将其转换为各个框架的数据系统所能识别的数据。 而部分耦合于系统内部的状态，这部分便是各个框架的兼容系统所需要处理的部分。

用代码对上面的行为进行描述，便是：

useEffect(() => {
  return zodui.onCompUpate(newComp => this.comp = newComp)
}, [])