一開始在 React 路上摸爬滾打的時候，不知道該尋找些什麼，但是這些年來，回頭總結經驗才發現，要找的已經在腦子裡了。下面是我自己在學習 React 歷程的一些關鍵點，以及我的一些背景情況。
- 我已經寫了 18 年的程式碼，其中 13 年是全職專業的老司機了；
- 其中 6 年時間都專注於 Flash 開發；
- 直到史蒂夫·賈伯斯的公開信表示不支援 Flash；
- 我刷過 HTML，CSS 和 JS 這幾個技能點；
- 曾經在主流 JavaScript 框架的研究上糾結了很久，當時感覺它們把大量的邏輯都隱藏在了背後；
- 辭職開始外包生活，主要做原型；
- 看了很多 React Demo；
- 2015 年 10 月，正式開始 React 專案生涯並且愛上了它；
- 2016 年 1 月，改了我在 LinkedIn 上的 Title：React 開發者。
接下來是我所總結的一些經驗，希望能對你有所幫助。
1. 多個簡單元件比一個高度定製化元件要好
改變 React 元件行為依賴於你傳遞的 props，這是個很有用的功能。在專案初期就養成一個好的程式設計習慣對未來很有好處：建立一些通用元件，使其在其他地方也可以使用。
當你開始了專案以後，對於一個元件你可能會不斷地擴充套件這個元件的使用外延。一段時間以後你會發現，你會疲於修復 bug，在 A 場景下修復好以後，又發現在場景 B 和場景 C 下又發現了 bug。
我的建議：如果一個組合元件導致了 bug，那麼把它分解成若干個簡單元件，即便程式碼重複也值得。
2. 如果你發現了庫中有 bug，儘量提 Issue 和 Pull Request
只要你使用 React，就一定會用到開源軟體，不論是 React 核還是 1000 多個可用的 NPM 模組。如果你發現了庫中有 bug，那就提 Issue 上去。更好的情況是，如果你 fix 了一個 bug，一定要提 Pull Request 把修復的程式碼整合進去，因為使用這個庫並且遇到 bug 的並不只是你一個人，這樣做會使整個生態變得更好。
我的建議：回饋社群，即便你只是修正了文件中的拼寫錯誤也好。
3. 首先完成一次 build 過程，然後再寫 React 程式碼
我知道這並不是一個常見的場景，但是我就遇到過，當我開始一個外包專案並且開始 build 的時候，發現有一些依賴編譯的包不存在。進而才發現實際上這個 React 是用於一個 Backbone 專案中的。在 Backbone 中實現 React 元件其實非常簡單，使用 Redux 可以在這兩個之間進行通訊。它們之間的通訊必須要通過 Browserify 或者 Webpack 編譯到一起才可以。
我的建議：如果在一個現有的專案中應用 React，首先用 Browserify 或者 Webpack 走一遍 build 過程比較好。
4. 對於簡單的資料視覺化，原生 SVG >= D3
D3 在資料視覺化方面做的非常棒，但是如果你只是要做一些簡單的資料視覺化，那麼渲染原生 SVG 就可以滿足你的工作需求了。
我的建議：學習一些 SVG 基礎，在你需要更復雜功能之前這就夠了。Youtube 的 前端中心頻道 前幾天剛好播放了 關於 SVG 的節目 ，值得一看。
5. 如果你只有兩週的專案期限，保持功能精簡
如果你要做的工作只是渲染，那麼 React 和 React-DOM 就足夠了。
Redux 的處理很耗費時間和精力，它對於處理大專案中的多層 UI 很有用。但是如果你的專案很簡單的話，那麼通過傳遞 props 和 callback 就好了，不必要使用 Redux。
我的建議：模板專案是非常有用的，但是如果你想保持專案精簡的話，從 React 和 React-DOM 開始是一個很好的選擇。
6. 單獨依賴於 CSS 動畫來移動元素會很慢
我沒有辦法精確地告訴你什麼時候會看到幀速率顯著下降，也許是 30 個元素的時候，也許是 300 個元素的時候。但是可以告訴以一些對你有幫助的經驗。充分利用 React 的虛擬 DOM，並且保證只在需要的時候進行渲染和重渲染。
就是說只渲染那些在檢視視窗中可見的元件。
我的建議：在低配機器上進行測試，同時還要測試邊界資料來看一下你的程式在受限的情況下表現如何。
7. 研究模板是一種很好的開始方法，但是…
如果你正在學習新庫或者新框架，從模板專案開始是比較好的方法。如果你們公司有自己的模板就更好了。
但是不要認為模板專案可以解決所有問題。實際工作中你會發現，它所實現的根本就不是你想要的那樣。如果你沒有自己從頭開始構建一個專案，那後面可能會出現很多問題。另外，如果你對一個模板專案的各種特徵不是很瞭解的話，你很可能會重構一個它已經存在的功能。
我的建議：把模板專案用在它們最擅長的地方——快速啟動專案。不要害怕重構它們，你要讓它們按照你的意志去運作，另外，最好提前瞭解你所使用的模板專案的特性。
8. 保持元件、connected 元件和容器的可控
用 Redux 來 build 的時候，最好要限制元件的個數，同時要儘量保證 actions/reducers 的可複用性。
元件應該只依賴於自己的 props。
Connected 元件應該通過 Redux 來訪問應用資料，並且應該只渲染自己的 DOM 和子元件。
容器充當一個演奏師的角色，取資料並且渲染元件。
我的建議：注意保持命名和功能的一致性。
9. 嚴格的程式碼檢查是一把雙刃劍
我開發過各種各樣的專案，經歷過各種形式的程式碼檢查。從一點程式碼檢查都沒有的專案，到甚至連一個懸空逗號都會拒絕提交的專案。
我想我們大多數人都會同意程式碼質量不僅僅是你用對了空格符和製表符。當開啟一個檔案時候，程式碼給你那種賞心悅目的感覺會讓你寫程式碼而舒服，而且你的注意力可以專注於你的程式碼邏輯。
程式碼檢查也可以幫助你發現一些錯誤，比如常量分配和書寫錯誤，甚至經典的“Undefined is not a function”錯誤。
我的建議：擁抱你的團隊所要求的程式碼審查規則吧。我在 JS 中使用 ESLint，在 Sass 專案 Atom 中使用 scss-lint。你也可以設定規則來方便轉換，如果你要求很嚴格，不想讓不好的程式碼提交上去的話， pre-push 會執行一個 npm 指令碼來做 push 前的檢查。
10. 在 Express 專案中進行 React 渲染是可行的
有很多博文介紹如何安裝普通應用，但是大多數都假設你是想要一個單頁面應用，很少文章介紹如何在一個多頁面 Express 應用中渲染單 React 元件。
我的建議：這種情況下，ReactDOMServer 會成為你的朋友。你可以把元件都當成是頁面片段，把它們傳遞給一個模板來渲染。
11. Saga 使我的大腦一團漿糊
Saga 是 Redux 中介軟體，基於 ES6 的生成器新特性。“生成器定義了可以保持自己 state 的迭代演算法”。在實踐中它和正常的 JavaScript 工作流是不一樣的，因為在另一個基於 Promise 程式碼執行的時候，這個函式可以在執行過程中暫停。
我應該不是第一個，也不是最後一個說這話的人，Saga 讓我的大腦一團漿糊。剛學習 Saga 的時候一團亂麻，不過最終我還是征服了它。不過回頭想想，如果我一開始就理解了生成器的話，可能事情發展會變的好一些。
我的建議：如果你是第一次使用 Saga，並且團隊中沒人有相關的經驗的話，你最好還是先理解 Promise 和 Generator，會對你很有幫助。
上面這些是學習 React 以來我自己總結的一些經驗。去年對我來講是很不一樣的一年，接觸到了不同型別的專案，同時也學到了很多。很期待接下來的時間繼續探索些新的事物。比如 React Native。很高興你能看完本文，希望能對你有所幫助。
如果你認為文章中還需要注意什麼，或者新增什麼， 請讓我知道 。
我最近正在寫一本《React.js 小書》，對 React.js 感興趣的童鞋，歡迎指點。