搭建基于react項(xiàng)目的心得

Barrior 發(fā)布于2019-08-22 18:14 / 2594人閱讀

摘要：在項(xiàng)目開始之前，不能心急立刻去搭建，需要設(shè)定幾個(gè)步驟來開展，接下來大概的說一下我從技術(shù)選型到項(xiàng)目前端搭建好的整個(gè)生命周期。開發(fā)該項(xiàng)目的底層的內(nèi)容遠(yuǎn)不止這些，但由于公司制度規(guī)定，只能大概的闡述了在從接手到選型到搭建完畢這到的過程的做法和思考。

前段時(shí)間部門要基于一個(gè)系統(tǒng)的基礎(chǔ)上開發(fā)一個(gè)管理平臺(tái)，于是我接手了該平臺(tái)的重活，因?yàn)樯弦粋€(gè)平臺(tái)我用了vue搭建，所以這次想用react來搭建。在項(xiàng)目開始之前，不能心急立刻去搭建，需要設(shè)定幾個(gè)步驟來開展，接下來大概的說一下我從技術(shù)選型到項(xiàng)目前端搭建好的整個(gè)生命周期。

技術(shù)選型

在項(xiàng)目開始之前，首先要決定該項(xiàng)目所采用的技術(shù)框架。在該階段，需要分幾個(gè)維度來選擇：
a)核心的前端框架；
b）該框架所配套的路由器；
c）狀態(tài)管理器；
d）異步請(qǐng)求npm包；
f）組件庫(kù)；
g）前端構(gòu)建工具；
h）聯(lián)調(diào)前的mock層技術(shù)；

基于這些維度，我選擇了react一系列核心技術(shù)和其配套技術(shù)，webpack由于求穩(wěn)所以選擇了一個(gè)不高的版本（怕最新的版本會(huì)有很多想不到的坑），然后組件庫(kù)因?yàn)樯弦粋€(gè)項(xiàng)目中用了element.ui，所以比較熟悉他的用法（最主要該組件庫(kù)里面的坑我上一個(gè)項(xiàng)目踩過，所以知道要如何回避）；至于異步請(qǐng)求我還是選擇了用superagent（原因在第2步中會(huì)說到），mock層我選擇了mock.js（但最后我還是沒使用，后續(xù)會(huì)說）；

- 技術(shù)調(diào)研

雖然已經(jīng)選擇了要使用的技術(shù)，但開始之前還是有必要做一個(gè)較為深入的調(diào)研，這樣會(huì)對(duì)已經(jīng)選擇的技術(shù)又一個(gè)大概的使用思路和適不適合使用該技術(shù)做一個(gè)最后的思考。
a）對(duì)于react，我查了一下他最近一年半的發(fā)布版本，然后決定還是用回15.6的版本（好像是17年9月份發(fā)布的），主要是因?yàn)樽钚碌睦锩婧孟褚ヒ恍┥芷冢绻锰拢赡茉陂_發(fā)過程中會(huì)采坑，影響項(xiàng)目的進(jìn)度。

b) react-router的版本選擇，目前有rr3和rr4兩個(gè)版本，其中rr4不支持路由集中配置，這會(huì)引來一系列要解決的問題，如代碼分割（覺得官方處理分割的手法挺麻煩的）等，雖然rr4的組件路由配置挺不錯(cuò)的，使得在大項(xiàng)目中不會(huì)導(dǎo)致路由文件過重，但對(duì)于不大的項(xiàng)目路由組件配置分散的話是不利于維護(hù)，所以還是決定用rr3（后續(xù)還有項(xiàng)目就用一下rr4體驗(yàn)一下）。

c）對(duì)于基于react的項(xiàng)目來說，有兩個(gè)方面處理起來是挺麻煩的，一個(gè)是組件如何減少重復(fù)或者沒必要的渲染；另一方面是redux的使用，redux的使用無疑是加大了項(xiàng)目的復(fù)雜度，但不用也不行，這時(shí)候會(huì)有人說其實(shí)用mobx也挺不錯(cuò)的，確實(shí)，他的響應(yīng)式編程挺好的，處理起來是的很簡(jiǎn)單直觀，然而它存在很多暗坑（網(wǎng)上有說，這里就不說了）。
為什么說redux難，難于在處理異步和數(shù)據(jù)同步，這里有很多優(yōu)異的中間件如redux-thunk等，而該項(xiàng)目中我使用的是我自己寫的中間件（有興趣可以看一下我之前的博客如何寫redux中間件，由于公司有嚴(yán)格的規(guī)定不能泄露項(xiàng)目代碼，雖然都是自己寫，但還是不貼出來，后面會(huì)說一下實(shí)現(xiàn)原理）。
d）superagent和axios的選用，兩個(gè)都是很好的異步請(qǐng)求包，然而這里選擇前者，主要的原因可能偏主觀一點(diǎn)，是因?yàn)閟uperagent用的多，比較熟悉，而且他的鏈?zhǔn)秸{(diào)用挺方便的。

- 創(chuàng)建項(xiàng)目

這里最主要公司有一套自主研發(fā)的代碼倉(cāng)庫(kù)，不需要用到外面的代碼倉(cāng)庫(kù)，所以只能從遵該倉(cāng)庫(kù)的使用規(guī)則創(chuàng)建，如自己寫遠(yuǎn)程編譯的sh腳本，第一次創(chuàng)建還要寫打包腳本等等，其實(shí)這一步在其他公司是不用花太多時(shí)間在這一步的，直接創(chuàng)建上傳到github或者gitlab就好了。

- 配置打包

這里就沒什么好說的，直接看圖就行了。

- 預(yù)編譯器

這里的坑很大，主要不是因?yàn)閟ass使用難，而是因?yàn)閟ass是服務(wù)器編譯的，所以在遠(yuǎn)程倉(cāng)庫(kù)中編譯的時(shí)候會(huì)經(jīng)常失敗，主要原因是因?yàn)閚ode-sass中的vendor文件夾有兩個(gè)版本，一般本地mac開發(fā)webpack編譯的是:

而倉(cāng)庫(kù)本身具有打包編譯功能，它用的是linux，linux則需要

看上去似乎很簡(jiǎn)單，但發(fā)現(xiàn)這原因可找了很久。

異步請(qǐng)求

一般來說，一個(gè)前端項(xiàng)目不可能直接通過superagent或者axios發(fā)起請(qǐng)求，必須對(duì)其進(jìn)行封裝，我這里整個(gè)請(qǐng)求體系有三部分組成：

中間件

redux有很多優(yōu)秀的中間件，但要適合項(xiàng)目的需求還是由自身開發(fā)的中間件會(huì)更貼近。中間件的代碼其實(shí)就是二三十行左右，但卻比較抽象，中間件的結(jié)構(gòu)直接決定action的結(jié)構(gòu)，所以一般先制定好action的具體形式，然后反向推敲中間件的結(jié)構(gòu)。

mock層

本來想用mock.js，技術(shù)調(diào)研的時(shí)候就查清楚使用方法，以及如何使用，但以實(shí)際落實(shí)，卻很多問題，最主要的問題是mock更多的是支持jq形式的ajax，對(duì)于fetch事件不支持，只能通過其他插件如mock-react之類的，這使得mock層成為了一個(gè)累贅，與原來加入mock的初衷相反了，所以最后用來webpack-dev-server中的before服務(wù)器以及proxy代理，共同完成了mock層開發(fā)；
但有考慮到有可能一不小心mock會(huì)影響到線上，所以這里對(duì)所有的api進(jìn)行改造，如果是dev模式且開啟了mock層服務(wù)，所有的api后面加上’_mcok’字符串。

開發(fā)該項(xiàng)目的底層的內(nèi)容遠(yuǎn)不止這些，但由于公司制度規(guī)定，只能大概的闡述了在從接手到選型到搭建完畢這0到1的過程的做法和思考。如果有不對(duì)或理解有誤的地方可以指出來。