前端js联动-前端js联动

如下图所示，整个流程是这样的：

浏览器发起请求，当请求得到处理，服务端传输数据给浏览器以呈现界面（这个数据一般为 HTML，一种描述呈现方式的语言）。

以表单为例，在呈现为表单的界面上进行操作，按照协议和浏览器的实现，则会发起一次新的资源请求（HTTP）。

这次请求需要服务器进行资源更改，成功后则会重新返回数据给浏览器以呈现修改后的界面。

<form action="/users/1">  <label>Name:label>  <input type="text" name="name" value="Bob">  <input type="submit" value="Submit">form>

传统的 web 只有最低限度的弹窗、确认、scroll 等浏览器定义的交互元素，提交（submit）则是交互的终结。不过，随着 web 和 js 的发展，交互有了更多的可能，同时 html5、css3 也为交互提供了更大的基础。

现在，我们最直观的感受就是网站越来越“炫酷”了，同时也越来越“重”了。站在开发者的角度，前端 js 工程的打包速度甚至比后端工程还要更慢。

有没有一种可能，让我们所有的技术都回归到经典 web，回归到面向资源（resource）进行操作，回归到上个世纪重新思考交互？我们进而可以扩充浏览器的交互元素，而不用通过 js 框架实现复杂交互；扩充 HTTP 请求使其更适应浏览器呈现和交互。

举个例子，我们正要开发一个工作看板前端js联动，如果浏览器已经提供了一个通用的看板交互元素，我们是不是就可以像使用表单 form 一样，只需要利用这个交互元素再“配置”上业务信息，就能够在不使用额外 js 的情况下，完成这个功能呢？

基于以上，我们得出了这样的构思：

沉淀出一个通用的组件库（来扩充浏览器交互元素），并且这个组件库数量是固定的，我们将其称之为“通用组件”。

利用通用组件填充进业务数据后可以配置呈现出业务功能，比如登录表单、项目创建表单等；通用组件复合业务属性后，我们称之为“业务组件”，业务组件个数会随着业务增长而膨胀。

需要有一个协议来响应交互，达成上述 form 表单的交互流程，但是这个协议需要足够强大不仅能支持组件库所有组件的交互流程，还需要支持多组件联动的复杂场景；这个协议运行在 HTTP 之上，但是与 RESTful 的区别在于，REST 只关注数据且它是无状态的，而我们设想的协议需要感知界面呈现以及支持完整的交互流程。

如上图所示，通过组件库和协议，可以承载前端一半以上的工作，同时将部分减少后端与前端重叠的工作，并且前后端仍保有其自身的灵活性。

组件及协议

综上前端js联动，落实我们得出的三点构思，需要达成三个层次的事情：

我们设计了这样一个渲染框架，分两个部分（上图绿色部分）：

上图中间的通用组件库，则是由前端进行定义和维护的，前端的关注点在于要丰富这个通用组件库，以及将每个组件的交互和 UI 做到极致（后面会讲到，这些工作即是前端呈现器）。

这样的设计初衷旨在大量减少前端工作，尤其是前后端对接方面，甚至可以认为对接是“反转”的，体现在两个层面：接口定义的反转和开发时序的变化。

接口定义的反转

接口的定义上，传统的由后端主导转向为前端主导。

传统（或者说现在主流）的后端实现为 RESTful API，而前端直接对接这些散落的 API，并且理解接口内结构体的含义。但在组件化的背景下，所谓“前后端对接”被拆成了两部分：渲染和呈现。

前面所说的渲染框架（后端）实现了业务到通用组件的渲染，前端定义维护了通用组件库，并实现通用组件的“呈现器”，它将通用组件的数据呈现为可视化的形式。

在渲染和呈现之间的是标准化的通用组件结构（Component Data），我们可以认为通用组件即为前端主导定义的接口，后端由原先甩手一个 RESTful API，演变成要“被迫”理解通用组件的数据结构以实现业务逻辑，整个形势发生了反转。

有趣的是，由于通用组件的数量是确定的，我们可以将通用组件开发移植到其他不同呈现介质，甚至可以开发出 CLI 界面的呈现器，且后端代码无需修改。

开发时序的变化

由传统的后端开发完成后前端联调，转向为前端先完成开发而后端配合联调。

“呈现器”使得前端只需要关注通用组件的开发，业务逻辑可以彻底归为后端。如此职责的划分让前端跳出对后端的依赖，可以独立完成设计、开发和调试（只需要 mock 组件数据）。组件的高度复用，前端甚至可以摇身一变成为设计师，跳过高保真设计稿，直接交付实物，而这个时候的后端可能还在与表结构设计苦苦挣扎。

更重要的不仅仅是前端的开发时间缩短。

我们可以类比 RESTful API 形式的前后端分离，同样都是通过“接口”来标准化对接以实现解耦。REST 接口显然是会随着业务而膨胀的，通用组件的真正优势在于彻底剥除业务，使得它的数量相对恒定且极少。我们都知道少即是美（simple is better），实践证明组件越少越能保证每个组件的质量，而前端通过这些高质量组件完成的功能，几乎可以认为，调试的工作都在后端了。

更多

在下篇文章中，我们将会详细地介绍组件渲染和协议渲染的运行逻辑，以及我们是如何做到让前端彻底不关心业务的？

目前 Erda 的所有代码均已开源，希望你也能够参与进来！关于 Erda，如果你有其它想要了解的内容，欢迎添加小助手微信（Erda202106）加入交流群！