前言
學習一門前端框架，不動手是不行的。所以當我學習react有一段時間時，就打算開始寫一個react的個人專案,前後端一起寫的話，比較耗時間，所以就選了提供了優質api的Cnode社群，感謝。（如果我參與的合作專案，產品選的技術棧是react的話，我也不用自己寫個app了,Orz）
希望各位大爺給個star勒,就右上角輕輕一點，比心
傳送門：原始碼地址
最近用mobx重構了一遍，也發了篇文章，傳送門
Demo
過程
分析需求
需求是做一個社群的webapp，首先一個社群的功能，就有 登入註冊（這次沒有註冊）， 自己的資訊， 發帖， 檢視別人的發帖， 檢視別人的主頁，評論他人的帖子等等等。功能太多，我們開發時總不能這部分做點，那部分做點。我們得將這些功能變成一個一個可拆解的模組，比如下圖便是我的分塊，
現在分塊出了個雛形，那麼就有的放矢了。我們開發時，可以先從某一個塊開始動手。比如可以先從登入這一塊開始，每個獨立的模組開發完成後，可以進行連線，其實主要是路由的轉跳。完成後，可以進行除錯，看看整個跑起來感覺如何（我只在我的安卓機除錯了一遍）。
選型
其實做webapp, 我更喜歡用Vue, 但是一開始我的目的就是打算用react的技術棧進行一次實戰。react，redux, react-redux這三樣是跑不掉的，雖然我一開始是想用dva，但是我看了一遍，覺得還是用前者好了，原因不是dva不好，個人專案還是看我個人的學習目的而選擇的。不過從dva中看到的一個redux處理非同步action的中介軟體，redux-saga。雖然redux-thunk加上async await可以基本滿足業務開發的需求。但是我感覺redux-saga更優雅一點。主要是它讓我們發起一個非同步action時，能像發起同步action一樣，其次就是它的監視和執行的機制吸引了我，本著學習的目的，選用redux-saga處理非同步action(當前它很適合用來測試)。UI框架為了迅速開發就選用了antd-mobile。發起http請求就用了axios。腳手架就用了create-react-app。
編碼
這裡主要說下編碼時遇到的問題和解決的方法：
- 首先是路由的懶載入。react-router這個專案用了3.x的。然後，由於是web app而且是一個單頁面應用。當專案變大時，打包後的js太臃腫。使用者第一次進到這個頁面，要下載太大的js導致首屏載入太慢。所以路由的分塊是很必要的。但是，重點來了。react-router官方的文件，動態路由是webpack1的require.ensure，這個不是什麼很大的事，主要那個寫法也不太一樣了。下面舊新對比：
折騰一個小時，總算搜到正確的寫法，並達到了分塊的效果。
- 其次antd-mobile的listview。這個元件用於展示列表。其中有一個屬性是 useBodyScroll, 意思就是以body作為滾動的容器。這個專案有一個需求，就是在詳情頁時，評論就是一個長列表。那麼我自然是想讓它以body作為滾動容器，但是，一直觸發不了到達底部的事件，除了一開始可以觸發一次。百思不得其解，乾脆，就自己監聽body的滾動事件，判斷到達底部，然後呼叫loadMore的事件，載入評論。
注意元件的更新順序。父元件render時，會等子元件渲染完了，才會DidMount，所以如果子元件和父元件都為一個dom繫結了一個事件的話，最後父元件的繫結會覆蓋子元件的。
然後還是路由。舉個例子： /user/1 => /user/2，這類轉跳，是不會觸發元件的生命週期的，我在vue也遇到過。暫時沒去看原始碼，首先我想到的解決方法就是當這類轉跳發生時，比較兩個路由，如果除了引數那部分都一樣的話，就提取新路由的引數，更新資料，重新渲染。如果你有更好的方法，告訴我謝謝！
還有一個就是引入模組的。假設一個模組裡有好幾個函式或元件，但是我們只要用其中一個，我們這樣匯入時
import { x } from y;
webpack可是會幫你把這整個模組都打包進來的，如果這個模組有1000個函式或1000個元件，那麼為了引入一個，打包其餘的999個。。可想而知問題多大了。最後就是減少重複程式碼吧。比如我的收藏，最近回覆，最近話題等的樣式和邏輯都很類似。那麼沒必要都寫一遍啊。封裝一個元件，然後根據需要傳props進入就可以達到複用的目的。長列表元件也是。沒必要為每個長列表都寫一遍。你只要抽取其中的邏輯，封裝起來，通過傳入props來個性配置使用就好。
大概就上面這麼多。其餘一些由於斷斷續續開發，沒有及時記錄下來，所以忘了。改天回憶一下。
測試
測試就暫時沒做，手動測試了一遍。
反思
一個產品的開發流程，到我這就剩上面的幾部分。開發這個web app時，對於 redux掌管資料，react只要負責檢視渲染的說法有了一些新看法。對於龐大的專案來說，這樣分開，應該很方便維護。react的元件儘量是無狀態的元件的話，我們只要管好資料，它就會正常地工作，這也是純函式的優點，關注點比較專一。也方便合作，比如一個前端工程師負責頁面UI，一個負責資料。這樣合作起來，找bug也很方便。但是開發小型應用時，這樣有點大材小用，就把方便的事情硬是搞複雜了。所以，使用redux的話，不用用到react就下意識決定用redux吧。綜合考慮，如果專案不小，而且未來會越做越大，解耦是最好的，資料和UI分開，後期方面增加新的東西，又不會顯得臃腫，一團麻花。如果做些小專案練手或者未來不會計劃開發下去的，直接在元件的state來儲存資料也可以。
關於輪子。工程開發如果用成熟的輪子能完美解決是最好的。那就儘量別自己寫輪子。畢竟人家的star就證明是千錘百煉的了。但是有時候，實在解決不了，可以選擇看原始碼，找問題。也可以造輪子，達成業務需求。也建議我，你們平時多看原始碼， 理解實現原理對於開發也是很有幫助的。
關於寫程式碼，寫程式碼前先想好再寫吧。真的，不然發現實現不對或者和需求不符合，你又得再來過。比如，路由分塊，一開始覺得怎麼簡單怎麼來，沒意識到頁面越來越多，分塊的需求越來越重要，那麼你又得重新寫router哇。而且那一大堆路由，有得你寫的了。如果平時加一個頁面就寫好了，那就不用付出這多一分勞累了。再比如，我開發點贊評論的saga時，腦子一熱，覺得點贊和取消不就是一個流程麼，點贊後，才能觸發取消點讚的action。這裡就沒有考慮到，一個使用者同時需要多好幾個人點贊，但是這個時候並不需要取消點贊。那麼按一開始的方法寫，點贊後，只能接受到取消點讚的action,並執行完這個非同步http, 才能再接受到點讚的action。那麼使用者除了第一個點讚的評論正確執行外，其餘的都會被忽略到。那就發生了錯誤。所以寫的時候就得仔細想好邏輯。