摘要：基于全家桶寫作新聞一體綜合應(yīng)用的實踐總結(jié)在線地址大家伙兒們，又見面了。參照但不可否認(rèn)非常符合的思想，都在處理大規(guī)模數(shù)據(jù)時彰顯優(yōu)勢。最好的辦法是使用部署環(huán)境。細(xì)致的拆分，解耦性更好，以為單位進行修改時，大大降低誤傷率的同時，隔離無關(guān)的信息。

在線地址

GITHUB

大家伙兒們，又見面了?。 自上次Byemess Todo之后，覺得自身不足還是挺多的，期間又萌生了一些將它重構(gòu)加上更多新特性的想法，之后技術(shù)磨煉一陣再來好好改造它。對于Learn by doing這種事情，一次就會上癮啊有木有??，于是乎本著繼續(xù)精進練習(xí)React技術(shù)棧，以及實踐更多相關(guān)技術(shù)的初衷，besides that，自己還想再準(zhǔn)備一個小項目來為找工作打底氣，于是乎就有了CoderPad。

在最開始的時候，是想做一個催稿app，又是一個集成的idea:提供分類書單，可以記錄閱讀情況，然后根據(jù)這個情況設(shè)定或者后臺計算智能推薦：何時去寫一篇相關(guān)的博客(技術(shù)博客)，當(dāng)然寫作也是在這個app里完成，然后自動部署至github page。 名字我都想好了，就叫催乎...（知乎er們懂的)，奈何這是個大工程啊... 我就造出了這么個只有編輯，閱讀的閹割版。 另外關(guān)于寫完markdown直接部署生成靜態(tài)博客的app我推薦好基友的Page.qy => ? 無代碼建站，基于Node.js，React和Electron，很用心的app，向他學(xué)習(xí)之，他馬上又會寫出一個UI逆天美的音樂播放器了，你們可以關(guān)注他。

Markdown： 支持本地緩存，保存/刪除/查看/下載，追求極簡。

NewsFeed： 集成v2ex，HackerNews-Top Stories， Github-Trending

Music: 暫未施工

老朋友React全家桶： 對于這塊，值得一提的是react router v4，相對于v3的巨大改動，extremely make sense. 讓route與組件化思想更貼切，有種幻覺：定義子route更加隨心所欲了。至于為什么... 請君上手感受。

Immutable: 有一些細(xì)微的坑，主要體現(xiàn)在數(shù)據(jù)類型轉(zhuǎn)化上，immutable會將原生JS數(shù)據(jù)類型進行包裝，如Map，List，在對它們進行提取的時候需要注意是否已經(jīng)轉(zhuǎn)化為原生JS，否則容易出錯。 我的建議就是時刻注意提取的數(shù)據(jù)是什么類型，結(jié)合PropTypes進行參數(shù)檢測，出錯時先console看看，一般很快可以解決。 對于多層對象嵌套的時候，為了保險，手動將被嵌套的對象進行指定類型轉(zhuǎn)化，比如{ list: [] } => { list:Immutable.List([]) }，如果要偷懶的話可以直接使用fromJS，但是這個方法滲透性強，會將所有內(nèi)嵌結(jié)構(gòu)進行轉(zhuǎn)化，在本項目的后期重構(gòu)里就遇到了子數(shù)組遍歷出來全是immutable object的情況，需要手動再次轉(zhuǎn)化，很是惡心。 這些缺點在redux文檔里也有表述，在具體實踐后才能有更直觀的理解。 參照: What are the issues with using Immutable.JS?.但不可否認(rèn)Immutable.js非常符合react的思想，都在處理大規(guī)模數(shù)據(jù)時彰顯優(yōu)勢。

Reselect：它用來替代我們手寫的state selector， 它的主要思想： state1 + state2 => state3， 緩存先決state，它們?nèi)绻嬎憬Y(jié)果是相同的，就使用緩存結(jié)果不去改變最終state，同樣也是immutable思想。 在結(jié)合immutable.js的時候，也是坑啊，還是那個老問題，數(shù)據(jù)類型，state嵌套越深，越麻煩。 所以，現(xiàn)在明白為什么強調(diào)Redux State扁平化了吧？

Redux Saga: Oh my.. 無比親切，至于原因： 我寫過這么一篇文章:From Iterator To Async. Saga致力于解決復(fù)雜場景下的異步流程控制，用它來管理action觸發(fā)，酸爽無比。 畢竟控制異步流程這種成就在JS話題下本身就是爽的不要不要的。 本質(zhì)是使用generator，對于理解CO庫的同學(xué)們，掌握saga不在話下。在操作極其頻繁的場景下(比如游戲），你會感受到他的威力。 推薦一篇文章： Async operations using redux-saga， 在本項目里我主要用它來控制news數(shù)據(jù)的拉取，采用axios.

Styled Components: 老朋友，更新了2.0版本，同樣配合styled-props，效果拔群。 至于一些宏觀上的樣式設(shè)置，的確不如直接寫CSS那么直觀。 我采用的方法是，特性按組件寫，通性和一些涉及多層級樣式都放在wrapper里。 也許多帶帶使用styled-components并不能發(fā)揮出色，配合傳統(tǒng)CSS寫法，應(yīng)該可以相得益彰。

ref: 對于ref的感覺一直是又愛又恨，畢竟在react之前，dom操作被我們玩的飛起，而react官方的態(tài)度一直是不建議使用。 在這次的項目中，markdown editor處的textarea我便采用了Uncontrolled的形式，使用ref保存dom引用。 初衷是為了對頻繁的內(nèi)容變動進行debounce處理，當(dāng)編輯暫停時才觸發(fā)一次內(nèi)容state更新。 隨著組件的增加，在一個嵌套達到3層的modal組件里，需要對textarea的value進行重置操作，好了，這下我得從父組件一層層的把這個ref傳進去。 那感覺簡直不能再糟.... 一剎那感覺官方文檔就像和藹的老司機，句句肺腑之言啊！ 不過在你真的遇到這個坑前，是不會有多深的感受的。 要解決這個惡心的傳遞，只有采用controlled形式，onChange監(jiān)聽，value直接鏈接state.

Perf: 作為性能測量的利器，測試結(jié)果讓我發(fā)現(xiàn)styled-components的消耗是可觀的，尤其是更新到v2.0版本后。在其他方面，由于本項目里的newsFeed可能會涉及頻繁點擊切換路徑的情況，為了防止無謂的重復(fù)渲染，給所有presentational components都設(shè)置為PureComponent， 接著在一些只需要更新一次的組件里手寫shouldComponentUpdate， 還是強調(diào)一點： 必須十分清楚傳入的參數(shù)，以及其結(jié)構(gòu)，并考慮這個結(jié)構(gòu)是否在生產(chǎn)環(huán)境中有變化的可能導(dǎo)致判斷失效。 還有個值得注意的問題是react-router-v4里的NavLink檢測location渲染當(dāng)前激活地址的link(activeClassName屬性)時，注意組件是否是PureComponent， 如果是，必須在父組件傳入location，否則PureComponent的shouldComponentUpdate將會判定參數(shù)無變化，從而block掉link的動態(tài)渲染。參照: Dealing with Update Blocking

Server Side: 由于是使用leancloud部署，用node環(huán)境，為了解決v2ex api的跨域問題，自己寫了一套請求轉(zhuǎn)發(fā)，但是問題來了： 單頁APP里為保證刷新后不出現(xiàn)cannot get等問題，必須寫上一條app.get("*", (req, res) => {res.sendFile("index.html的路徑")} )， 這就很麻煩了，后來經(jīng)過請教，用正則過濾了請求轉(zhuǎn)發(fā)涉及的路徑，就避免了路徑全局?jǐn)r截。但是！ 這樣刷新后，又會遇到cannot get的問題了。 因為再次刷新時url已經(jīng)變化，瀏覽器會去請求這個地址，而后臺并沒有提供此路徑的響應(yīng)。 最好的辦法是使用nginx部署環(huán)境。(express難道就沒辦法？ 還是我服務(wù)端知識短淺啊...要惡補） 另外一個問題： 生產(chǎn)環(huán)境和部署環(huán)境下由于使用了不同的請求地址，返回的數(shù)據(jù)的結(jié)構(gòu)存在微小差異，以本項目為例，請求v2ex topic在生產(chǎn)環(huán)境下數(shù)據(jù)是res.data，而到了部署環(huán)境下由于使用了自己設(shè)置的請求地址，返回的數(shù)據(jù)成了res.data[0]，找了很久才發(fā)現(xiàn)問題，值得注意。

Cancellation: 在newsfeed里頻繁切換頁面時還有一個問題： 也許下一個頁面呈現(xiàn)時，上一個頁面中觸發(fā)的fetch操作還沒執(zhí)行完畢。舉個例子： 我進入了v2ex的頁面，此時組件拉取新聞信息，接著我?guī)缀醪坏却闱袚Q至github，此時對于v2ex的拉取還在進行。這就是一種浪費了。 為了解決它，起初我嘗試用saga結(jié)合react-router-redux里提供的LOCATION_CHANGE action來作為判定取消之前未完成fetch的標(biāo)志。 測試發(fā)現(xiàn)就算我點擊的是同一個link，依然會觸發(fā)LOCATION_CHANGE，（真坑啊，完全不符合直覺好么！？）那么有這么一個場景： 當(dāng)你進入hackerNews等待數(shù)據(jù)返回，由于時間較久，你不耐煩的再次點擊了hackerNews的Link，Boom~~！ LOCATION_CHANGE dispatched. 于是乎你的fetch被取消了...，所以用LOCATION_CHANGE作為判定標(biāo)志在首次拉取這個場景下是不可行的(論corner case重要性..)， 后來想出來的解決辦法是在三塊新聞組件的componentDidMount的頂部dispatch一個STOP_FETCH action，然后將判定取消的標(biāo)志改為:STOP_FETCH，算是解決了，可總感覺有點暴力，因為一旦組件變多，將要手動。接下來將繼續(xù)思考更優(yōu)雅的解決方案，如果大神們有答案，請告知。

最大的收獲： 主動找上問題，而不是問題找上你。 不折騰，不踩坑，進步頗微。

當(dāng)container變多時，直接將container component作為單位，多帶帶設(shè)立目錄，然后放置對應(yīng)的components/styled-components/reducer/action. 這就是按feature組織目錄的方法。 細(xì)致的拆分，解耦性更好，以container component為單位進行修改時，大大降低誤傷率的同時，隔離無關(guān)的信息。

大概總結(jié)出一個Learn by doing的心路歷程：

被未嘗試的技術(shù)吸引，并且有了下一個project的idea

嘗試拆分所需技能，分成組塊(裂墻推薦知乎金旭亮老師組塊學(xué)習(xí)論)

漫長的學(xué)習(xí)過程： 讀文檔，找樣例，寫小demo倒騰API。由于組塊積累未完全，所以無法對project全面下手，自然會很煩躁，并且踏出了舒適區(qū)，接收更多的信息。

組塊知識積累完畢，project開始施工： 從最簡功能需求開始，不斷增加新feature: problem -> google -> resolve.

Project成型，評估，修正，改進，more problem come in.

項目總結(jié)。然后享受一下獨立完成project的成就感。同時也會深刻理解自己的不足，為自己的技術(shù)精進之路指明了方向。

以project為單位，循環(huán)以上步驟。

最后的領(lǐng)悟： 我早幾年干什么去了... 捶胸淚目ing。

未來可能會補上的：

白噪音組合播放

番茄鐘

音樂部分（哈哈哈偷懶了時間不多了，趕緊找工作。）

作為一名新人，還請大家多多指教。同樣無恥的求star，2333。