前端页面field_我来聊聊前端应用表现层抽象

本文首发于欧雷流。由于我会时不时对文章进行补充、修正和润色，为了保证所看到的是最新版本，请阅读原文。

我们处于变化很快的时代，无论是商业还是科技。一家公司看上去商业很成功，也许前脚刚上市，后脚就因为什么而退市，甚至倒闭；一项看似高大上的技术横空出世，各类媒体争先恐后地撰文介绍，热度炒得老高，没准没多久就出现了竞争者、替代者。

在这样的大环境下，传统的「web 前端开发」演变成了「泛客户端开发」，前端开发者从「配置工程师」被「逼」成了「软件工程师」。开发变得更复杂了，要处理的问题更多了，从业难度不知提升了多少倍——前端早就不再简单。

在众多必须要处理的问题中的一个，就是表现层运行环境的兼容问题，像跨浏览器和跨端、平台、技术栈。注意，这里说的是「表现层」而不是「视图层」。

「表现层」与「视图层」

「表现层」的英文是「presentation tier」或「presentation layer」，具体是哪个取决于是物理上还是逻辑上划分；而「视图层」的英文是「view」。「表现层」是「视图层」的超集，根据前端应用的架构设计，它们既可以不等又可以相等。

表现层

「表现层」这个词出自经典的三层架构（或多层架构），是其中一个分层。三层架构包括数据层、逻辑层和表现层，一般用在 C/S 架构中。

三层架构

为什么会在这篇讲前端开发的文章中提到它？这是因为，虽然在一些前端应用中用不到，尤其是快餐式应用，但在企业级复杂前端应用中就十分需要一个前端的「三层架构」。

视图层

「视图层」则来自表现层常用的「model-view-whatever」模式中的「view」，即「视图」。至于说的时候在「视图」后面加个「层」字合不合适，就不在这里讨论了，文中皆使用「视图层」这个词。

运行环境兼容

跨浏览器

由于各浏览器厂商对标准实现的不一致以及浏览器的版本等原因，会导致特性支持不同、界面显示 bug 等问题的出现。但庆幸的是，他们基本是按照标准来的，所以在开发时源码的语法几乎没什么不同。

所谓的「跨浏览器」实际上就是利用浏览器额外的私有特性和技术或辅以 JS 对浏览器的 bug 进行「修正」与功能支持。

跨端、平台、技术栈

现在，绝大部分的前端开发者是在做泛客户端开发——开发 web 应用、客户端应用和各类小程序。

在做 web 应用时需要考虑 PC 端和移动端是分开还是适配？技术选型是用 React、Vue？还是用 Web Components？或是用其他的？做客户端应用、各类小程序时这些也会面临技术选型的问题。

如果公司某个业务的功能覆盖了上述所有场景，该如何去支撑？与跨浏览器不同的是，不同端、平台、技术栈的源码语法不一样，要满足业务需求就得各开发一遍。然而，这显然成本过高，并且风险也有些大。

那么，要怎么解决这个问题呢？从源头出发。根本的源头是业务场景，然后是产品设计，但这些都不是开发人员可掌控的，几乎无法改变。能够完全被开发人员所左右的基本只有开发阶段的事情，那就从这个阶段的源头入手——源码编写。

若是与业务相关的代码只需编写一次就能运行在不同的端、平台、技术栈上，那真是太棒了！这将会大大地降低成本并减少风险！

表现层的抽象

为了达到跨端、平台、技术栈的目的，需要将表现层再划分为抽象层、运行层和适配层。其中，抽象层是为了统一源码的编写方式，可以是 DSL、配置等，它是一种协议或约定；运行层就是需要被「跨」的端、平台、技术栈；适配层则是将抽象层的产物转换为运行层正常运行所需要的形式。

表现层中可以被抽象的大概有视图结构、组件外观、组件行为等。

视图结构