关于前端工程:我来聊聊面向模板的前端开发

在软件开发中，研发效率永远是开发人员一直谋求的主题之一。于公司而言，在竞争强烈的互联网行业中，产出得快和慢兴许就决定着公司的生死存亡；于集体而言，效率高了就能够少加班，多出工夫去晋升本人、倒退喜好、陪伴家人，工作、生存两不误。

晋升效率的路径，无外乎就是「办法」和「工具」。以一个开发者的思维来想，就是将工作内容进行总结、演绎，从一组类似的工作内容中提炼共同点，形象出解决这一类问题的办法，从而造出便于在今后的工作中更为疾速解决这类问题的工具。这个「工具」能够是个函数、组件、中间件、插件，也能够是 IDE、其余开发工具的扩大，甚至是语言。

面向组件

在古代前端开发中，如果去问一个业务前端开发：「如何晋升团队开发效率？」对方所答复的内容中，极有可能会呈现「组件库」。没错，在前端工程化趋近欠缺的明天，在近几年 React、Vue 等组件化库 / 框架的影响下，面向组件开发的思维形式早已深入人心。

组件库提效无限

当初，组件库曾经是一个前端团队的必备设施了，久远来看，团队肯定且必须要有本人的组件库。开源的第三方组件库再好，对于一家企业的前端团队来说也只是短期用来充饥的，因为它们无奈齐全满足一家公司的业务场景，并且出于多终端反对的思考，必然要进行二次开发或者自研。

组件库有了，团队和公司中推广的成果也不错，绝大多数的人都在用。应用组件开发页面绝对 jQuery 时代要每块功能区都得从 <span>、<div> 等 HTML 标签码起来说的确晋升了效率，然而无限；要搞出页面须要重复去引入组件，而后组合拼装进去，就像工厂流水线上的工人拼装整机，依然要去做很多反复动作。

只有感觉以后的开发方式反复的动作多了，就代表还能持续提效，得想个法子缩小反复无意义动作。

面向组件的开发方式，是古代前端页面开发提效的初级阶段，也是一个团队所要必经的阶段。

更高层面的提效

在之前写的文章中有段话——

组件能够很简略，也能够很简单。依照复杂程度从小到大排的话，能够分为几类：

1. 根底组件；
2. 复合组件；
3. 页面；
4. 利用。

对，不必揉眼睛，你没有看错！

站在更高的角度去看，「页面」和「利用」也是一种「组件」，只不过它们更为简单。在这里我想要说的不是它们，而是「根底组件」和「复合组件」。

欧雷《我来聊聊面向组件的前端开发》

文中提到了「页面」和「利用」也能够看作是种「组件」。尽管与过后的想法有些差别，但本文的内容就是要在那篇文章的根底上简略聊聊在「页面」层面的提效。

一般来说，「页面」是用户所能看到的最大、最残缺的界面，如果能在这个层面有个很好的形象计划，在做业务开发时与单纯高空向组件开发相比，应该会有更大的提效成果。

GUI 倒退了几十年，人机交互的图形元素及布局形式曾经绝对固定，只有不是呈现像 Google Glass 之类的革命性交互设施，就不会产生重大扭转。在业务开发中界面模式更是千篇一律，尤其是 web 页面，尤其是中后盾零碎的 web 页面，肯定能够通过什么形式来将这种「千篇一律」进行形象。

试着来回忆下，本人所做过的中后盾零碎的绝大部分页面是不是我所形容的这样——

页面整体是高低或左右布局。如果是高低布局的话，下面是页头，上面的左侧可能有带页面导航的侧边栏，或者没有侧边栏间接将页面导航全副集中在页头中，残余区域是页面主体局部，承载着这个页面的次要数据和性能；如果是左右布局，左侧毋庸置疑就是有页面导航的侧边栏，页头跑到了右侧下面，其余是页面主体。

中后盾零碎的次要性能就是 CRUD，即业务数据的增删改查，绝对应的页面展示及交互模式就是列表页、表单页和详情页。列表页汇总了所有业务数据的简要信息，并提供了数据的增、删、改和更多信息查看的入口；表单页肩负着数据新增和批改的性能；详情页可能看到一条业务数据记录最残缺的信息。

每新增一个业务模块，就要又写一遍列表页、表单页和详情页……重复做这种事件有啥意思呢？既然这三种页面会重复呈现，那罗唆封装几个页面级别的组件好了，有新需要的时候就建几个页面入口文件，外面别离引入相应的页面组件，传入一些 props，完活儿！

这种形式看起来不错，然而存在几个问题：

• 没有形容出页面内容的构造，已封装好的页面组件对于使用者来说算是个黑盒子，页面内容是什么构造不去看源码不得而知；
• 如果新需要中尽管须要列表页、表单页和详情页，但与已封装好的可能笼罩大部分场景的相干组件所反对的页面有些差别，扩展性是个问题；
• 每来新需要就要新建页面入口文件而后在外面引入页面组件，还是会有很多无意义反复动作和反复代码，工夫长了还是感觉烦。

我须要一种既能看一眼就理解内容构造和关系，又具备较好扩展性，还能缩小反复代码和无意义动作的形式——是的，兜了一个大圈子终于要进入正题了——面向模板开发。

面向模板

面向模板的前端开发有三大因素：模板；节点；部件。

富裕表达力的模板

我所说的「模板」的次要作用是内容构造的形容以及页面的配置，观感上与 XHTML 相近。它次要具备以下几个特色：

1. 字符全副小写，多单词用连接符「-」连贯，无子孙的标签间接闭合；
2. 蕴含极少的具备形象语义的标签的标签集；
3. 以特定标签的特定属性的模式反对无限的轻逻辑。

为什么不抉择用 JSON 或 JSX 来形容和配置页面？因为模板更合乎直觉，更易读，并且中立。用模板的话，一眼就能简直不必思考地看出都有啥，以及层级关系；如果是 JSON 或 JSX，还得在脑中进行转换，减少心智累赘，并且拼写起来绝对简单。Vue 上手如此「简略」的起因之一，就是它「合乎直觉」的设计。

要应用模板去形容页面的话，就得自定义一套具备形象语义的标签集。

页面的整体布局能够用如下模板构造去形容：

<layout>
  <header>
    <title> 欧雷流 </title>
    <navs />
  </header>
  <layout>
    <sidebar>
      <navs />
    </sidebar>
    <content>...</content>
  </layout>
  <footer>...</footer>
</layout>

看起来是不是跟 HTML 标签很像？但它们并不是 HTML 标签，也不会进行渲染，只是用来形容页面的一段文本。

整体布局能够形容了，但承载整个页面的次要数据和性能的主体局部该如何去形容呢？

在上文中提到，咱们习惯将中后盾零碎中与数据的增删改查绝对应的页面称为「列表页」、「表单页」和「详情页」。尽管它们中都带有「页」，但真正有区别的只是整个页面中的一部分区域，通常是页面主体局部。它们能够被别离看成是一种视图模式，所以能够将称说略微扭转一下——「列表视图」、「表单视图」和「详情视图」。个别状况下，表单视图和详情视图长得根本一样，就是一个能编辑一个不能，能够将它们合称为「表单 / 详情视图」。

「视图」只形容了一个数据的汇合该展现成啥样，并没有也没法去形容每个数据是什么以及长啥样，须要一个更小粒度的且可能去形容每个数据单元的概念——「字段」。这样一来，用来形容数据的概念和模板标签曾经齐活儿了：

<view>
  <field name="name" label="姓名" />
  <field name="gender" label="性别" />
  <field name="age" label="年龄" />
  <field name="birthday" label="生日" />
</view>

尽管数据可能形容了，但还有些欠缺：表单 / 详情视图中想将字段分组展现没法形容；对数据的操作也没有形容。为了解决这两个问题，再引入「分组」和「动作」。这下，表单 / 详情视图的模板看起来会是这样：

<view>
  <group title="根本信息">
    <field name="name" label="姓名" />
    <field name="gender" label="性别" />
    <field name="age" label="年龄" />
    <field name="birthday" label="生日" />
  </group>
  <group title="宠物">
    <field name="dogs" label="🐶" />
    <field name="cats" label="🐱" />
  </group>
  <action ref="submit" text="提交" />
  <action ref="reset" text="重置" />
  <action ref="cancel" text="勾销" />
</view>

模板很好地解决了内容构造形容和配置的问题，但如何去动静地调整结构和更改配置呢？在平时的业务页面开发时兴许不会太凸显出问题，但碰到流程表单设计或页面可视化编辑这种灵活性很高的需要时，问题就会被裸露进去了。

充斥控制力的节点

在这里，我要将定义好的标签集所拼成的模板解析成节点树，通过更改树的构造和节点的属性去影响页面最终的出现成果。每个节点都会有节点的根本信息、对应标签的属性和一些节点操作方法：

{
  name: "field",
  tag: "field",
  attrs: {
    name: "name",
    label: "姓名"
  },
  parent: {},
  children: [],
  remove: function() {},
  insert: function() {}
}

在页面模板化且节点化之后，现实状况下，页面长啥样曾经不受如 React、Vue 等运行时技术栈的解放，控制权齐全在解析模板所生成的节点树上，要想扭转页面的视觉效果时只需更改节点即可。

极具表现力的部件

页面内容的形容通过模板来表白了，页面内容的控制权集中到节点树中了，那么页面内容的出现在这种体系下应该如何去做呢？负责这块的，就是接下来要说的面向模板开发的第三大因素——部件。

「部件」这个词不陈腐，但在我所说的这个面向模板开发的体系中的含意，须要被从新定义一下：「部件」是一个可复用的，显示的信息排列可由用户扭转的，能够进行交互的 GUI 元素。

在这个面向模板开发的体系中，模板和节点树齐全是中立的，即不受运行时的技术栈所影响；而部件是建设在运行时技术栈的根底之上，但不用限于同一个技术栈。也就是说，能够应用 React 组件，也能够用 Vue 组件。

每个部件在应用前都须要注册，而后在模板中通过 widget 属性援用：

<view widget="form">
  <group title="根本信息" widget="fieldset">
    <field name="name" label="姓名" widget="input" />
    <field name="gender" label="性别" widget="radio" />
    <field name="age" label="年龄" widget="number" />
    <field name="birthday" label="生日" widget="date-picker" />
  </group>
  <group title="宠物" widget="fieldset">
    <field name="dogs" label="🐶" widget="select" />
    <field name="cats" label="🐱" widget="select" />
  </group>
  <action ref="submit" text="提交" widget="button" />
  <action ref="reset" text="重置" widget="button" />
  <action ref="cancel" text="勾销" widget="button" />
</view>

这样，一个面向模板开发的一般表单页进去了！

思维总结

面向模板的开发方式很好，可能大幅度提高业务前端开发效率，肯定水平上缩小了业务零碎的搭建速度；作为外围的模板和节点树是保持中立的，大大降低了运行时技术栈的迁徙老本，且可能应答多端等场景。

面向模板的开发方式初期投入老本很高，标签集、模板解析和部件注册与调用机制等的设计和实现须要较多工夫，并且这仅仅是视图层，逻辑层也须要做出相应的变动，不能简略地用 props 和事件绑定进行解决了。

这个体系建成之后，在业务开发上会很简略，但机制了解上会减少局部开发人员的心智累赘。

为了效率，一家公司里的业务前端开发到最初肯定是面向模板，而非面向组件。

本文其余浏览地址：集体网站|微信公众号