一个模块化+低代码的页面生成器的开发记录（要点+BUG篇）

系列目录

• 一个模块化+低代码的页面生成器的开发记录(原理篇)
• 一个模块化+低代码的页面生成器的开发记录(要点+BUG篇)

(接上文)

多平台响应式方案

我司该项目实际上为多端平台，包含Web/小程序/APP/MS-Teams/Adobe等，所以开发时需要考虑编辑后如何在多端展示。

1. 移动端(除小程序)处理

如前所述，本项目中模块的JSON定义支持设置移动端、分平台样式样式，所以默认支持移动端响应式，具体可以见【预览】窗口的移动端效果：

preview-mobile.png

既然已支持响应式，那么不难想到，其他非浏览器端的平台，最简单的方式是使用WebView，直接嵌入H5的页面。通常的店铺主页，除了自定义的部分，还会有一些固定不变的组成部分，如头部Banner，底部Tabbar等，以美的旗舰店的京东主页为例：

app-media-homepage-marked.jpg

本项目编辑器生成的页面，其实只展示在上图中间的【自定义区域】，顶部和底部的小程序是各店铺通用的，由其他逻辑生成。如果采用WebView方案，可在中间【自定义区域】设置一个WebView窗口，直接指向web端页面即可。我司APP端也是这样实现的。

2. 小程序端处理

然而这种方案在小程序上碰壁了。因为小程序的web-view有个强制规定:

wx-mp-webview-doc.png

即小程序的WebView必须是全屏的，无法设置大小，这与上面分析的需求不符。理论上也许可以使用等方案局部覆盖实现,但效果显然好不到哪里去。所以WebView方案在小程序端行不通，需要另外实现一套小程序的渲染逻辑。

由于我们项目采用了JSON => DOM的方案，这种分层思想类似于React Native的逻辑，将结构抽象成的JSON后，只要各端处理好实现从节点到DOM的渲染，那边就能实现一次编辑、多端展示了。且小程序的DOM属性原本就与Web端的大致兼容（我司小程序使用Taro,所以也是基于vue），所以解决方案其实很简单：

1. 将Web端compiler流程相关代码复制到小程序端，然后在schema规范化时，将Web端的tagName改成View:

// （其他逻辑详见上文的normalizeStrategies）
import { View, Text } from '@tarojs/components';
// 规范化nodeSchema策略集合（策略模式）
const normalizeStrategies = {
  module(nodeSchema: CommonCompProp) {
    return {
      tagName: View,
      ...objUtil.pick(nodeSchema, ['style', 'class']),
      children: nodeSchema.children || [],
    };
  },
  block(nodeSchema: CommonCompProp) {
    return {
      tagName: View,
      ...objUtil.pick(nodeSchema, ['style', 'class']),
      children: nodeSchema.children || [],
    };
  },
  ...
};

2. 对各种组件元素（type： 'component'）进行改写.基本上只需要将InputableText/ImageBox/ProductBox等组件复制一份到小程序端，然后将