React 可視化開發工具 Shadow Widget 非正經入門（之一：React 三宗罪）

本系列博文從 Shadow Widget 做者的視角，解釋該框架的設計要點，既做爲用戶手冊的補充，也從更本質角度幫助你們理解 Shadow Widget 爲何這樣設計，相關概念是怎麼提出的，正確的使用姿式等。

1. 前言

"非正經入門" 是相對 "正經入門" 而言的。

正經入門 Shadow Widget 的路數是：按照 Shadow Widget 技術棧的依賴順序，依次學習各個手冊，好比 React 處於最底層，到它的官方網站找材料學習，React 之上是 shadow-widget 與 shadow-server，到 github.com/rewgt 找到這兩個 repository，克隆到本地，按順序學習各 repo 附帶用戶手冊，而後其上還有 shadow-book、shadow-slide 等 repo，若用到了，就學習相應的用戶手冊。"正經入門" 的學習方式是學院派的，嚴謹、完整、成體系，對於大部分用戶來講是首選。

但終歸有些老司機是不正經的，正襟危坐弄那麼多前戲會很不耐煩，好吧，這幾篇博客就是爲他們準備的，我嘗試直擊人心講要點，不求全面，也不要求從未接觸 Shadow Widget 的童鞋一下就看懂，解釋過程可能掛一漏萬，見諒先。不過沒關係，正式學習仍需回到 "正經入門" 的方式。

要求讀者對 React 開發技術已有深刻了解，不然，嗯，還請回到 "正經入門" 的學習方式吧，這幾篇博客用做技術回顧也是不錯的，能讓你們對 Shadow Widget 體系的本質性原理認識更深刻些。

2. 快速入門建議

1) 先學會用拼文寫文檔

註冊一個 github 帳號，把 rewgt/blogs 庫 fork 到本身名下，而後用這個庫寫本身的博客，參見 這份介紹。

Shadow Widget 界面設計嚴重依賴兩樣東西，一是使用 markdown 語法，二是所見即所得的 UI 可視化設計器。這兩項也是寫文檔隨時用到的，好比撰寫演示膠片時，膠片頁編輯器就是 Shadow Widget 可視化設計器。會用拼文寫文章，至關於 Shadow Widget 開發已入門三分之一了。

2) 系統化學習《Shadow Widget 用戶手冊》

包括理論篇、基礎篇、進階篇、API手冊、可視化設計使用手冊。

多數軟件的用戶手冊還是最佳入門教材，儘管網上常有人編寫《XX系統最佳入門》之類的教材，讓人誤覺得是捷徑，其實，多數狀況下，都沒有閱讀原配用戶手冊學得快。

Shadow Widget 編程體系具備內斂特質，入門時學習工做量較大，入門後，在 Shadow Widget 之上的衆多組件（或庫）都是擴展插件，規格一致，學起來很容易。另外，藉助可視化設計的特色，記憶負擔輕，基本上經過拖入一個樣板來建立構件，選中構件後配置它的屬性，遇到不清楚的 API，再查一下在線幫助，很方便的。

3. React 三宗罪

事先申明，React 是一個優秀框架，我不黑 React。

所提三宗罪基於世俗觀點，人們常將 React、Angular、Vue 三者並列比較，其實 React 只是虛擬 DOM 層面的庫，在 React 之上疊加若干工具，好比使用 immutable 數據、造成 FRP 處理框架、疊加路由機制等，以後，React 才與 Angular、Vue 是對等的。將 DOM 庫拔高與別人比較，顯然對 React 不公。但現狀如此，誰讓 React 確立一種編程模式呢，其實將這三者並列比較的人，內心也很清楚，他比較的是三種生態鏈，而非只是三個工具。

由於 React 確立一種函數式的，單向數據驅動的，JSX 與 JS 代碼混寫的編程模式，既有它的先進性，也必然引入一些讓人垢病的因素，下文 "三宗罪" 所列就是典型的負面因素，也是當前 React 生態圈還沒有有效解決的焦點問題。固然，shadow-widget 出世後，這些不利影響也基本消除了。因此，React 三宗罪是 "React + 其它" 的三宗罪，不是 "React + shadow-widget" 的三宗罪。

3.1 三宗罪之一：長工具鏈

學習 React 要面臨超長工具鏈，這是不利消息，好消息是，這套工具鏈通過數年磨鍊，如今基本穩定下來了（坑仍是很多，前人有總結，你不把它當坑就行 ）。關於超長工具鏈，請參考個人上一篇博客 《Shadow Widget框架概略介紹》，React 工具鏈尚在春秋戰國，過於發散、雜亂、低效，並且，在嚴謹普適的方法論與直觀易用之間，還沒找到最佳平衡方式。

當年 Brendan Eich 創造 javascript，僅爲簡陋的網頁增長一點簡單編程手段，如今的 JS 所處生態環境，遠非早年樣子，即使五年前，網頁編程還都是很簡單，一個 jQuery 解決大半問題。事實上，這種簡易的形態反倒與網頁主流狀態相適配，多數網頁只是展現信息，加點小量編程就夠用。如今問題是，輕量編程與重量編程之間沒有界限，有時剛開始是輕量的，一邊維護一邊追加功能就慢慢變重了，有時本身負責部分是輕量級的，但與他人對接，別人是重量級開發，不得已被同化成重量級應用。

個人意思是，一個好的前端框架，應該同時適應輕量級與重量級開發，二者之間過渡是平滑進行的。在草創階段，無論面對多複雜的系統，都應是輕量級的，疊加功能，應該只是容量遞增，而非架構重建。目前主流的 "React + redux + react-router" 用法，加上沒法省略的 Babel 編譯工具，一入手就是重量級開發。因此，如今許多人面對輕量級網頁開發，寧肯啥框架都不要，用回老舊的 jQuery。

Shadow Widget 創建一個插件式框架，"開發新構件並封裝成樣板" 是一件工做，"使用現成構件組裝 APP" 是另外一件工做，兩件工做截然分開。對於後者，可避開 Babel 翻譯，用 ES5 語法能很好作開發了。此外，Shadow Widget 內置與 reflux/redux 對等的單向數據流機制，與 react-router 等價的也有內置實現，其它的，如 immutable 數據、ajax 調用等都內置支持了。總之，"React + shadow-widget" 是完整的前端框架，與 Angular、Vue 功能對等。

在 Shadow Widget 之上擴展的 PINP Blog，更是將寫文章與編程拉通，實踐 "寫做即編程" 的理念，從輕量開發過渡到重量級開發，是很天然的過程。

3.2 三宗罪之二：JSX漿糊

JSX 看起來像 html，能直接描述界面設計，咱們拿 React 官網上一段代碼來舉例：

function getGreeting(user) {
  if (user) {
    return <h1>Hello, {formatName(user)}!</h1>;
  }
  return <h1>Hello, Stranger.</h1>;
}

上面 formatName() 也是用戶定義的一個函數，函數調用、變量引用都能雜湊在 JSX 中使用。這麼作好處是編程靈活，壞處是破壞了界面與底層的解耦，使用 JSX 得到便利同時，也綁架它的上下文實現，由於這個 JSX 的本質是一段代碼，在特定上下文才有效（相關變量與函數纔可用）。咱們稱之爲 "JSX漿糊"，使用的 JSX 與特定編程片段粘糊在一塊兒了。

"JSX漿糊" 直接的負面影響是，界面設計與其它部分沒有分離，因此，儘管 React 生態圈中的輪子如此豐富，但鮮見以 "所見即所得" 支持可視化設計的解決方案，不得不說 "JSX漿糊" 是禍首。

Shadow Widget 經過一系列手段解決 "界面設計" 與底層分離的問題，不過，它的分離機制在 React 基礎上疊加，React 原機制並未破壞，若是想用 JSX，仍正常可用。此處理方式反映了咱們的 "實效主義" 策略，一方面認同 React 那種函數式、單向數據流的處理機制，另外一方面，也正視函數式編程與可視化開發自然有衝突，面向對象編程與可視化開發更親近些。

不追求純正的函數式開發，不強調純函數組件，什麼東西最有效，能解決問題就選它。本系列文章後面還會解釋，函數式開發的思惟方式既有優點也有劣勢，尤爲將 FRP（Functional Reactive Programming，函數響應式編程）嚴格應用到現實項目，必然遭遇反人性困局。編程的世界裏沒有純粹的東西，由於人性並不純粹，過份追求 "純正" 會讓事情走向反面。

3.3 三宗罪之三：分層解耦

軟件開發中有兩類分層，一是軟件功能的分層，二是人員的分層。當前端開發變複雜後，這兩類分層的需求變得更強烈，尤爲針對簡單網頁的開發，你不能要求全部開發人員都是專家，但 React 生態鏈的現狀是，能用 React 正式開發產品時，你已是準專家了，在有產出以前，你要熟悉一堆工具、一堆規則、一堆語法，要踩很多坑。

網上有人對比 React 與 Vue，說用 Vue 是先爽後痛，用 React 則先痛後爽，還有人補充說，用 React 一直痛，沒有爽。這些說法大體準確，React 體系遵循嚴格的函數式編程風格，從它選這條路的第一天開始，就意味着要 "先痛"，至於後來 "爽不爽" 還得看它的修爲，想像一下用 LISP 開發 GUI 程序是怎樣一種感覺吧？函數式風格與指令式存在本質性差別，推演下來，反映到 React 與 Vue 上必是這種效果。因此，函數式是 React 體系的原罪，shadow-widget 是爲 React 贖罪來的。

用 Vue 爽後還得痛，反映了這個領域作開發原本就這麼複雜，入手門檻雖降，但晉升爲專家的路上，該受的苦，該踩的坑一件不落。不過，Vue 也是優秀的前端框架，它與 React 對比，基本在對比指令式與函數式的優劣，做爲工具自己，兩個都很優秀，可指責的很少。平心而論，若從中長期收益考慮，在 React 系統已引入 MVVM 框架的前提下，選擇 React 更好些，它出彩的地方是在虛擬 DOM 與 FRP 編程思惟。不過，怎麼說呢？vuex 也引入虛擬 DOM、store、action 機制，它們越長越像了。

上述結論要預設一個前提：在 React 引入 MVVM 結構，這很重要，Shadow Widget 已經幹了這事。React 官方宣稱 React 符合 MVC 分層，並未宣稱它是 MVVM，其工具鏈上主流工具延續了這必定位，事實上，受限於 "JSX漿糊" 等因素，想把它改形成 MVVM 仍是要動一番手術的，不像 Vue 與 Angular，與 MVVM 自然走得近。

我扼要歸納一下 Shadow Widget 是如何改造的？

首先肯定目標，讓 React 適合於可視化開發及人員分層，人員分層是將開發人員分兩撥，一撥低要求，實習生就能作，主要使用現成構件樣板組裝 APP，其門檻只比用 jQuery 作開發稍高一點，另外一撥高要求，能開發新構件並封裝成樣板，什麼都得學。

其次，設計轉義標籤、json-x 描述、投影定義等機制，讓界面與底層分離，實現 MVVM 框架，相關細節請看《Shadow Widget 用戶手冊》。最後，引入雙源屬性、可計算屬性等概念，把 React 的函數式編程往指令式方向上拉回一點，或者更準確一點說，在界面設計，即 "V" 層，採用指令式風格，而 "VM" 與 "M" 層仍沿用原先的函數式風格。

4. Shadow Widget 淵源

Shadow Widget 由 PINP.ME 團隊研發，PINP.ME 一直專一於提供以 HTML5 技術撰寫文檔的工具，包括相似 WORD 的博客文檔與相似 PPT 的演示膠片。最先發布的 PINP 版本距今已有四年，早期的 PINP 採用 Ractive 框架，後來全盤重構，改用 React，就是你們如今看到的 PINP Blog 產品。

    (PINP 的 logo)

 

PINP 改版最大變化是，層次劃分更清晰、開發方法更先進，推出的版本也更穩定了。另外，在底層把 shadow-widget、shadow-slide 專門獨立出來，讓 shadow-widget 自成一個體系，不僅 PINP 工具能用，也嘗試讓 "React + shadow-widget" 成爲一個簡單易用的前端框架。

（本文完）

本專欄歷史文章：

1. 《介紹一項讓 React 能夠與 Vue 抗衡的技術》