ReactJS 傻瓜教程

五柳-先生發表於2015-06-24
ReactJS

在相當長的一段時間內，我很努力地去嘗試理解 React 是什麼以及它在應用架構上的健壯程度。這篇文章解答了我希望別人為我解答的疑惑。

React 是什麼？

和 Angular，Ember，Backbone 等等比起來 React 的表現如何？要如何處理資料？要如何連線伺服器？JSX 到底是什麼？“元件”又是如何定義的？

停。

立刻停下來。

React 僅僅是 VIEW 層。

React 通常和其他的 JavaScript 框架同時被提及，但是說“React 對比 Angular”卻講不通，因為它們之間是不可比較的。Angular 是一個完整的框架（包括一個 view 層），React 卻並不是。這也是 React 很難於理解的原因，它雖然抽離自一個具備完整框架的生態系統中，但僅僅是一個 view 層。

React 提供了模板語法以及一些函式鉤子用於基本的 HTML 渲染。這就是 React 全部的輸出——HTML。你把 HTML / JavaScript 合到一起，被稱為“元件”，允許把它們自己內部的狀態存到記憶體中（比如在一個選項卡中哪個被選中），不過最後你只是吐出 HTML。

很明顯，你沒辦法單單使用 React 來建立一個功能完善的動態應用。下面我們詳細看看。

好處

使用 React 一段時間後，我發現了三個非常重要的特性。

1. 通過檢視一個原始檔就可以知道你的元件將會如何渲染。

這是最大的好處，儘管這和 Angular 模板沒什麼不同。下面看一個真實的應用例項。

假設你需要在使用者登入後更新站點頭部的使用者名稱。如果沒有使用 JavaScript MVC 框架，可能要這麼做：

<header>  
   <div class="name"></div>
</header> 

$.post('/login', credentials, function( user ) {
    // Modify the DOM here
    $('header .name').show().text( user.name );
});

按照我的經驗，這些程式碼要毀掉你的生活甚至你同事的生活。如何對輸出除錯？誰來更新頭部？誰還可以訪問頭部的 HTML？誰來維護名字的顯示隱藏狀態？這個 DOM 操作會讓你的專案像 GOTO 語句那樣糟糕。

在 React 中你可以像下面這樣做：

render: function() {  
    return <header>
        { this.state.name ? <div>this.state.name</div> : null }
    </header>;
}

我們會清楚的分辨出這個元件可能會如何渲染。如果你知道這個語句，就會知道渲染後的輸出。你沒必要去記錄程式的流程。在複雜應用中，特別是團隊開發中，顯得尤為重要。

2. 將 JavaScript 和 HTML 繫結到 JSX 使元件更易懂

上面的那種把 HTML 和 JavaScript 混合在一起的寫法可能讓你很不適應。我們會很自然地拒絕將 JavaScript 放在 DOM 當中（比如 onClick 事件處理函式）即便我們是小小的開發者。但是，請一定要相信我；JSX 元件真的會讓你的工作變得很“nice”。

按照傳統，你會把檢視（HTML）從功能（JavaScript）中分離開出來。這會產生一個巨大的 JavaScript 檔案，包含了一個“頁面”的所有功能需求，並且你必須記錄複雜的流程，從 JS 到 HTML 到 JS 到悲痛欲絕。

捆綁功能直接標記和打包成一個可移植的，自主控制的“元件”，讓你更開心，且減少髒亂的程式碼。因為 JavaScript 與 HTML 關係密切，揉到一起也正常。

3. 你可以在服務端渲染 React

如果你正在建立一個入口網站或者應用，並且按照 render-it-all-on-the-client 路線，可能已經出錯了。只通過客戶端渲染使得 Soundcloud 感覺如此慢，相反 Stack Overflow（純服務端渲染）如此快。你可以在服務端渲染 React，並且你該這麼做。

Angular 等促使你做一些噁心的事情，比如使用 PhantomJS 來渲染頁面，分析請求頭中的 user agent ，把這些頁面提供給搜尋引擎，或者為此買一個服務。呃。

壞處

不要忘了 React 僅僅是個 view 層。

1. 下面這些都沒有：

  • 事件系統（除了原生的 DOM 事件）
  • AJAX 功能
  • 資料層
  • Promises
  • 應用程式架構
  • 實現以上功能的規範

單獨的 React 在這個世界上真的沒什麼用。更糟糕的是，就像我們將要看到的，這迫使每個開發者都要重新造輪子。

2. 官方文件既不是“容易理解的”，也不是“良好的”。重申一遍，這是為笨蛋寫的一篇部落格。請看文件頁側邊欄中第一部分：

有三個獨立的、相互矛盾的快速入門指南。我有些不知所措，並且我沒有喝多。更下面的側邊欄就像是惡夢一樣，很明顯一些章節不應該放在那裡，像“More About Refs”和“PureRenderMixin”。

3. 相比 React 給你提供的好處，React 實在太大。而且對瀏覽器的支援也很有限

更新：我之前寫到 React 大小不到 144KB。通過 gzip 壓縮傳輸後在 35KB 左右。

這沒有包含任何 React 的外掛，而你需要使用那些外掛才能實現一個真正的應用！

也不包含 ES5 shim 的類庫，你需要支援 IE8 的話。

不包含任何型別的應用類庫！

React 的大小和 Angular 相當，但 Angular 是一個完整的應用框架。React 顯而易見的臃腫，但是你只獲得了很少的功能。希望這在將來能得到改善。

不要說 Flux

也許 React 開發中，最讓人反感的還是“Flux”。 遠比 React 自身混亂。“Flux”這個名字就很讓人費解。

Flux 並不是真實存在的。它只是一個概念，而不是個類庫。幸運的是，存在一個類庫，在某種程度上：

“相比於一個框架，Flux 更像是一種模式。”

呃。一個最不恰當的名字：React 並沒有重塑最近 40 年的 UI 體系的知識，也沒有為資料管理帶來新的概念。

Flux 的概念很簡單，view 層觸發了一個事件（比如說，使用者在文字域中輸入了一個姓名），這個事件更新了 model，然後 model 觸發了一個事件，view 響應了 model 的事件，使用最新的資料進行渲染。就這樣。

這一資料流/解耦觀察者模式被設計來保證你的資源總存在於記憶體/模式中。這是一件好事™。

Flux 的壞處是每個人都會重新發明輪子。由於沒有在事件庫，model 層，AJAX 層等達成一致，出現了很多種“Flux”的實現方式，並且它們彼此之間相互混雜。

我該用 React 嗎？

簡單回答：是。

詳盡的回答：很不幸，是的，在大多數場景中。

下面是為什麼要用 React：

  • 對團隊開發來說表現的很出色
  • 加強了 UI 和 工作流模式 UI 程式碼的可讀和可維護性。
  • 元件化的 UI 是 web 開發的趨勢，並且你現在應該開始了。

下面是為什麼在你選擇之前需要再考慮一下：

  • 一開始 React 會極大地減慢你的開發。理解props、state以及元件通訊如何工作並不是很簡單，並且文件資訊錯綜複雜。理論上，這將會被克服，你的整個團隊都上道之後，開發速度上就會有一個很大的提升。
  • React 不支援 IE8 以下的任何瀏覽器，以後也絕不會。
  • 如果你的應用/站點不需要頻繁的動態頁面更新，你可能為了很小的功能而編寫大量的程式碼。
  • 你會改造很多輪子。React 很年輕，並且因為沒有權威的方式來處理事件、元件通訊，你必須從零開始建立大量的元件庫。你的應用是否有下拉選單，可調整大小的視窗，或者 lightbox？你同樣必須從零開始寫這些。

轉載： http://zhuanlan.zhihu.com/FrontendMagazine/19896745

相關文章