React全家桶實戰-react版的cnode webapp

前言

學習一門前端框架，不動手是不行的。因此當我學習react有一段時間時，就打算開始寫一個react的我的項目,先後端一塊兒寫的話，比較耗時間，因此就選了提供了優質api的Cnode社區，感謝。（若是我參與的合做項目，產品選的技術棧是react的話，我也不用本身寫個app了,Orz）

但願各位大爺給個star勒,就右上角輕輕一點，比心

傳送門：源碼地址

最近用mobx重構了一遍，也發了篇文章，傳送門

Demo

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。那麼用戶除了第一個點讚的評論正確執行外，其他的都會被忽略到。那就發生了錯誤。因此寫的時候就得仔細想好邏輯。