这是第 46 篇不掺水的原创，想获取更多原创好文，请扫 👆上方二维码关注我们吧~
本文首发于前端早早聊公众号：第三届搞搭建|洛尘 - 如何设计实现 PC 站点搭建系统 - Schema

介绍

大家好，我是洛尘，来自于政采云前端团队，2014 年毕业于浙江工业大学，做过 .net ，写过 Java，玩过数据库，2015 年才加入前端这个大家庭，这一路上，见证了前端从 Jquey —> Angular -> React/Vue 的转变，经历过一个降薪、裁员，还经历过一个子公司从创立到解散。2019 年 1 月，正式加入政采云有限公司，负责“鲁班”搭建系统相关的前端基建工作，是一枚普通的前端打字工程师。

什么是搭建系统

搭建系统话题引入

完成业务需求是我们的本职工作，需求评审->开发->提测->上线，上线完了以后呢，又是下一轮的需求评审->开发->提测->上线，3 年，5 年，10 年过去了，你学会了什么？需求评审，还有开发，这是出蛮力。那么如何优雅的去解决业务问题，这就涉及到我们今天讨论的话题 —— 搭建系统。

业务场景

技术是用来服务于业务的，没有业务场景的技术建设，都是耍流氓。那让我们一起来看看搭建系统的业务场景有哪些：

上述场景都是真实存在的，在我们公司，门户网站的需求量是很大的，而且很多门户网站的相似度极高，这就意味着，只要视觉规范保持一致的情况下，前端的元件、组件、模块甚至是模板是可以进行大量复用的；还有，运营所提的需求体量小，功能小点多，需求的优先级自然提不上来，运营自己又无能为力，最终导致流量和用户的流失；对于前端来说，重复的业务需求，对于自身成长毫无价值可言，渐渐的也就麻木了，离当时定下的一个亿的小目标越来越远，成为了无情的编码机器。

业务实例

下面这些都是我们公司的门户网站，顶通、头部导航、Banner 位、商品类目、快捷入口等等都是极度的相似，这也将组件/模块的重复利用成为了可能，也是搭建系统存在的前提之一。

我们再看另一个例子，图中红框选中区域，都是运营/产品希望手动配置数据的模块，它几乎占据了页面内容的 70% 之多，也就可以想象运营所提需求不能得到及时解决时，内心到底有多痛苦。

搭建系统长什么样

我们的搭建系统一共分为 3 个主要功能模块，1 个数据模块，1 个权限模块。

站点管理：站点这个东西，为了方便理解，你可以认为是一种业务分类，每类业务对应一个站点（分类）
页面管理：这是搭建的核心功能，具体功能可以看下面连续的四段录屏
组件管理：一个页面会用到很多组件，不同的页面也会用到同一个组件的不同版本，这就是组件管理存在的意义
数据看板：如何体现一个系统是否带来了价值，是否被有效的利用，数据才是最直观的表达方式。
权限：权限分为两部分：一部分是菜单和操作权限的控制，另一部分是系统自身的数据权限控制，也就是约束用户的数据可见范围，数据权限这块尤为重要，如果任何人都可以对数据进行编辑，那是非常危险的事

架构图

部署

搭建系统要怎么部署？有小伙伴可能会疑惑：这尼玛还能怎么部署，测试、预发、生产环境各来一套呗。你只说对了一半。问大家一个问题：不同环境的页面是不是同一个？是同一个吧！不对，是长得一样的三个页面！！那么这个时候，我们就会有一个心里预期：只做一次页面搭建，能在三个环境生效。那这要怎么做？让搭建系统本身部署在一个环境上，而且最好是生产环境单独服务器，然后让这台服务器和其他三个业务环境打通，也就是说，在生产环境产出页面，然后通过“发布”操作把页面同步到测试，预发，生产这三个业务环境，这样就可以达到我们的预期。

上面说了这么多，大家也应该对于搭建有一定的印象了，接下来我们进入这次分享的正题。

如何配数据

JSON Schema

说到数据，大家肯定会想到什么？String，Number，Boolean 对不对，但今天我要说的是 JSON ，准确的来说是 JSON Schema ，那么请大家来思考一下这个问题，JSON Schema 到底是 JSON 的扩展？还是 JSON 的约束？

答案是：约束。其实 JSON Schema 就是一个标准化/规范化的 JSON 数据。那 JSON Schema 是怎么定义出来的，这也就是下面我要讲解的内容。我们先从简单示例入手。

简单示例

这是一个很常见的 Form 表单，其中包括输入框，下拉框，开关。其中包含的元素包括：label（主题色、账号）、placeholder、type（input、switch）、data（下拉框的选项）、key（字段名）、value（字段值）。刚才说的这些都和我们的 JSON Schema 定义息息相关。

把刚才属性的定义整理一下，拿其中一个“主题色”的下拉框举例：

可以看到我们用一段 JSON 数据描述了一个具体的页面元素，这就是 JSON Schema 在搭建中要达到的效果。

当然了除了页面元素的定义以外，页面还需要有初始数据，初始数据的定义就简单很多，大概是这样：

扩展类型

上面说到的 input、switch 都是根据场景定义的类型，我们也可以将 input定义为 string，switch 定义为Boolean，这些都是通过场景人为定义的一些分类标准，没有固定的表达形式，只要你确保定义合理，并且容易被人理解即可。除此之外，平常业务当中比较常见的还有这些：

总结

在平时编码过程中，我们用来定义数据最多，也最常见的复杂类型是对象（Object）和数组（Array），而构成对象和数组的最常见的基本类型是 String 和 Number，也可以是扩展类型。

说了这么多 JSON Schema 相关的内容，那它和我们的业务到底有什么关系，让我们一起来看看

业务场景

这是一个我们公司的门户网站，图上红框标记部分都是运营或者产品希望能够动态配置数据的地方，这几乎包括了页面 70% 的内容，也足以说明数据动态配置在业务中的重要性，那如何将数据配置和我们的 JSON Schema 产生关系呢？

将业务转化为数据

第一步，我们需要将业务场景转化为客观存在的数据，拿其中一小块来举例：

从图中可以看到这是一个各省份的快捷入口，这一小块页面它对应的数据就是这样：

很常见，也很简单对不对，那接下来我们进入第二步：

将数据转化为定义

上面我们提到过很多的类型定义，那我们先在将这些定义引入到我们的业务场景中来。

我可以看到这份数据，它的数据类型是 Array，其中包括了“地名”、“图标”、“链接”、“描述”字段。我们拿地名、图标这二个字段来进行举例举例：

地名：label = 地名，key = addressName，type = String
图标：label = 图标，key = icon，type = Select，data = {icon1: icon1, icon2: icon2}

然后，我们将他们进行整合，可以得到最后这样的结果。

将定义规范成结构

我们已经有能力可以将一个页面模块转化为一份简单的 JSON Schema 片段，同样的，我们也可以将其他模块做同样的转化，不管是 Object ，还是 Array ，甚至是 Two-dimensional Array（二维数组），然后，我们将每一份 JSON Schema 片段进行整合，当然了，光有定义还不够，页面还需要有数据，这样我们就可以得出完整的 JSON Schema 结构：

可视化

最后你可以根据你的可视化需要，写一个符合你自己页面设计的 format 函数，对这一份 JSON Schema 数据进行转化，最终渲染成为一个表单、表格或者其他样子。下图是我将 JSON Schema 转化后渲染得到的运营数据配置页，给大家做个参考：

总结

体系和扩展

搭建系统是前端工程化体系之一，我们可以根据不同的业务场景，建设不同规模的搭建系统：元件级、组件级、模板级、甚至是应用级的；从搭建场景来看，可以是单个页面、也可以是整条业务链路、营销活动、甚至是整个中台；从终端类型来看：可以是 PC、H5、Native、小程序等等；为保证搭建系统的稳定性，产出高质量、高性能的页面，我们还需要一些其他能力的支持：自身的系统的容灾策略，比方说，页面丢了需要怎么样的兜底方案，数据丢了怎么找回，发布失败了怎么办回滚；从规范层面来说，我们需要有一套完整的脚手架，约束和规范组件的开发生命周期；从产出层面来说，我们需要保证搭建产出的页面性能相对可观，因此就涉及到页面性能检测，这又是一套完整的系统，我们的性能检测系统叫做“百策”，它和搭建系统进行横向打通，提供搭建页面性能检测能力。忽然说到了页面，自然就少不了数据：BFF 层、数据共享、Ajax 请求聚合等等。

上面说到的这一切的一切，不管是一个小点还是一个大的方向，只要你抓住了业务的痛点，为其设计一套通用的可行性方案，并落地成为一套系统反哺于业务，那都是一种质突破，也是走向产品化、智能化的一大步。谨记：你的一小步，业务一大步。

快到碗里来，我们招人了！！！

团队最新的招聘信息，请扫下方二维码关注“政采云前端团队”微信公众号获取，期待你的加入。

简历自荐推荐，请发送至 ZooTeam@cai-inc.com