知识点一：数据驱动

素颜马尾好姑娘i 2022-08-29 10:55 217阅读 0赞

前端框架发展到今天，已经出现了很多被广泛认同的理念，也可以叫作它们的特征。在所有的特征中，最具代表性的特征之一即是数据驱动。

**用户交互的对象——界面**

不论 web 应用的内部逻辑如何组织，最终与用户产生交互的仍然是界面（User Interface，简称 UI）。对 web 应用来说，界面则主要由 DOM 元素来呈现。因此，归根到底，为了让用户通过 web 应用完成操作，DOM 元素需要根据实际需要来不断变化。

例如，用户通过我们的页面来查询当天苹果的价格，页面上有一个“查询”按钮，还有一个显示苹果价格的区域，此外，在查询过程中，还有一个加载中的提示。

<button>查询</button> <div class="price">今日苹果价格为 10.00/千克</div> <div class="loading">加载中</div>

在查询并显示结果的过程中，DOM 实际上会经历这样几个状态：

1.  鼠标移动到按钮上时，按钮的样式改变（通过 CSS
2.  :hover

1.  或者通过 JS）。
2.  按钮按下时，按钮的样式改变（通过 CSS

1.  :active
2.  或者通过 JS）。

1.  清空价格区域的显示内容。
2.  将加载中的提示显示出来。

1.  待查询到数据后，将数据拼装成文字“今日苹果价格为 10.00/千克”，放入价格区域中。
2.  将加载中的提示隐藏。

**命令式编程实现界面变化**

如果将 1 和 2 使用 CSS 来处理，那么早期我们的 JavaScript 代码大概是这样：

// 3. 清空价格区域的显示内容 price.innerHTML = ''; // 4. 将加载中的提示显示出来 loading.style.display = 'block'; // 查询价格 queryPrice(function(data)\{ // 5. 待查询到数据后，将数据拼装成文字“今日苹果价格为 10.00/千克”，放入价格区域中 price.innerHTML = '今日苹果价格为 ' + data.price + '/千克'; // 6. 将加载中的提示隐藏 loading.style.display = 'none'; \});

即使是引入 jQuery 之类的库，整个过程仍然不会有实质性的变化，主要靠每一行 JavaScript 代码命令式地修改 DOM 元素来达到修改界面的目的。

**数据驱动界面改动**

既然需要不断修改界面，而命令式修改界面又如此繁琐，是否有别的方法来修改界面呢？数据驱动的概念应运而生。它的基本思想是：使用数据来描述应用的状态，将界面的修改与数据的修改绑定起来，从而实现数据的任何修改都直接反映到界面的修改。

如果用一个公式来表示的话，可以写成UI=F(state)，UI 即指用户界面，state指应用的状态，而F则是应用状态与用户界面的映射关系定义。它最直观的理解是“应用的任何状态，都可以通过一种确定的映射关系，反映到界面的某种状态上”，因此只要状态发生变化，界面也会发生变化。

上述例子使用 Vue 来编写：

<template> <button @click="query">查询</button> <div class="price">今日苹果价格为 \{ \{price\}\}/千克</div> <div class="loading" v-show="isLoading">加载中</div> </template> <script> export default \{ data()\{ return \{ price: 0, isLoading: false \} \}, methods: \{ query()\{ this.isLoading = true; queryPrice((data) => \{ this.price = data.price; this.isLoading = false; \}); \} \} \} </script>

在上述代码中，应用的状态就是data，包括两个值price和isLoading。我们的逻辑代码只需要对这两个值进行操作，即可以完成整个应用功能的界面变化。

而状态和界面的映射则由来定义，例如今日苹果价格为 \{ \{price\}\}/千克表示状态中的price变量需要显示在此处，v-show="isLoading"则表示是否显示加载中完全由变量值isloading决定。

事实上当前前端主流的几大框架，在界面的渲染上都不约而同选择了数据驱动的方式，深入理解这一模式有助于我们更好地理解前端框架。

**数据驱动带来的好处**

数据驱动界面变更能迅速被广泛接受，也可以从侧面说明它确实为开发者带来了一些好处。

首先，因为开发者仅需要管理数据，使得关于界面细节控制的代码不再需要开发者编写。同时，由于状态被抽象出来，同一个变量值在界面上的多处变化全部由映射关系来决定，而不需要开发者手工修改每一处变化。这两者结合起来使得开发者的心智负担大大减少，需要关注的代码量也大大减少，从而使得开发效率得以大幅提升，出现 bug 的概率也大大减少。

其次，专门将应用状态抽象出来，使得开发者必须认真思考代码的组织方式，而因为界面相关细节的消失，大部分的代码都变成了逻辑代码，使得传统编程中的模式都可以被应用到前端代码中，从而使得前端代码能够支持更大规模的应用，也能更好地组织前端代码本身，使得代码更容易阅读和维护。

状态的抽象也使得开发者可以精准地保存和还原任意一个界面状态。因为界面的每一时刻的界面表现都是由这一时刻的应用状态决定，因此只要能够将此时的应用状态进行保存，就能在另一个时间、空间中重现应用此时的界面表现。

这个特性在某一些场景下非常好用，例如线上 bug 的排查。如果我们有办法取到用户的当前状态，就有办法完全还原用户的界面表现，从而快速复现应用碰到的 bug，而不用再苦苦和用户沟通详细的操作步骤，一点点地确认应用可能是哪里出了问题。除此之外，这个特性还可以用于实现“时间旅行”效果，即应用界面的回放。我们只需要将状态的变更都记录下来，就能看到应用从初始化一直到最终状态中间发生的完整事情。它本身可以作为一个效果来使用，也可以用来支持一些功能（例如撤销/重做）。

因为应用界面完全由应用状态决定，而状态映射到界面的操作一般由框架来帮忙我们完成，因此在测试的时候，就有机会将重点放在状态的测试上。即在很多情况下，我们只需要测试逻辑和数据，确保应用状态是正确的，即可大概认为界面是正确的。

因为界面测试的成本要远高于逻辑和数据测试，如果我们能在不做界面测试的情况下也保证应用逻辑和状态是正确的，将大大提升测试效率。

**小结**

时至今日，数据驱动已经成为绝大部分前端开发者的共识，Vue 也是这一理论的实践者，后面我们将看到 Vue 是如何实现这一重要特征的