☘️ gingko(银杏)
一套用于模块配置化的业务组件框架
A front-end framework for dynamic configure web application.
Getting Started 现在开始
Install 如何安装
$ npm i gingko -S
Usage 如何使用
; const schema = root: id: 'parent' componentName: 'Parent' props: {} children: id: 'sun' componentName: 'Sun' props: {} ; const Parent = ;ParentdisplayName = 'Parent'; const Sun = <div>sun has storeDatacar</div>;SundisplayName = 'Sun'; <div> Gingko !!! <RenderComponent schema=schema components=Parent Sun Daughter globalData= firstname: 'gingko' globalConfig= isWeek: false /> </div>;
Development 如何开发
# Starting a local service $ npm run dev
Features 特征
- 🕹Dynamic config & schema to UI - 动态 Schema 渲染 UI
- ⚙️Store & Context management - Store 和 Context 的管理
- 📄Business somponent stardard - 标准业务组件实现规范
- 🔧Configurate by part of block - 局部可配置化
Concept 概念
在页面可配置化的场景下,在需要构建富交互应用时,组件的关联关系和数据映射往往很难处理。
而 gingko 提供了三层结构以及标准化的业务组件概念使得配置化页面简单而纯粹。
- GlobalContainer:表示一个完整的产品业务
- DataContainer:表示一个完善的业务流程
- Business Component: 表示一个独立的业务组件
Difference 区别
页面可配置化,一般都是 SchemaBuilder -> Schema -> SchemaRender,但是如何处理组件之间的关联关系和数据流转的信息通常是用 Schema 来描述。
这样的方式使得 Schema 难以维护且配置复杂,这样的原因是因为以前的思路都是按照 UI 组件拆分的维度做组件划分,但是在 gingko 中,我们通过业务模块来划分。
也就是说我们脱离的 UI 的维度,站在产品业务角度(数据角度)对组件进行划分,分离出业务组件(Business Component)。
但是一个业务模块会跟多个业务模块组成一个业务流程,而这个业务流程则是一个闭环,在 gingko 中我们以 DataContainer 的概念表示。
通常一个系统包含多个业务流程,每个业务流程是相互独立的,但是可能会统一收取系统的信息,在 gingko 中最外层就是 GlobalContainer。
映射到数据层
- Business Component:业务组件,独立管理 state
- DataContainer:业务流程,统一管理下面子组件的 store
- GlobalContainer:业务系统,统一管理全局 context
正是因为有了这三层结构,我们将以往的集中式 store 以及分离式 store 等约束规范成了三层,便于实现可配置化的前端应用构建。
API
RenderComponent
; <RenderComponent schema=渲染组件的 Schema components=注册的组件,所以 Schema 中的组件都需要 displayName globalData=全局 context 通过 <GlobalConsumor /> 注册读取 globalConfig=全局只读配置,子组件可通过 propsglobalConfig 获取/>
DataContainer
被 DataContainer 包裹后的组件可通过 props 获取 storeData
和 setStoreData
两个对象,用于统一处理业务组件的状态数据。
globalData & setGlobalData
被 GlobalConsumer 包裹后的组件可通过 props 获取 globalData
和 setGlobalData
两个对象,用于统一处理全局状态数据。