摘要：前言非正經(jīng)入門是相對(duì)正經(jīng)入門而言的。不過(guò)不要緊，正式學(xué)習(xí)仍需回到正經(jīng)入門的方式?？焖偃腴T建議先學(xué)會(huì)用拼文寫文檔注冊(cè)一個(gè)賬號(hào)，把庫(kù)到自己名下，然后用這個(gè)庫(kù)寫自己的博客，參見(jiàn)這份介紹。會(huì)用拼文寫文章，相當(dāng)于開(kāi)發(fā)已入門三分之一了。

本系列博文從 Shadow Widget 作者的視角，解釋該框架的設(shè)計(jì)要點(diǎn)，既作為用戶手冊(cè)的補(bǔ)充，也從更本質(zhì)角度幫助大家理解 Shadow Widget 為什么這樣設(shè)計(jì)，相關(guān)概念是怎么提出的，正確的使用姿勢(shì)等。

"非正經(jīng)入門" 是相對(duì) "正經(jīng)入門" 而言的。

正經(jīng)入門 Shadow Widget 的路數(shù)是：按照 Shadow Widget 技術(shù)棧的依賴順序，依次學(xué)習(xí)各個(gè)手冊(cè)，比如 React 處于最底層，到它的官方網(wǎng)站找材料學(xué)習(xí)，React 之上是 shadow-widget 與 shadow-server，到 github.com/rewgt 找到這兩個(gè) repository，克隆到本地，按順序?qū)W習(xí)各 repo 附帶用戶手冊(cè)，然后其上還有 shadow-book、shadow-slide 等 repo，若用到了，就學(xué)習(xí)相應(yīng)的用戶手冊(cè)。"正經(jīng)入門" 的學(xué)習(xí)方式是學(xué)院派的，嚴(yán)謹(jǐn)、完整、成體系，對(duì)于大部分用戶來(lái)說(shuō)是首選。

但終歸有些老司機(jī)是不正經(jīng)的，正襟危坐弄那么多前戲會(huì)很不耐煩，好吧，這幾篇博客就是為他們準(zhǔn)備的，我嘗試直擊人心講要點(diǎn)，不求全面，也不要求從未接觸 Shadow Widget 的童鞋一下就看懂，解釋過(guò)程可能掛一漏萬(wàn)，見(jiàn)諒先。不過(guò)不要緊，正式學(xué)習(xí)仍需回到 "正經(jīng)入門" 的方式。

要求讀者對(duì) React 開(kāi)發(fā)技術(shù)已有深入了解，否則，嗯，還請(qǐng)回到 "正經(jīng)入門" 的學(xué)習(xí)方式吧，這幾篇博客用作技術(shù)回顧也是不錯(cuò)的，能讓大家對(duì) Shadow Widget 體系的本質(zhì)性原理認(rèn)識(shí)更深入些。

1) 先學(xué)會(huì)用拼文寫文檔

注冊(cè)一個(gè) github 賬號(hào)，把 rewgt/blogs 庫(kù) fork 到自己名下，然后用這個(gè)庫(kù)寫自己的博客，參見(jiàn) 這份介紹。
Shadow Widget 界面設(shè)計(jì)嚴(yán)重依賴兩樣?xùn)|西，一是使用 markdown 語(yǔ)法，二是所見(jiàn)即所得的 UI 可視化設(shè)計(jì)器。這兩項(xiàng)也是寫文檔隨時(shí)用到的，比如撰寫演示膠片時(shí)，膠片頁(yè)編輯器就是 Shadow Widget 可視化設(shè)計(jì)器。會(huì)用拼文寫文章，相當(dāng)于 Shadow Widget 開(kāi)發(fā)已入門三分之一了。

2) 系統(tǒng)化學(xué)習(xí)《Shadow Widget 用戶手冊(cè)》

包括理論篇、基礎(chǔ)篇、進(jìn)階篇、API手冊(cè)、可視化設(shè)計(jì)使用手冊(cè)。
多數(shù)軟件的用戶手冊(cè)仍是最佳入門教材，盡管網(wǎng)上常有人編寫《XX系統(tǒng)最佳入門》之類的教材，讓人誤以為是捷徑，其實(shí)，多數(shù)情況下，都沒(méi)有閱讀原配用戶手冊(cè)學(xué)得快。

Shadow Widget 編程體系具有內(nèi)斂特質(zhì)，入門時(shí)學(xué)習(xí)工作量較大，入門后，在 Shadow Widget 之上的眾多組件（或庫(kù)）都是擴(kuò)展插件，規(guī)格一致，學(xué)起來(lái)很容易。另外，借助可視化設(shè)計(jì)的特點(diǎn)，記憶負(fù)擔(dān)輕，基本上通過(guò)拖入一個(gè)樣板來(lái)創(chuàng)建構(gòu)件，選中構(gòu)件后配置它的屬性，遇到不清楚的 API，再查一下在線幫助，很方便的。

事先申明，React 是一個(gè)優(yōu)秀框架，我不黑 React。

所提三宗罪基于世俗觀點(diǎn)，人們常將 React、Angular、Vue 三者并列比較，其實(shí) React 只是虛擬 DOM 層面的庫(kù)，在 React 之上疊加若干工具，比如使用 immutable 數(shù)據(jù)、形成 FRP 處理框架、疊加路由機(jī)制等，之后，React 才與 Angular、Vue 是對(duì)等的。將 DOM 庫(kù)拔高與別人比較，顯然對(duì) React 不公。但現(xiàn)狀如此，誰(shuí)讓 React 確立一種編程模式呢，其實(shí)將這三者并列比較的人，心里也很清楚，他比較的是三種生態(tài)鏈，而非只是三個(gè)工具。

因?yàn)?React 確立一種函數(shù)式的，單向數(shù)據(jù)驅(qū)動(dòng)的，JSX 與 JS 代碼混寫的編程模式，既有它的先進(jìn)性，也必然引入一些讓人垢病的因素，下文 "三宗罪" 所列就是典型的負(fù)面因素，也是當(dāng)前 React 生態(tài)圈尚未有效解決的焦點(diǎn)問(wèn)題。當(dāng)然，shadow-widget 出世后，這些不利影響也基本消除了。所以，React 三宗罪是 "React + 其它" 的三宗罪，不是 "React + shadow-widget" 的三宗罪。

學(xué)習(xí) React 要面臨超長(zhǎng)工具鏈，這是不利消息，好消息是，這套工具鏈經(jīng)過(guò)數(shù)年磨煉，現(xiàn)在基本穩(wěn)定下來(lái)了（坑還是不少，前人有總結(jié)，你不把它當(dāng)坑就行 ）。關(guān)于超長(zhǎng)工具鏈，請(qǐng)參考我的上一篇博客 《Shadow Widget框架概略介紹》，React 工具鏈尚在春秋戰(zhàn)國(guó)，過(guò)于發(fā)散、雜亂、低效，而且，在嚴(yán)謹(jǐn)普適的方法論與直觀易用之間，還沒(méi)找到最佳平衡方式。

當(dāng)年 Brendan Eich 創(chuàng)造 javascript，僅為簡(jiǎn)陋的網(wǎng)頁(yè)增加一點(diǎn)簡(jiǎn)單編程手段，現(xiàn)在的 JS 所處生態(tài)環(huán)境，遠(yuǎn)非早年樣子，即便五年前，網(wǎng)頁(yè)編程還都是很簡(jiǎn)單，一個(gè) jQuery 解決大半問(wèn)題。事實(shí)上，這種簡(jiǎn)易的形態(tài)反倒與網(wǎng)頁(yè)主流狀態(tài)相適配，多數(shù)網(wǎng)頁(yè)只是展示信息，加點(diǎn)小量編程就夠用?，F(xiàn)在問(wèn)題是，輕量編程與重量編程之間沒(méi)有界限，有時(shí)剛開(kāi)始是輕量的，一邊維護(hù)一邊追加功能就慢慢變重了，有時(shí)自己負(fù)責(zé)部分是輕量級(jí)的，但與他人對(duì)接，別人是重量級(jí)開(kāi)發(fā)，不得已被同化成重量級(jí)應(yīng)用。

我的意思是，一個(gè)好的前端框架，應(yīng)該同時(shí)適應(yīng)輕量級(jí)與重量級(jí)開(kāi)發(fā)，兩者之間過(guò)渡是平滑進(jìn)行的。在草創(chuàng)階段，不管面對(duì)多復(fù)雜的系統(tǒng)，都應(yīng)是輕量級(jí)的，疊加功能，應(yīng)該只是容量遞增，而非架構(gòu)重建。目前主流的 "React + redux + react-router" 用法，加上無(wú)法省略的 Babel 編譯工具，一入手就是重量級(jí)開(kāi)發(fā)。所以，現(xiàn)在許多人面對(duì)輕量級(jí)網(wǎng)頁(yè)開(kāi)發(fā)，寧可啥框架都不要，用回老舊的 jQuery。

Shadow Widget 建立一個(gè)插件式框架，"開(kāi)發(fā)新構(gòu)件并封裝成樣板" 是一件工作，"使用現(xiàn)成構(gòu)件組裝 APP" 是另一件工作，兩件工作截然分開(kāi)。對(duì)于后者，可避開(kāi) Babel 翻譯，用 ES5 語(yǔ)法能很好做開(kāi)發(fā)了。此外，Shadow Widget 內(nèi)置與 reflux/redux 對(duì)等的單向數(shù)據(jù)流機(jī)制，與 react-router 等價(jià)的也有內(nèi)置實(shí)現(xiàn)，其它的，如 immutable 數(shù)據(jù)、ajax 調(diào)用等都內(nèi)置支持了?？傊?React + shadow-widget" 是完整的前端框架，與 Angular、Vue 功能對(duì)等。

在 Shadow Widget 之上擴(kuò)展的 PINP Blog，更是將寫文章與編程拉通，實(shí)踐 "寫作即編程" 的理念，從輕量開(kāi)發(fā)過(guò)渡到重量級(jí)開(kāi)發(fā)，是很自然的過(guò)程。

JSX 看起來(lái)像 html，能直接描述界面設(shè)計(jì)，我們拿 React 官網(wǎng)上一段代碼來(lái)舉例：

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

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

"JSX漿糊" 直接的負(fù)面影響是，界面設(shè)計(jì)與其它部分沒(méi)有分離，所以，盡管 React 生態(tài)圈中的輪子如此豐富，但鮮見(jiàn)以 "所見(jiàn)即所得" 支持可視化設(shè)計(jì)的解決方案，不得不說(shuō) "JSX漿糊" 是禍?zhǔn)住?/p>

Shadow Widget 通過(guò)一系列手段解決 "界面設(shè)計(jì)" 與底層分離的問(wèn)題，不過(guò)，它的分離機(jī)制在 React 基礎(chǔ)上疊加，React 原機(jī)制并未破壞，如果想用 JSX，仍正?？捎?。此處理方式反映了我們的 "實(shí)效主義" 策略，一方面認(rèn)同 React 那種函數(shù)式、單向數(shù)據(jù)流的處理機(jī)制，另一方面，也正視函數(shù)式編程與可視化開(kāi)發(fā)天然有沖突，面向?qū)ο缶幊膛c可視化開(kāi)發(fā)更親近些。

不追求純正的函數(shù)式開(kāi)發(fā)，不強(qiáng)調(diào)純函數(shù)組件，什么東西最有效，能解決問(wèn)題就選它。本系列文章后面還會(huì)解釋，函數(shù)式開(kāi)發(fā)的思維方式既有優(yōu)勢(shì)也有劣勢(shì)，尤其將 FRP（Functional Reactive Programming，函數(shù)響應(yīng)式編程）嚴(yán)格應(yīng)用到現(xiàn)實(shí)項(xiàng)目，必然遭遇反人性困局。編程的世界里沒(méi)有純粹的東西，因?yàn)槿诵圆⒉患兇?，過(guò)份追求 "純正" 會(huì)讓事情走向反面。

軟件開(kāi)發(fā)中有兩類分層，一是軟件功能的分層，二是人員的分層。當(dāng)前端開(kāi)發(fā)變復(fù)雜后，這兩類分層的需求變得更強(qiáng)烈，尤其針對(duì)簡(jiǎn)單網(wǎng)頁(yè)的開(kāi)發(fā)，你不能要求所有開(kāi)發(fā)人員都是專家，但 React 生態(tài)鏈的現(xiàn)狀是，能用 React 正式開(kāi)發(fā)產(chǎn)品時(shí)，你已經(jīng)是準(zhǔn)專家了，在有產(chǎn)出之前，你要熟悉一堆工具、一堆規(guī)則、一堆語(yǔ)法，要踩不少坑。

網(wǎng)上有人對(duì)比 React 與 Vue，說(shuō)用 Vue 是先爽后痛，用 React 則先痛后爽，還有人補(bǔ)充說(shuō)，用 React 一直痛，沒(méi)有爽。這些說(shuō)法大致準(zhǔn)確，React 體系遵循嚴(yán)格的函數(shù)式編程風(fēng)格，從它選這條路的第一天開(kāi)始，就意味著要 "先痛"，至于后來(lái) "爽不爽" 還得看它的修為，想像一下用 LISP 開(kāi)發(fā) GUI 程序是怎樣一種感受吧？函數(shù)式風(fēng)格與指令式存在本質(zhì)性差異，推演下來(lái)，反映到 React 與 Vue 上必是這種效果。所以，函數(shù)式是 React 體系的原罪，shadow-widget 是為 React 贖罪來(lái)的。

用 Vue 爽后還得痛，反映了這個(gè)領(lǐng)域做開(kāi)發(fā)本來(lái)就這么復(fù)雜，入手門檻雖降，但晉升為專家的路上，該受的苦，該踩的坑一件不落。不過(guò)，Vue 也是優(yōu)秀的前端框架，它與 React 對(duì)比，基本在對(duì)比指令式與函數(shù)式的優(yōu)劣，作為工具本身，兩個(gè)都很優(yōu)秀，可指責(zé)的不多。平心而論，若從中長(zhǎng)期收益考慮，在 React 系統(tǒng)已引入 MVVM 框架的前提下，選擇 React 更好些，它出彩的地方是在虛擬 DOM 與 FRP 編程思維。不過(guò)，怎么說(shuō)呢？vuex 也引入虛擬 DOM、store、action 機(jī)制，它們?cè)介L(zhǎng)越像了。

上述結(jié)論要預(yù)設(shè)一個(gè)前提：在 React 引入 MVVM 結(jié)構(gòu)，這很重要，Shadow Widget 已經(jīng)干了這事。React 官方宣稱 React 符合 MVC 分層，并未宣稱它是 MVVM，其工具鏈上主流工具延續(xù)了這一定位，事實(shí)上，受限于 "JSX漿糊" 等因素，想把它改造成 MVVM 還是要?jiǎng)右环中g(shù)的，不像 Vue 與 Angular，與 MVVM 天然走得近。

我扼要概括一下 Shadow Widget 是如何改造的？

首先確定目標(biāo)，讓 React 適合于可視化開(kāi)發(fā)及人員分層，人員分層是將開(kāi)發(fā)人員分兩撥，一撥低要求，實(shí)習(xí)生就能做，主要使用現(xiàn)成構(gòu)件樣板組裝 APP，其門檻只比用 jQuery 做開(kāi)發(fā)稍高一點(diǎn)，另一撥高要求，能開(kāi)發(fā)新構(gòu)件并封裝成樣板，什么都得學(xué)。

其次，設(shè)計(jì)轉(zhuǎn)義標(biāo)簽、json-x 描述、投影定義等機(jī)制，讓界面與底層分離，實(shí)現(xiàn) MVVM 框架，相關(guān)細(xì)節(jié)請(qǐng)看《Shadow Widget 用戶手冊(cè)》。最后，引入雙源屬性、可計(jì)算屬性等概念，把 React 的函數(shù)式編程往指令式方向上拉回一點(diǎn)，或者更準(zhǔn)確一點(diǎn)說(shuō)，在界面設(shè)計(jì)，即 "V" 層，采用指令式風(fēng)格，而 "VM" 與 "M" 層仍沿用原先的函數(shù)式風(fēng)格。

Shadow Widget 由 PINP.ME 團(tuán)隊(duì)研發(fā)，PINP.ME 一直專注于提供以 HTML5 技術(shù)撰寫文檔的工具，包括類似 WORD 的博客文檔與類似 PPT 的演示膠片。最早發(fā)布的 PINP 版本距今已有四年，早期的 PINP 采用 Ractive 框架，后來(lái)全盤重構(gòu)，改用 React，就是大家現(xiàn)在看到的 PINP Blog 產(chǎn)品。

????(PINP 的 logo)

?

PINP 改版最大變化是，層次劃分更清晰、開(kāi)發(fā)方法更先進(jìn)，推出的版本也更穩(wěn)定了。另外，在底層把 shadow-widget、shadow-slide 專門獨(dú)立出來(lái)，讓 shadow-widget 自成一個(gè)體系，不只 PINP 工具能用，也嘗試讓 "React + shadow-widget" 成為一個(gè)簡(jiǎn)單易用的前端框架。

（本文完）

本專欄歷史文章：

《介紹一項(xiàng)讓 React 可以與 Vue 抗衡的技術(shù)》