現代 web 應用開發的特征一：數據驅動
前端框架發展到今天，已經出現了很多被廣泛認同的理念，也可以叫作它們的特征。在所有的特征中，最具代表性的特征之一即是數據驅動。
用戶交互的對象——界面
不論 web 應用的內部邏輯如何組織，最終與用戶產生交互的仍然是界面（User Interface，簡稱 UI）。對 web 應用來說，界面則主要由 DOM 元素來呈現。因此，歸根到底，為了讓用戶通過 web 應用完成操作，DOM 元素需要根據實際需要來不斷變化。
例如，用戶通過我們的頁面來查詢當天蘋果的價格，頁面上有一個“查詢”按鈕，還有一個顯示蘋果價格的區域，此外，在查詢過程中，還有一個加載中的提示。
<button>查詢</button>
<div class="price">今日蘋果價格為 10.00/千克</div>
<div class="loading">加載中</div>
在查詢并顯示結果的過程中，DOM 實際上會經歷這樣幾個狀態：
- 鼠標移動到按鈕上時，按鈕的樣式改變（通過 CSS
:hover或者通過 JS）。 - 按鈕按下時，按鈕的樣式改變（通過 CSS
:active或者通過 JS）。 - 清空價格區域的顯示內容。
- 將加載中的提示顯示出來。
- 待查詢到數據后，將數據拼裝成文字“今日蘋果價格為 10.00/千克”，放入價格區域中。
- 將加載中的提示隱藏。
命令式編程實現界面變化
如果將 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。我們的邏輯代碼只需要對這兩個值進行操作，即可以完成整個應用功能的界面變化。
而狀態和界面的映射則由<template>來定義，例如今日蘋果價格為 {{price}}/千克表示狀態中的price變量需要顯示在此處，v-show="isLoading"則表示是否顯示加載中完全由變量值isloading決定。
事實上當前前端主流的幾大框架，在界面的渲染上都不約而同選擇了數據驅動的方式，深入理解這一模式有助于我們更好地理解前端框架。
數據驅動帶來的好處
數據驅動界面變更能迅速被廣泛接受，也可以從側面說明它確實為開發者帶來了一些好處。
首先，因為開發者僅需要管理數據，使得關于界面細節控制的代碼不再需要開發者編寫。同時，由于狀態被抽象出來，同一個變量值在界面上的多處變化全部由映射關系來決定，而不需要開發者手工修改每一處變化。這兩者結合起來使得開發者的心智負擔大大減少，需要關注的代碼量也大大減少，從而使得開發效率得以大幅提升，出現 bug 的概率也大大減少。
其次，專門將應用狀態抽象出來，使得開發者必須認真思考代碼的組織方式，而因為界面相關細節的消失，大部分的代碼都變成了邏輯代碼，使得傳統編程中的模式都可以被應用到前端代碼中，從而使得前端代碼能夠支持更大規模的應用，也能更好地組織前端代碼本身，使得代碼更容易閱讀和維護。
狀態的抽象也使得開發者可以精準地保存和還原任意一個界面狀態。因為界面的每一時刻的界面表現都是由這一時刻的應用狀態決定，因此只要能夠將此時的應用狀態進行保存，就能在另一個時間、空間中重現應用此時的界面表現。
這個特性在某一些場景下非常好用，例如線上 bug 的排查。如果我們有辦法取到用戶的當前狀態，就有辦法完全還原用戶的界面表現，從而快速復現應用碰到的 bug，而不用再苦苦和用戶溝通詳細的操作步驟，一點點地確認應用可能是哪里出了問題。除此之外，這個特性還可以用于實現“時間旅行”效果，即應用界面的回放。我們只需要將狀態的變更都記錄下來，就能看到應用從初始化一直到最終狀態中間發生的完整事情。它本身可以作為一個效果來使用，也可以用來支持一些功能（例如撤銷/重做）。
因為應用界面完全由應用狀態決定，而狀態映射到界面的操作一般由框架來幫忙我們完成，因此在測試的時候，就有機會將重點放在狀態的測試上。即在很多情況下，我們只需要測試邏輯和數據，確保應用狀態是正確的，即可大概認為界面是正確的。
因為界面測試的成本要遠高于邏輯和數據測試，如果我們能在不做界面測試的情況下也保證應用邏輯和狀態是正確的，將大大提升測試效率。
小結
時至今日，數據驅動已經成為絕大部分前端開發者的共識，Vue 也是這一理論的實踐者，后面我們將看到 Vue 是如何實現這一重要特征的。