摘要：前言非正經入門是相對正經入門而言的。不過不要緊，正式學習仍需回到正經入門的方式。快速入門建議先學會用拼文寫文檔注冊一個賬號，把庫到自己名下，然后用這個庫寫自己的博客，參見這份介紹。會用拼文寫文章，相當于開發已入門三分之一了。

本系列博文從 Shadow Widget 作者的視角，解釋該框架的設計要點，既作為用戶手冊的補充，也從更本質角度幫助大家理解 Shadow Widget 為什么這樣設計，相關概念是怎么提出的，正確的使用姿勢等。

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

正經入門 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 體系的本質性原理認識更深入些。

1) 先學會用拼文寫文檔

注冊一個 github 賬號，把 rewgt/blogs 庫 fork 到自己名下，然后用這個庫寫自己的博客，參見 這份介紹。
Shadow Widget 界面設計嚴重依賴兩樣東西，一是使用 markdown 語法，二是所見即所得的 UI 可視化設計器。這兩項也是寫文檔隨時用到的，比如撰寫演示膠片時，膠片頁編輯器就是 Shadow Widget 可視化設計器。會用拼文寫文章，相當于 Shadow Widget 開發已入門三分之一了。

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

包括理論篇、基礎篇、進階篇、API手冊、可視化設計使用手冊。
多數軟件的用戶手冊仍是最佳入門教材，盡管網上常有人編寫《XX系統最佳入門》之類的教材，讓人誤以為是捷徑，其實，多數情況下，都沒有閱讀原配用戶手冊學得快。

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

事先申明，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" 的三宗罪。

學習 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，更是將寫文章與編程拉通，實踐 "寫作即編程" 的理念，從輕量開發過渡到重量級開發，是很自然的過程。

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

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

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

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

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

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

軟件開發中有兩類分層，一是軟件功能的分層，二是人員的分層。當前端開發變復雜后，這兩類分層的需求變得更強烈，尤其針對簡單網頁的開發，你不能要求所有開發人員都是專家，但 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" 層仍沿用原先的函數式風格。

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" 成為一個簡單易用的前端框架。

（本文完）

本專欄歷史文章：

《介紹一項讓 React 可以與 Vue 抗衡的技術》