前段時間部門要基於一個系統的基礎上開發一個管理平臺,因而我接手了該平臺的重活,由於上一個平臺我用了vue搭建,因此此次想用react來搭建。在項目開始以前,不能心急馬上去搭建,須要設定幾個步驟來開展,接下來大概的說一下我從技術選型到項目前端搭建好的整個生命週期。前端
技術選型vue
在項目開始以前,首先要決定該項目所採用的技術框架。在該階段,須要分幾個維度來選擇: a)核心的前端框架; b)該框架所配套的路由器; c)狀態管理器; d)異步請求npm包; f)組件庫; g)前端構建工具; h)聯調前的mock層技術;
基於這些維度,我選擇了react一系列核心技術和其配套技術,webpack因爲求穩因此選擇了一個不高的版本(怕最新的版本會有不少想不到的坑),而後組件庫由於上一個項目中用了element.ui,因此比較熟悉他的用法(最主要該組件庫裏面的坑我上一個項目踩過,因此知道要如何迴避);至於異步請求我仍是選擇了用superagent(緣由在第2步中會說到),mock層我選擇了mock.js(但最後我仍是沒使用,後續會說);node
- 技術調研react
雖然已經選擇了要使用的技術,但開始以前仍是有必要作一個較爲深刻的調研,這樣會對已經選擇的技術又一個大概的使用思路和適不適合使用該技術作一個最後的思考。 a)對於react,我查了一下他最近一年半的發佈版本,而後決定仍是用回15.6的版本(好像是17年9月份發佈的),主要是由於最新的裏面好像要除去一些生命週期,若是用太新,可能在開發過程當中會採坑,影響項目的進度。 b) react-router的版本選擇,目前有rr3和rr4兩個版本,其中rr4不支持路由集中配置,這會引來一系列要解決的問題,如代碼分割(以爲官方處理分割的手法挺麻煩的)等,雖然rr4的組件路由配置挺不錯的,使得在大項目中不會致使路由文件太重,但對於不大的項目路由組件配置分散的話是不利於維護,因此仍是決定用rr3(後續還有項目就用一下rr4體驗一下)。 c)對於基於react的項目來講,有兩個方面處理起來是挺麻煩的,一個是組件如何減小重複或者不必的渲染;另外一方面是redux的使用,redux的使用無疑是加大了項目的複雜度,但不用也不行,這時候會有人說其實用mobx也挺不錯的,確實,他的響應式編程挺好的,處理起來是的很簡單直觀,然而它存在不少暗坑(網上有說,這裏就不說了)。 爲何說redux難,難於在處理異步和數據同步,這裏有不少優異的中間件如redux-thunk等,而該項目中我使用的是我本身寫的中間件(有興趣能夠看一下我以前的博客如何寫redux中間件,因爲公司有嚴格的規定不能泄露項目代碼,雖然都是本身寫,但仍是不貼出來,後面會說一下實現原理)。 d)superagent和axios的選用,兩個都是很好的異步請求包,然而這裏選擇前者,主要的緣由可能偏主觀一點,是由於superagent用的多,比較熟悉,並且他的鏈式調用挺方便的。
- 建立項目linux
這裏最主要公司有一套自主研發的代碼倉庫,不須要用到外面的代碼倉庫,因此只能從遵該倉庫的使用規則建立,如本身寫遠程編譯的sh腳本,第一次建立還要寫打包腳本等等,其實這一步在其餘公司是不用花太多時間在這一步的,直接建立上傳到github或者gitlab就行了。
- 配置打包webpack
這裏就沒什麼好說的,直接看圖就好了。ios
- 預編譯器git
這裏的坑很大,主要不是由於sass使用難,而是由於sass是服務器編譯的,因此在遠程倉庫中編譯的時候會常常失敗,主要緣由是由於node-sass中的vendor文件夾有兩個版本,通常本地mac開發webpack編譯的是:github
而倉庫自己具備打包編譯功能,它用的是linux,linux則須要web
看上去彷佛很簡單,但發現這緣由可找了好久。
通常來講,一個前端項目不可能直接經過superagent或者axios發起請求,必須對其進行封裝,我這裏整個請求體系有三部分組成:
redux有不少優秀的中間件,但要適合項目的需求仍是由自身開發的中間件會更貼近。中間件的代碼其實就是二三十行左右,但卻比較抽象,中間件的結構直接決定action的結構,因此通常先制定好action的具體形式,而後反向推敲中間件的結構。
原本想用mock.js,技術調研的時候就查清楚使用方法,以及如何使用,但以實際落實,卻不少問題,最主要的問題是mock更多的是支持jq形式的ajax,對於fetch事件不支持,只能經過其餘插件如mock-react之類的,這使得mock層成爲了一個累贅,與原來加入mock的初衷相反了,因此最後用來webpack-dev-server中的before服務器以及proxy代理,共同完成了mock層開發;
但有考慮到有可能一不當心mock會影響到線上,因此這裏對全部的api進行改造,若是是dev模式且開啓了mock層服務,全部的api後面加上’_mcok’字符串。
開發該項目的底層的內容遠不止這些,但因爲公司制度規定,只能大概的闡述了在從接手到選型到搭建完畢這0到1的過程的作法和思考。若是有不對或理解有誤的地方能夠指出來。