正文
接下来需要解决两个问题：
- 可视化搭建的其他业务元素如何与画布交互。比如拓展属性配置面板、图层列表、拖拽添加组件、定位锚点、主题等等。
runtimeProps如何访问到当前组件实例的props。
这两个问题非常重要，而恰好又可以通过良好的数据流设计一次性解决，接下来让我们分别分析讨论一下。
问题一：可视化搭建的其他业务元素如何与画布交互。比如拓展属性配置面板、图层列表、拖拽添加组件、定位锚点、主题等等
需要设计一个 Hooks API，可以访问到画布提供的方法、数据。在 React 设计中，访问 Hooks API 需要在一定上下文内，所以可以将 ，其中 负责渲染画布。这样开发者的使用方式就变成了这样：
import { createDesigner } from 'designer'
const { Designer, Canvas, useDesigner } = createDesigner()
const EditPanel = {
const { addComponent } = useDesigner()
return
}
const App = () => {
}
为了支持多个 Designer 实例间隔离，通过 createDesigner 创建一套上下文独立的 API，这样就可以让画布、配置面板同时用 Designer 实现，用一套技术方案同时实现画布与配置表单，这样学习上下文、组件规范都可以统一为一套，表单、画布能力也可以共享。
在 useDesigner 直接访问数据与方法，比如上面例子在直接访问内置方法 addComponent 时，不需要附加任何参加，而 addComponent 方法也永远保持引用不变，此时 useDesigner 不会导致 EditPanel 重渲染。
如果需要访问当前组件树，并在组件树变化时重渲染，可以通过如下方式访问：
const EditPanel = {
const { componentTree } = useDesigner(state => ({
componentTree: state.componentTree
}))
}
该写法的效果是，当 state.componentTree 变化了，会触发 EditPanel 重新渲染，并拿到最新值。
同时也可以传入第二个参数 compare 自定义对比方法，默认为 shallowEqual：
useDesigner(
(state) => ({
componentTree: state.componentTree,
}),
isEqual
);
如此一来，无论给画布拓展多少 UI 元素都没有问题，而且 UI 元素可以自由的访问画布方法与数据。
问题二：runtimeProps 如何访问到当前组件实例的 props
在 componentMeta.runtimeProps 中，我们构造一个 selector 函数用于访问当前组件 props：
const divMeta = {
componentName: "div",
runtimeProps: ({ selector }) => {
const name = selector(({ props }) => props.name)
return {
fullName: `full-${name}`
}
}
element: /** ... */
};
首先支持从 runtimeProps 回调里拿到 selector，并且该 selector 支持传入一个回调函数，该回调函数的参数中 props 指向当前组件实例的 props，通过该方法就可以访问组件 props 了。
该 selector 仅在 props.name 改变时重新执行，并且也遵循 compare 对比规则，即当 props.name 变化时，selector 回调函数的返回值通过 compare 与上一次值进行对比，如果没有变化就返回上一次的旧值，变化了则返回新值。默认对比函数为 shallowEqual，与 useDesigner 类似，也可以在第二个参数位置覆写 compare 方法。
那组件元信息如何访问内置静态方法呢？由于静态方法引用不变，因此可以在 selector 同级直接传入：
const divMeta = {
componentName: "div",
runtimeProps: ({ addComponent }) => {
return {
add: () => {
/** addComponent(...) */
}
}
}
element: /** ... */
};
如此一来，我们就将数据流与组件元信息打通了，即 UI 可以通过 useDesigner 访问与操作数据流，组件元信息也可以直接拿到方法，或通过 selector 拿到数据，相应的也可以访问与操作数据流。这样的设计在以后拓展更多组件元信息函数时，都可以继承下来，开发者只要学习一次语法，就可以获得非常强力的拓展性。
拓展应用状态与静态方法
刚才介绍了一些内置的状态（componentTree）与方法（addComponent），在下一接会系统介绍笔者梳理了哪些内置状态与方法。首先抛开内置状态与方法不谈，应用肯定需要定义自己的状态与方法，我们可以提供两种模式给用户。
第一种是应用的状态与方法定义在外部，对应受控模式。
假设你的应用在对接 Designer 之前就已经用 Redux、Dva、Zustand 等状态管理库，那么就可以使用受控模式直接接入：
const App = () => {
// 伪代码，不管是 useState 还是其他数据流管理状态，假这里拿到了数据与方法
const { getAppInfo } = useSomeLib();
const { userName } = useSomeLib("userName");
return
将方法传给 actions，状态传给 state。
第二种是应用的状态与方法通过
假设你的应用之前没有使用任何数据流，那么也可以直接将 Designer 的数据流作为项目数据流使用：
import { createMiddleware, createDesigner } from "designer";
const middleware1 = createMiddleware({
state: { userName: "bob " },
actions: { getAppInfo: () => {} },
});
const { Designer } = createDesigner(middleware1);
const App = () => {
return
通过 createMiddleware 创建一个中间件定义状态与函数，传入 createDesigner 即可生效。
也可以在 createMiddleware 里通过第二个参数定义自定义 hooks，或者拿到方法更改 State:
const middleware1 = createMiddleware(
{
state: { userName: "bob " },
},
({ setState }) => {
const setUserName = React.useCallback((newName: string) => {
setState((state) => ({
...state,
userName: newName,
}));
});
return { setUserName };
}
);
Designer 内部采用最朴素的 Redux 管理状态，提供了最基础的 getState 与 setState 获取与修改状态，基于它们封装业务函数即可。
无论是受控模式，还是非受控模式（亦或两种模式同时使用），定义的状态与方法都可以在以下两个位置访问，第一个位置是 useDesigner：
const {
/** 自定义函数 */,
setUserName,
/** 自定义函数 */
getAppInfo,
/** 内置函数 */
addComponent,
// 内置变量
componentTree,
// 自定义变量
userNamee
} = useDesigner(state => ({
componentTree: state.componentTree,
userName: state.userName
}))
第二个位置是组件元信息上的回调函数，比如 runtimeProps：
const divMeta = {
componentName: "div",
runtimeProps: ({
selector,
/** 自定义函数 */,
setUserName,
/** 自定义函数 */
getAppInfo,
/** 内置函数 */
addComponent
}) => {
const {
/** 内置变量 */
componentTree,
/** 自定义变量 */
userName
} = selector(({ state }) => ({
componentTree: state.componentTree,
userName: state.userName
}))
return { componentTree, userName }
}
element: /** ... */
};
至此，我们实现了一套完整的数据流定义，包括：
- 不同 Designer 之间上下文隔离。
- 可无缝对接项目数据流，也可作为独立数据流方案提供。
- 内置变量与函数与自定义变量、函数混合。
- 无论在 UI 通过
useDesigner，还是在组件元信息通过selector都可访问这些变量与函数。
总结
一个基本可用的可视化搭建框架在本章就算设计完了。但这只是可视化搭建问题的冰山一角，未来的章节，笔者会逐渐为大家介绍更多可视化搭建的设计。
但无论框架未来怎么发展，也永远会基于这前三章的基本设定，总结一下，这三章的基本设定就是：设计一个逻辑与 UI 分离的可视化搭建协议，数据流、组件元信息、组件实例是永远的铁三角，数据流可以对接任意已存在的实现，或基于 Designer 规范实现，组件元信息与组件实例仅存储最基本信息，得益于数据流的自定义能力，以及无论何处都有完全的数据流访问能力，使业务框架既遵循规则，又可以千变万化。
抛开具体 API 设计或者命名不谈，一个有简洁、抽象，又提供极少量 API 却能满足所有业务定制诉求，是可视化搭建永远追求的目标。只要熟悉了这套规范，就可以几乎仅根据业务表现，一眼猜出是基于哪些 API 封装实现的，那么维护成本与理解成本将大大降低，规范的意义就体现在这里。
也许有同学会觉得，现在各个大厂都有无数可视化搭建的实现，可视化搭建概念都已经烂大街了，为什么还要重新设计一个呢？
因为也许数量不代表质量，维护的时间越久，参与的同学越多，越容易使设计变得冗余，概念变得复杂，要对抗这些递增的熵，唯有不断重新设计，从零开始反思方案。
下一讲理论思考会少一些，介绍可视化搭建框架会考虑内置哪些变量与方法，更多关于JS画布与组件元信息数据流的资料请关注脚本之家其它相关文章！
版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）