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