在人们的传统印象中，前端一直都是很薄的一层，向上不能影响后端数据，向下不能改变产品设计，只是相当于数据与界面之间的一个连接层，单独拿出来后就将失去其大部分的价值。但随着单页应用的普及，越来越多的重型前端应用被开发了出来并逐渐成为了人们常用的生产力工具中重要的组成部分。

这其中最经典的一个应用莫过于「可视化页面搭建工具」。

对于任何一家有运营需求的公司，「可视化页面搭建工具」都是一个刚需，我们很难想象有哪家公司的前端工程师每天的工作就是做生命周期只有几天甚至几小时的活动页。所以一直以来「可视化页面搭建工具」在前端开发界都不是一个新鲜的议题。从 20 年前的 Dreamweaver 开始，一直到最近淘宝推出的飞冰（ice），其本质上的思路都是类似的，即基于组件的模块化页面搭建。

# 三个阶段

在讨论具体的页面搭建工具之前，我们首先要明确一个问题，那就是谁是页面搭建工具的目标用户以及页面搭建工具能够帮助这些目标用户解决什么问题？

结合目前市面上已经推出的产品，可视化页面搭建工具的目标用户大致可以分为两类：一类是非技术的运营（产品）人员，主要使用场景为更新较为频繁的促销页、活动页等；另一类是非前端开发的技术人员，主要使用场景为简单的内部管理系统搭建。而根据不同的使用场景及需求，页面搭建工具最终交付的成品也不尽相同。

# 静态页面

常见的可视化页面搭建工具一般都会包含页面预览区、组件选择区及布局调整区（如调整组件顺序等）等三个部分。在从组件选择区选择了某几个组件后，每个被选用的组件还会有各自的属性编辑界面，一般为弹窗的形式，如下图所示的表格组件编辑界面。

最终的产出就是一段描述当前页面布局与内容的 DSL，通常以 JSON 的格式存储。

{
  "pageId": 1,
  "pageUrl": "/11-11-promo/electronics",
  "pageTitle": "双十一大促 - 家电专场",
  "layout": "two-columns",
  "components": {
    "two-columns": {
      "firstCol": [{
        "componentName": "list",
        "componentProps": [{
          "title": "促销家电列表",
          "data": [{
            "name": "电视机"
          }, {
            "name": "洗衣机"
          }, {
            "name": "冰箱"
          }]
        }]
      }],
      "secondCol": [{
        "componentName": "list",
        "componentProps": [{
          "title": "促销家电列表",
          "data": [{
            "name": "电视机"
          }, {
            "name": "洗衣机"
          }, {
            "name": "冰箱"
          }]
        }]
      }]
    }
  }
}

@前端进阶之旅: 代码已经复制到剪贴板

与之相配合的在客户端代码中还需要有两个解析器。第一个解析器是路由解析器，即根据当前页面路径向后端发送请求拿到对应页面的 DSL 数据。第二个解析器是在拿到这段 DSL 数据后对 components 字段进行解析然后按照设置的布局逐个渲染配置好的组件。

这种架构非常适合处理内容展示页面的需求，从技术角度来讲也很适合做服务端渲染因为每个页面的渲染结果完全是数据驱动的，后端返回的服务端渲染结果就是最终前端展示的 HTML。但这种方案的局限性在于无法动态更新页面数据，因为数据和组件的配置是完全绑定的想要更新页面数据就需要去更改组件的配置。

# 动态页面

为了实现动态更新数据的需求，我们需要将组件的数据源与组件的配置解耦，也就是说我们需要将原先组件中配置好的数据替换为一个后端的数据接口，让后端的数据接口可以直接与组件进行对接。这样就实现了数据与配置之间的解耦，即不需要更新组件的配置就可以直接更新组件的展示数据。这样的灵活性对于促销页、活动页等数据变动频繁的业务场景来说是非常有帮助的。

{
  "pageId": 1,
  "pageUrl": "/11-11-promo/electronics",
  "pageTitle": "双十一大促 - 家电专场",
  "layout": "two-columns",
  "components": {
    "two-columns": {
      "firstCol": [{
        "componentName": "list",
        "componentApi": "/api/11-11-promo/electronics/list",
        "componentProps": [{
          "title": "促销家电列表"
        }]
      }],
      "secondCol": [{
        "componentName": "list",
        "componentApi": "/api/11-11-promo/electronics/list",
        "componentProps": [{
          "title": "促销家电列表"
        }]
      }]
    }
  }
}

@前端进阶之旅: 代码已经复制到剪贴板

除了直接配置数据接口外，另一种常见的做法是将数据接口统一处理为数据资产，在使用者配置组件的数据源时，让其可以在所有相关的数据资产中选择需要的部分，然后再转化为具体的数据接口，保存在组件配置中。

但在引入了异步数据之后，有一个必须要解决的问题就是何时发出这些数据请求。这里推荐使用高阶组件的方法来解决这一问题，即抽象出一个专门根据组件的 componentApi 属性发送请求的高阶组件，并将它包裹在所有需要发送异步请求的组件之上。

function fetchData(WrappedComponent) {
  class FetchData extends Component {
    state = {
      data: {},
    }

    componentDidMount() {
      const { componentApi } = this.props;
      api.get(componentApi)
        .then((response) => {
          this.setState({
            data: response,
          });
        });
    }

    render() {
      return <WrappedComponent {...props} data={this.state.data} />;
    }
  }

  return FetchData;
}

@前端进阶之旅: 代码已经复制到剪贴板

# 动态可交互页面

上面提到的动态页面虽然做到了动态更新数据，但组件与组件之间却仍是独立工作的沙盒模式无法交换数据，也无法感知或响应其他组件的变化。

为了实现组件之间的通信与简单交互，我们需要将不同的组件通过一些自定义的钩子 hook 起来。如下面这个例子中，list 组件 componentQuery 中的 type 字段就来自于 dropdown 组件的 activeKey。用户在改变 dropdown 组件的 activeKey 时，也会更新 list 组件获取数据所调用的 API，如 "/api/11-11-promo/electronics/list?type=kitchen" 或 "/api/11-11-promo/electronics/list?type=living" 等。

{
  "pageId": 1,
  "pageUrl": "/11-11-promo/electronics",
  "pageTitle": "双十一大促 - 家电专场",
  "layout": "two-columns",
  "components": {
    "two-columns": {
      "firstCol": [{
        "componentName": "dropdown",
        "componentProps": [{
          "title": "选择家电种类",
          "defaultActiveKey": "kitchen",
          "data": [{
            "key": "kitchen",
            "value": "厨房"
          }, {
            "key": "living",
            "value": "客厅"
          }, {
            "key": "bedroom",
            "value": "卧室"
          }]
        }]
      }],
      "secondCol": [{
        "componentName": "list",
        "componentApi": "/api/11-11-promo/electronics/list",
        "componentQuery": {
          "type": "dropdown_activeKey"
        },
        "componentProps": [{
          "title": "促销家电列表"
        }]
      }]
    }
  }
}

@前端进阶之旅: 代码已经复制到剪贴板

这样我们就实现了组件与组件之间的联动，大大拓展了页面搭建工具可覆盖的需求范围。在达到了这个阶段之后，我们甚至可以说使用页面搭建工具搭建出来的页面与日常工程师手写的页面之间区别已经不大了。但与此同时随着业务需求的复杂程度越来越高，使用页面搭建工具生成的 DSL 也会越来越复杂，它的表现力相较于代码究竟孰优孰劣，这就很考验平台设计者的内功了。

# 动态路由

可视化页面搭建工具的核心价值就是以最小的代价快速创建大量时效性较强的页面，在创建页面不再是一个问题后，如何管理这些被创建出来的页面成为了下一个待解决的问题。

假设我们现在已经创建了一个营销页面的 MongoDB 集合，每个页面都有一个自己的 uuid 如 580d69e57f038c01cc41127e 。最简单的情况下，我们可以在应用中创建一个例如 /promotion/:id 这样的路由，然后根据每个页面的 uuid 来获取页面的 DSL 数据。这样的做法非常简洁，但存在的问题是所有营销页的 url 都是无含义的 uuid，既不利于 SEO，也不利于用户以输入 url 的方式到达页面。

针对这个问题，我们需要在页面的 url 和 uuid 之间再建立起一个一一对应的关系，即后端除了要提供获取页面 DSL 数据的接口外，还需要再提供一个处理动态路由的接口。如 580d69e57f038c01cc41127e 对应的页面 url 为 /double11-promotion，那么在用户到达 /double11-promotion 页面后，前端需要先将页面的 url 发送至后端的动态路由接口以拿到页面真正的 uuid，然后再调用获取页面 DSL 数据的接口拿到页面中配置好的组件数据并渲染。

这时另一个问题出现了，前端如何区分 /double11-promotion 这种动态路由和 /home 这种固定路由呢？在前文中我们提到过 react-router 是按照所有路由定义的顺序逐一去匹配路由的，如果当前的页面路径和所有的路由都匹配不上的话，则会渲染在最后定义的 404 页面。换句话说，在简单的应用中路由只分为两种，一种是定义好的固定路由，另一种是会由 404 页面统一处理的其他路由。

const Router = ({ history }) => (
  <ConnectedRouter history={history}>
    <div>
      <Route path="/home" component={Home} />
      <Route path="/login" component={Login} />
      <Route path="/store/:id" component={Store} />
      <Route path="/404" component={NotFound} />
      <Route component={DynamicRoute} /> // try to query the url from backend
    </div>
  </ConnectedRouter>
);

@前端进阶之旅: 代码已经复制到剪贴板

# 后端路由服务的意义

甚至我们还可以推而广之，彻底抛弃掉由 react-router 等提供的前端路由服务，转而写一套自己的路由分发器，即根据页面类型的不同分别调用不同的页面渲染服务，以多种类型页面的方式来组成一个完整的前端应用。

继往开来 可视化页面搭建工具|React专题

继往开来 可视化页面搭建工具|React专题

继往开来可视化页面搭建工具|React专题

继往开来可视化页面搭建工具|React专题