前端之變（六）：引領式變革，從命令式UI到宣告式UI

當我在2020年使用前端的技術堆疊去撰寫一個跨平臺桌面App時，發現前端在UI方面其模式與我在移動端接觸到的有很大的差異，那時候我意識到原來在前端，其UI使用的是另一種模式，后面我才知道它的名字：宣告式UI

事實上，前端本身也經歷了變革，至少在JQuery時代，它與移動端一致，其UI模式仍然屬于傳統的命令式UI，但到了React及Vue的時代，它變成了宣告式UI，從我有限的知識來看，至少在大前端的其它兩個方向：移動端與桌面開發，并未優先引領式的出現這種變革，

因此，我把前端的這種變革，稱之為：引領式變革，

它改變的不僅僅是自己，而且正在改變移動端，無論是Android官方自己主推的Jetpack，還是iOS官方新的UI框架SwiftUI，與之前也完全不同，都從命令式UI變為宣告式UI，很難說這種變革，沒有受到前端的影響或借鑒，

這說明前端技術變革不僅改變了自身，甚至在一些方面走在了更前面，

本周，繼續就前端之變闡述自己的思考與分析，這是第六篇，前面幾篇分別是：

1. 前端之變（一）：技術的變與不變
2. 前端之變（二）：不變的前端
3. 前端之變（三）：變革與突破
4. 前端之變（四）：進擊的前端
5. 前端之變（五）：王者歸來

命令式與宣告式

首先，要明確一個前提，UI這個事情，只在大前端才有，所以，無論是命令式UI還是宣告式UI，在后端編碼是不存在這個概念的，

當然，若干年前，后端兼顧前端頁面的開發，但那個時代已經過去了，現在主流的模式應該是前后端分離，由后端人員同時來開發前端，比如用JSP或FreeMarker模板技術的做法，在現在應該不多見了，不能算主流了，

UI這個事情并非只在Web前端才有，事實上，在技術的幾個方向，除了后端以外，包括前端，移動端及桌面端都存在UI，

因此，無論是命令式UI，還是宣告式UI，其概念是同時適應于前端，移動端以及桌面端的，

在這個前提之下，我們就可以來仔細分析下，在前端發生變革以前，事實上無論是在前端，移動端還是桌面端，其UI的編碼模式都屬于命令式UI

什么是命令式UI

UI的更新是由程式員使用代碼主動重繪，UI與資料并無必然的映射關系，這種我們稱之為命令式UI

什么是宣告式UI

UI的更新并非由程式員使用代碼來主動重繪，而是由后面隱藏機制來負責維護UI的重繪，UI與資料有映射關系，這種我們就稱之為宣告式UI

上面這種定義是我的定義，根據上述定義，區分是命令式UI還是宣告式UI的兩個核心點是：

1. 程式員是否要顯式的去呼叫代碼重繪UI
2. UI與資料是否存在映射關系

傳統UI模式：命令式UI

我們回到過往的時光，在那個還是JQuery主導前端開發的時代，我們設想一個最簡單的需求：記住上一次的登錄用戶名

我在這里用前端與移動端的代碼來示例，展現命令式UI的做法:

前端

//基于JQuery的實作
const lastLoginUsername = localstorage.getItem("lastLoginUsername")
$("#username").val(lastLoginUsername);//主動重繪UI

移動端

//Android + Java
String lastLoginUsername = preferences.getString("lastLoginUsername", "");
usernameInput.setText(lastLoginUsername);//主動重繪UI

上述的這些實作，就是典型的命令式UI，它都具備幾個特點：

• 在程式中，你可以顯式的參考或拿到UI組件
• UI組件的內容是怎么樣，什么時候改變內容，都是由程式員在合適的時候進行處理，UI本身與資料并無直接的映射關聯，都是由程式員將資料顯式的注入到UI中，

無論是傳統的前端開發，還是我前些年開發原生iOS與Android，都統一屬于這種模式，它們都毫不例外的屬于命令式UI，

這種命令式UI的模式，是存在一些問題的，表現在：

UI維護作業較重

從上面我的描述可以看出，整體UI行為，怎么樣，什么時候怎么改變，要全部由程式員使用代碼來處理，可想而知，這個程序顯然是非常繁重的，事實上，可以說，無論是過往的前端，還是現在的移動端，可能有相當一部分作業都是在處理UI的各種重繪上面，

易于出錯

很顯然，需要重繪UI的時機很多，比如下拉重繪，通知資料變更，網路不好資料加載錯誤，其它模塊變更引發的聯動UI變更等等，很多情況下需要你處理UI的重繪作業，

需要處理的事情一旦多起來，出錯的概率就再所難免了，

性能不佳

通過一個UI包含很多內容與組件，但需要重繪時，你是怎么處理重繪的？

是不管三七二十一，將所有UI內容全部設定一下，還是先對比下，有改變的再重繪，沒改變的不再重繪？

可能有相當一部分比例，是屬于全部設定一下的做法，這種的性能肯定不會太好，產生了許多不必要重繪，

當然，如果你比對然后只盡量做必要性的重繪，那這個事也有相當的復雜度的，而且可能易于出錯，

UI與資料易出現不一致

想像一下吧，你的代碼中有一份資料，這份資料決定了UI的展現，但事實上程式員是分開處理這兩個部分的，由一些代碼來呼叫重繪資料，再由一些方法現重繪UI，無論你做的多么周到，出現資料變更 ，UI卻忘記重繪的可能性仍然是非常高的，

因此，UI與資料出現不一致的可能性極高，

所幸，宣告式UI出現了，它極大的改善了這些問題，

變革之道：宣告式UI

宣告式UI與命令式UI的最核心的區別在于：

1. UI是資料的映射與描述，甚至一些框架中，程式員是無法持有UI組件的，更談不上去呼叫這個組件的方法重繪UI了，
2. 程式員關心的只是資料，只需要在合適的時機重繪資料就行了，UI則根據映射，由技術背后的機制幫你去重繪處理，

很顯然，這是對命令式UI做了根本性的改變，

我在這舉一個簡單的例子，仍然以記住上一次登錄用戶這個需求為例，

//代碼做了刪減，只保留了有關的部分
export const LoginView = observer(() => {

  const [username, setUsername] = useState(localStorage.getItem('login_username'));

  return (
    <Input className="input_username" value={username} onChange={e => setUsername(e.target.value)} />
  );
});

這是一個React代碼，你可以看到，input_username這個輸入框的值是{username}這個變數，而要修改這個輸入框的值的方式，也不是呼叫UI的方法去設定值，而是通過改變username這個變數來實作，

所以，修改這個UI的內容的方法是

onChange={e => setUsername(e.target.value)}

一旦你改變了username的值，input_username的內容自動的重繪改變了，并不需要程式員去介入UI的重繪作業，

這就是宣告式UI

宣告式UI如果要論述，可以說的很多，我這篇文章的目的不在于此，就不詳細去解釋它了，

當然，很明顯，與命令式UI相比，上述的幾個缺點都有所改善：

程式員沒有復雜的UI操作

在宣告式UI中，程式員要做的就是定義資料與UI的映射關系而已，一旦定義好后，后面只需要關心資料的維護，不需要再關心UI的重繪了，這極大的減輕了程式員的在UI上的作業，

事實上，以我個人撰寫移動端與前端的經歷來看，前端的UI撰寫的確更快，更有效率

難以出錯

顯而易見的是吧，UI重繪是由框架或技術背后實作的，你只需要重繪資料就可以了，框架或技術的可靠性保證了不太可能出現資料重繪了，UI卻沒重繪或重繪出錯的情況，

極高的性能

由于對資料的映射與重繪是框架在背后處理的，通過大部分框架都不會資料一變就全量重繪，這就太low了，

比如，React就有一個diff演算法，這個演算法保證了只進行必要的重繪，這是非常高效的做法，

UI與資料的一致性

你只需要關心資料，變更資料，并不需要擔心資料與UI出現不一致的情況，

在框架質量有所保證的前提下，這種可能幾乎為小的可以忽略不計，(框架也可能有BUG，不能期望它為0)

趨勢，大前端UI的未來

當然，『后』前端階段，無論是React或Vue，都已經是這種宣告式UI的做法了，它已經是前端的事實與主流了，

而在移動端，Android現在本身主推的是Jetpack，而iOS主推的是SwiftUI，這些也都是宣告式UI了，但在移動端，它們仍然只是趨勢，移動端現在絕大部分主流可能仍然是過往的命令式UI，

但可想而知，就算移動端，未來也必然會轉向宣告式UI，

至于移動端非原生的技術，類似Flutter,React Native等就不用說了，這些已經是宣告式UI的實作了，

至于桌面端，由于我只有基于Electron開發桌面軟體的經驗，這是個前端技術，當然也是宣告式UI，至于原生Window或Linux桌面開發，我并未有相關經驗，但我相信借鑒宣告式UI也絕對是正確的趨勢，

所以，做為一個大前端的程式員，無論你是前端或是移動端，還是桌面端，你都要做好迎接宣告式UI的未來的準備，

前端之困

前端發生了巨大的變革，如我所言，這種變化是革命性的，顛覆性的，

但從我在前端的經驗來看，無論是前端語言的生態，還是質量，與后端仍存在一些差距，這就非常值得我的思考，如果理念與技術并沒有問題，那問題究竟在哪？

下一篇，前端之變（七）：前端之困，繼續就前端闡述我的思考與分析，