從零帶你架構一個企業級 React 項目

「本文已參與好文召集令活動，點擊查看：後端、大前端雙賽道投稿，2萬元獎池等你挑戰！」javascript

本文沒有隻針對 React 讀者，除了強相關 React 技術棧的內容，其餘東西徹底是能夠應用進任意技術棧的項目。css

通常在公司內部開發一個新項目，腳手架一把梭而後就開幹了。由此一部分開發人員會缺失一些知識點，好比說爲何咱們要選擇這套技術棧進行開發；項目裏的工程化配置到底應該怎麼搞，一旦本身上手就懵逼；腳手架究竟是個什麼東西（至關一部分讀者朋友認爲腳手架是個很厲害的東西），如何整一個適合業務開發的企業級腳手架。前端

一個 React 項目會涉及到不少通用的東西，同時又存在不少選擇性。單人開發能夠按照本身的喜愛來隨意整合，可是在多人開發多項目的場景下，勢必須要一整套規範來限制你們。文章將根據如下大綱和各位讀者聊聊咱們如何架構一個企業級 React 項目，以及最終如何將這套東西整合進腳手架。java

接下來假定你目前處於一家主要使用 React 開發的公司。多人團隊，且已有項目上線，隨着業務的發展及人員的增長，大家急需創建一套完整統一且規範的開發流程，老闆須要你全權負責這塊內容並最終產出一個腳手架。react

技術棧選擇

對於一個 React 項目來講，通用的技術棧確定須要考慮如下內容：git

TS 仍是 JS？
選擇 Hooks 仍是非 Hooks 仍是混合？
CSS 方案，是 Saas 這類預處理亦或者 CSS-In-JS、Atom CSS？
狀態管理怎麼選？
Route 怎麼選？其實這個選擇性不多

首先在考慮某個技術優劣以前，咱們先須要對團隊狀況進行分析。github

好比說咱們如今須要考慮是選擇 TS 仍是 JS，那麼首先應該先考慮團隊成員是否大部分已經瞭解或者開發過 TS 項目。若是大部分紅員對 TS 是一個不熟練、有抵觸心理的狀態，那麼強上 TS 勢必會帶來開發效率的下降，項目裏 any 遍地飛。固然若是 Leader 能承受短時間的效率下降，那麼TS 的方案就能夠擺在選項上，不然該選項可能就須要稍稍靠後，或者說只在部分項目裏慢慢開始推廣。後端

接下來我會以上述技術棧爲例來講明在選型時咱們須要從哪些角度去考慮問題。緩存

選擇 Hooks 仍是非 Hooks 仍是混合？

下表中的上手成本針對於團隊成員已經會用類組件寫 React 項目的前提下。babel

	Hooks	非 Hooks	混合
上手成本	高	無	高
功能複用性	高	低	中
代碼可讀性	高	低	中
各自常見缺陷	閉包陷阱、對比類組件生命週期不全	JS Class 缺陷	都有
老項目遷移成本	高	無	中

Hooks 的選擇其實早幾年就有文章開始聊了，因此我這裏就再也不班門弄斧來大聊特聊各自的優缺點了，上表也只是列了些常見的對比。

這個小節主要是給你們一個思路，在遇到選型的時候，咱們該從哪幾個方向去考慮。

CSS 方案

	CSS-In-JS	Atom CSS	預處理
上手成本	高	中	幾乎沒有
樣式覆蓋成本	高，須要暴露給外部 class 或者單個節點的 style	無	無
代碼可讀性	高	幾乎沒有	高
支持 postcss	不支持，得用本身的	支持	支持
SSR 支持度	服務端那塊須要額外寫代碼	支持	支持

對於 CSS 方案的選擇，筆者早在年初的時候就寫過一篇文章，你們有興趣的話能夠自行閱讀，下面的話筆者來簡單聊聊這些方案。

CSS-In-JS

這個方案筆者已經用了兩年了，具體用的是styled-components這個庫（下文簡稱 sc）。總的來講感受這種方案對於 React 來講是很香的，而且解決了我很討厭的傳統寫 CSS 的一些點，好比說得寫一堆 class，真的是取名困難戶。

經過這個庫咱們須要用 JS 來管理 CSS，所以就能夠充分享受 JS 帶來的工具鏈好處了。一旦項目中出現沒有使用到的樣式組件，那麼 ESLint 就能夠幫助咱們找到那些死代碼並清除，這個功能對於大型項目來講仍是能減小一部分代碼體積的。

除此以外，樣式污染、取名問題、自動添加前綴這些問題也很好的解決了。除了以上這些，再來聊兩點不容易注意到的。

首先是動態切換主題。由於咱們是經過 JS 來寫 CSS 了，那麼咱們就能夠動態地控制樣式。若是你的項目有切換主題這種相似的大量動態 CSS 的需求，那麼這個方案會是一個不錯的選擇。

還有個點是按需加載。由於咱們是經過 JS 寫的 CSS，現階段打包基本都走的 code split，那麼就能夠實現 CSS 文件的按需加載，而不是傳統方式的一次性所有加載進來（固然也是能夠優化的，只是沒那麼方便）。

說完了優先再來聊聊缺點，學習成本確定存在，這個沒啥好說的。另外也有運行時成本，sc 自己就有文件體積，加上還須要動態生成 CSS，那麼這其中一定有性能上的損耗。項目越大影響的也會越大，若是你的項目對於性能有很高的要求，那麼須要謹慎考慮使用。另外由於 CSS 動態生成，因此不能像傳統 CSS 同樣緩存 CSS 文件了。除此以外，樣式覆蓋成本相較其它方案也略高，同時也不支持 postcss，針對 SSR 方案也有額外的開發成本。

Atom CSS

代碼可讀性差，學習成本不低，可是在存在成熟的 UI 規範下，該方案能提供通用樣式來進行復用，從而下降 CSS 文件體積。

其實筆者並不看好這個方案在國內業務團隊中的大範圍應用，由於需求的頻繁變動致使的 UI 變動以及絕大部分 UI 團隊沒有一個成熟的規範，這些問題會顯著提升使用 Atom CSS 的成本。

預處理方案

應該算是傳統方案了，該有的都有，開發成本也低，無非存在 CSS 的通病：調試起來是真的蛋疼。

小結

總的來講用 CSS-In-JS 須要考慮學習成本及團隊成員的接受程度，畢竟確實存在一部分開發人員是不喜歡這種方式來書寫 CSS 的。

Atom CSS 的話必定務必須要有一套成熟的 UI 規範，不然隨着需求的變化頻繁亂改 UI，相信我，必定會火葬場的。

預處理方案沒啥好說的，幾乎沒有上手成本，代碼也方便維護。若是團隊成員不喜歡 CSS-In-JS 而且也沒有一套成熟的 UI 規範，就選這個唄。

狀態管理怎麼選？

狀態管理真的有太多選擇了，除了你們耳熟能詳的 Redux 和 mobx，其它還有一大堆競品，好比說：

xstate
Recoil
pmndrs家出品的 zustand、valtio、jotai
另外還有好多小衆產品

咱們在對狀態管理進行選型的時候，其實第一步應該考慮項目是否須要狀態管理，實際上大部分項目須要的只是跨組件的通訊，而不是管理。或者說實際上當你在考慮項目是否須要狀態管理的時候，基本上此時就是不須要的。由於你可能壓根還沒遇到狀態管理解決的痛點，而只是以爲跨組件通訊麻煩。

若是你的項目還沒上升到須要狀態管理的時候，能夠考慮選擇狀態共享庫（相似hox）外加 hooks 一把梭，實際上這個方案基本能夠覆蓋大部分項目了，寫出來的狀態相關的代碼也不容易屎山。

若是項目真的須要狀態管理，那麼儘可能別去考慮技術相關的東西，而是選擇一個你們熟悉的東西直接用。由於狀態管理太容易寫出屎山了，咱們巴拉巴拉對比了一堆技術相關的東西，最終若是選擇了一個相對先進但你們不熟悉的產品，那麼最後屎山應該是避免不了的。

Route 怎麼選？

路由這塊其實我的認爲沒啥好選的，畢竟可選擇的餘地基本沒有，選哪一個都對開發沒什麼影響，因此愛選啥選啥吧。

其餘

除了上面所說的技術選型，咱們可能還會根據項目的不一樣存在更多的技術需求，好比說單測等等。

單測

業務團隊寫單測的很少，尤爲是 UI 相關的。可是咱們能夠退而求其次，對工具函數或者一些關鍵節點作下單測，提升一下總體的代碼質量。

工具函數測試的話，直接上 Jest 或者 Mocha 就行，反正也就是斷言的事情。若是要測試 UI 相關的，那麼 enzyme 以及 react-testing-library 也是必不可少的。最後若是大家還想整一整自動化測試，那麼就上 cypress 吧。

另外筆者以前也寫過一篇單測的文章，有興趣的讀者能夠本身閱讀下。

小結

實際上在進行技術選型的時候，技術相關的內容極可能是最後纔會考慮的，在這以前咱們須要結合團隊、項目工期、項目訴求等外部因素來權衡。

最後關於各個技術棧的選擇你們能夠瀏覽雲謙大佬搞的倉庫，應該算是覆蓋的很全面了。

工程化配置

項目中的工程化配置是至關重要的一環，這部份內容對於開發人員來講應該儘量少的配置，在常見場景下要實現開箱即用，而且對於一部分配置強管控。

筆者和一些處在小公司的前端開發聊過，瞭解到他們的開發其實至關混亂。好比說：

工程配置每一個項目都不一樣，具體體如今 Webpack 配置混亂、ESLint 形同虛設、代碼格式混亂等問題上
commit 提交沒有規範，代碼沒人 review
等等。。。

以上這類問題若是恰巧發生於正在閱讀文章的你的團隊，你也許能夠按照筆者下文中的思路去嘗試改進。

對於一個項目來講，如下內容應該是必須的：

構建器配置，在應用中通常都是 Webpack
Babel 配置
TS 配置
ESLint 配置
Prettier 配置

針對以上內容來講，我的認爲除了第二和三點，其餘幾項都是須要強管控的。

對於 Webpack 而言，你們都知道配置起來挺麻煩的，可是其中至關一部分配置在各個應用中應該是通用的。咱們是能夠抽離出這部分通用的配置並作成一個內部的 preset 的，就像@babel/preset-env同樣。這種作法簡化了須要配置的內容，從而杜絕用戶瞎搞形成各個項目 Webpack 混亂的局面。同時之後在升級 Webpack 的時候，也無需用戶關注通用配置的修改，只須要對本身新增的配置作適配便可。

那麼對於 ESLint 和 Prettier 來講，強管控是必須的，把配置封裝起來直接讓用戶 require 就行。這樣就能杜絕換個項目 ESLint 被關閉了、編碼格式全變了的狀況，這種問題其實對代碼質量是有毀滅性打擊的，你們都會破罐子破摔寫代碼。

總的來講，對於工程化配置咱們最好儘量少的讓用戶去接觸配置，專心業務代碼便可。能強管控的地方務必強管控起來，對於整個團隊的代碼質量都是有提高的。固然咱們確定不能把全部配置都強管控起來，有的地方仍是須要開個口子讓用戶能自定義 / 合併配置項的，好比 Webpack。

目錄結構

一個好的項目目錄是能提升項目的維護性的，不然代碼沒有條理的亂放，本身可能寫爽了，可是對於接手的同事來講真的是會頭大的。

筆者大體會把一個項目目錄分爲如下幾塊：

pages，頁面，其中每一個文件夾按照功能模塊劃分
components，組件，分爲 common 及業務組件
services，和後端打交道的地方
store，狀態管理邏輯相關，若是須要的話
utils，常量、工具函數等
types，TS 項目須要，存放類型
assets，靜態資源，好比說圖片、svg 這類
tests，測試相關，若是須要的話

根據以上分類，咱們一個項目大體目錄會長成這樣：

└── /src
    ├── /pages
    ├── /components
    ├── /services
    ├── /store
    ├── /utils
    ├── /types
    ├── /assets
    ├── /tests
    ├── index.ts
    └── App.ts
複製代碼

除了以上內容，根據咱們不一樣的 CSS 選型以及工程化的選擇，對應的文件也會有所不一樣。

整合進腳手架

腳手架簡單來講就是幫咱們 git clone 了一個初始化項目過來，一個最基礎的腳手架大概能夠分爲兩塊內容：

工程化配置和模板代碼上文已經聊過一些了，你們能夠根據本身業務的不一樣來整出這樣一套東西，可是僅有這些還不足以作出一個好用的腳手架。

舉個例子，有些業務須要作單測怎麼辦？又須要業務方本身去作一大堆配置麼？

好比說根據業務的不一樣，模板可能也會存在細微的不一樣，這時候咱們是從新再搞一套模板仍是怎麼辦？

所以對於腳手架來講，咱們須要在必備的工程化配置之上，再加上一些可選的內容。好比說業務方認爲項目須要單測，那麼在初始化項目的時候選上單測就能夠自動加入單測所需的配置。

再而後由於業務的不一樣，模板代碼上可能存在不一樣，這時候咱們能夠依照狀況來決定是再拆分一套模板仍是在原有的模板上支持編譯，從而根據用戶的輸入來決定最終的模板輸出。

作好以上這些東西咱們可能才勉強作出一個好用點的且適合自身團隊業務的腳手架。

最後

文章沒有代碼，主要仍是分享了從筆者的角度去考慮如何從零設計一個 React 項目，其中的技術棧選型大概是怎麼樣的、工程化這塊該怎麼搞的好用點、項目目錄結構大概長什麼樣子，以及最後聊了聊如何作一個好用的腳手架。

做者：yck

倉庫：Github

公衆號：前端真好玩

特別聲明：原創不易，未經受權不得轉載或抄襲，如需轉載可聯繫筆者受權