溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
原文作者：Jolyon Russ
本文編譯：胡子大哈翻譯原文：http://huziketang.com/blog/posts/detail?postId=58e83f01a58c240ae35bb8e1
英文連接：11 lessons learned as a React contractor
轉載請注明出處，保留原文鏈接以及作者信息
一開始在 React 路上摸爬滾打的時候，不知道該尋找些什么，但是這些年來，回頭總結經驗才發現，要找的已經在腦子里了。下面是我自己在學習 React 歷程的一些關鍵點，以及我的一些背景情況。
接下來是我所總結的一些經驗，希望能對你有所幫助。
改變 React 組件行為依賴于你傳遞的 props，這是個很有用的功能。在項目初期就養成一個好的編程習慣對未來很有好處：創建一些通用組件，使其在其他地方也可以使用。
當你開始了項目以后，對于一個組件你可能會不斷地擴展這個組件的使用外延。一段時間以后你會發現，你會疲于修復 bug，在 A 場景下修復好以后，又發現在場景 B 和場景 C 下又發現了 bug。
我的建議：如果一個組合組件導致了 bug，那么把它分解成若干個簡單組件，即便代碼重復也值得。
只要你使用 React，就一定會用到開源軟件，不論是 React 核還是 1000 多個可用的 NPM 模塊。如果你發現了庫中有 bug，那就提 Issue 上去。更好的情況是，如果你 fix 了一個 bug，一定要提 Pull Request 把修復的代碼整合進去，因為使用這個庫并且遇到 bug 的并不只是你一個人，這樣做會使整個生態變得更好。
我的建議：回饋社區，即便你只是修正了文檔中的拼寫錯誤也好。
我知道這并不是一個常見的場景，但是我就遇到過，當我開始一個外包項目并且開始 build 的時候，發現有一些依賴編譯的包不存在。進而才發現實際上這個 React 是用于一個 Backbone 項目中的。在 Backbone 中實現 React 組件其實非常簡單，使用 Redux 可以在這兩個之間進行通信。它們之間的通信必須要通過 Browserify 或者 Webpack 編譯到一起才可以。
我的建議：如果在一個現有的項目中應用 React，首先用 Browserify 或者 Webpack 走一遍 build 過程比較好。
D3 在數據可視化方面做的非常棒，但是如果你只是要做一些簡單的數據可視化，那么渲染原生 SVG 就可以滿足你的工作需求了。
我的建議：學習一些 SVG 基礎，在你需要更復雜功能之前這就夠了。Youtube 的前端中心頻道前幾天剛好播放了關于 SVG 的節目，值得一看。
如果你要做的工作只是渲染，那么 React 和 React-DOM 就足夠了。
Redux 的處理很耗費時間和精力，它對于處理大項目中的多層 UI 很有用。但是如果你的項目很簡單的話，那么通過傳遞 props 和 callback 就好了，不必要使用 Redux。
我的建議：模板項目是非常有用的，但是如果你想保持項目精簡的話，從 React 和 React-DOM 開始是一個很好的選擇。
我沒有辦法精確地告訴你什么時候會看到幀速率顯著下降，也許是 30 個元素的時候，也許是 300 個元素的時候。但是可以告訴以一些對你有幫助的經驗。充分利用 React 的虛擬 DOM，并且保證只在需要的時候進行渲染和重渲染。
就是說只渲染那些在視圖窗口中可見的組件。
我的建議：在低配機器上進行測試，同時還要測試邊界數據來看一下你的程序在受限的情況下表現如何。
如果你正在學習新庫或者新框架，從模板項目開始是比較好的方法。如果你們公司有自己的模板就更好了。
但是不要認為模板項目可以解決所有問題。實際工作中你會發現，它所實現的根本就不是你想要的那樣。如果你沒有自己從頭開始構建一個項目，那后面可能會出現很多問題。另外，如果你對一個模板項目的各種特征不是很了解的話，你很可能會重構一個它已經存在的功能。
我的建議：把模板項目用在它們最擅長的地方——快速啟動項目。不要害怕重構它們，你要讓它們按照你的意志去運作，另外，最好提前了解你所使用的模板項目的特性。
用 Redux 來 build 的時候，最好要限制組件的個數，同時要盡量保證 actions/reducers 的可復用性。
組件應該只依賴于自己的 props。
Connected 組件應該通過 Redux 來訪問應用數據，并且應該只渲染自己的 DOM 和子組件。
容器充當一個演奏師的角色，取數據并且渲染組件。
我的建議：注意保持命名和功能的一致性。
我開發過各種各樣的項目，經歷過各種形式的代碼檢查。從一點代碼檢查都沒有的項目，到甚至連一個懸空逗號都會拒絕提交的項目。
我想我們大多數人都會同意代碼質量不僅僅是你用對了空格符和制表符。當打開一個文件時候，代碼給你那種賞心悅目的感覺會讓你寫代碼而舒服，而且你的注意力可以專注于你的代碼邏輯。
代碼檢查也可以幫助你發現一些錯誤，比如常量分配和書寫錯誤，甚至經典的“Undefined is not a function”錯誤。
我的建議：擁抱你的團隊所要求的代碼審查規則吧。我在 JS 中使用 ESLint，在 Sass 項目 Atom 中使用 scss-lint。你也可以設置規則來方便轉換，如果你要求很嚴格，不想讓不好的代碼提交上去的話，pre-push 會執行一個 npm 腳本來做 push 前的檢查。
有很多博文介紹如何安裝普通應用，但是大多數都假設你是想要一個單頁面應用，很少文章介紹如何在一個多頁面 Express 應用中渲染單 React 組件。
我的建議：這種情況下，ReactDOMServer 會成為你的朋友。你可以把組件都當成是頁面片段，把它們傳遞給一個模板來渲染。
Saga 是 Redux 中間件，基于 ES6 的生成器新特性。“生成器定義了可以保持自己 state 的迭代算法”。在實踐中它和正常的 JavaScript 工作流是不一樣的，因為在另一個基于 Promise 代碼執行的時候，這個函數可以在執行過程中暫停。
我應該不是第一個，也不是最后一個說這話的人，Saga 讓我的大腦一團漿糊。剛學習 Saga 的時候一團亂麻，不過最終我還是征服了它。不過回頭想想，如果我一開始就理解了生成器的話，可能事情發展會變的好一些。
我的建議：如果你是第一次使用 Saga，并且團隊中沒人有相關的經驗的話，你最好還是先理解 Promise 和 Generator，會對你很有幫助。
上面這些是學習 React 以來我自己總結的一些經驗。去年對我來講是很不一樣的一年，接觸到了不同類型的項目，同時也學到了很多。很期待接下來的時間繼續探索些新的事物。比如 React Native。很高興你能看完本文，希望能對你有所幫助。
如果你認為文章中還需要注意什么，或者添加什么，請讓我知道。
我最近正在寫一本《React.js 小書》，對 React.js 感興趣的童鞋
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
