最好的 6 款 React admin 后臺管理系統(tǒng)模板和框架
時間：2023-06-12 19:03:01 | 來源：網(wǎng)站運營
時間：2023-06-12 19:03:01 來源：網(wǎng)站運營
最好的 6 款 React admin 后臺管理系統(tǒng)模板和框架：本文首發(fā)：《
最好的 6 款 React admin 后臺管理系統(tǒng)模板和框架》
React admin框架繁多，在本文里我們介紹 React 下最好的 6 款后臺系統(tǒng)，每款均嚴格測試后，整理它們的優(yōu)缺點方便你來挑選。同時我們給出一些實用建議，幫你避免選型時不注意可能導致的埋坑。
為什么后臺系統(tǒng)極其重要
一個成熟好用的后臺管理系統(tǒng)對于公司運營效率有極大提升，而對程序員來說，很多時候?qū)懞笈_系統(tǒng)其實都是在“幫個忙”，原因是這些后臺系統(tǒng)多數(shù)情況下和公司的主營業(yè)務并沒有太大關系。
比如說，運營會請你寫個系統(tǒng)來幫助管理商品，人事會請你寫個系統(tǒng)來管理公司人員等等。因此，找一個稱手的模板和框架可以省下大量的時間。如果需要馬上搭建馬上能上線的后臺系統(tǒng)，可以直接考慮卡拉云(見后文)，比模板和二次開發(fā)更快更方便，同時功能豐富得多。
如何挑選 React admin后臺
有的時候選擇一個后臺系統(tǒng)框架時，一個開始沒注意到的小問題可能導致之后系統(tǒng)完全無法使用。舉個例子，如果你的整套系統(tǒng)用了 SCSS 來寫界面，而這個后臺框架并不支持 SCSS，那么你還需要額外的精力把 SCSS 集成進去。因此，在下文評測中我們盡量把這些細節(jié)展示出來。
我們用以下一些標準來評判 React 下的后臺系統(tǒng)模板。
開發(fā)者體驗
首先后臺系統(tǒng)要能用得起來，開發(fā)者(也就是你)得盡量少花功夫在這個框架上，也就是說這個框架本身的 API、組件或者接口需要設計得足夠好，足夠能用。否則，如果需要大量蠻力適配(brute-force)才能滿足需要的話，還不如不用框架自己寫好了。
權限管理
一個后臺系統(tǒng)是不是具有完備的權限管理，對于絕大多數(shù)公司來說都極為重要。比如，很難想象讓一個公司請的外包運營成員來直接操作公司的用戶數(shù)據(jù)庫。而正確的做法是給他們分配合適的權限，讓一部分人員只能操作限定的動作。
權限管理說起來簡單，但是絕大多數(shù)前端模板中是無法實現(xiàn)的，必須配合后端。而是不是有好的接口設計就決定了與后端的權限管理對接時是否足夠容易。
組件豐富程度
有一些組件對于一些后臺來說極為重要，比如說如果你的后臺是一個員工報銷系統(tǒng)，那么時間選擇器可能就非常重要，因為可能需要注明發(fā)票報銷的時間。如果你的后臺需要展示服務器運行時間、用戶數(shù)，那么報表、圖表組件就很重要。
對絕大多數(shù)后臺來說，
表格組件也非常重要。但是不管是表格、圖表還是時間選擇器，都是實現(xiàn)比較困難的前端組件。所以要找到一個框架要剛好把這三個組件都做得好，是不太容易的事情。
因此組件的豐富程度和完善度，也是挑選后臺系統(tǒng)的重要標準。
React 后臺系統(tǒng)的類別
React 后臺系統(tǒng)可以粗略地分為以下幾種類別
- 僅前端模板
- 前后端集成系統(tǒng)，需要數(shù)據(jù)遷移
- 前后端集成且有方便的數(shù)據(jù)接口
對于 1，適合后臺已經(jīng)成型，所有后臺 API、數(shù)據(jù)庫連接均已經(jīng)包好的情況下。
第一種是指只有前端代碼的 React 后臺系統(tǒng)。當然，后臺系統(tǒng)顯然是用來操作后端數(shù)據(jù)的，所以不接“后端”的后臺系統(tǒng)是不存在的，選用這種后臺系統(tǒng)的話，你需要自己提供后端接口和數(shù)據(jù)庫接口等。這個類型的代表有
antd 和各種純 UI 的 react 框架，比如
Material UI,
Mi-UI 等。
第二種是指不僅有前端代碼，同時也包含了后端服務。如果需要一些新的后端接口，則需要調(diào)整和開發(fā)后端接口。通常來說，這類后臺系統(tǒng)都是打包銷售，比如 SAP，SalesForce 出售的一些 SaaS 后臺系統(tǒng)，本文里就不展開討論了。
第三種是指，前端后端集成，但不需要數(shù)據(jù)遷移?？蚣芴峁┝藬?shù)據(jù)接口，你只需要把你的數(shù)據(jù)接入即可使用。這個類型的代表有
卡拉云。
那么什么情況下選擇哪種后臺系統(tǒng)呢？
情況一如果你已經(jīng)有一個成型的后臺系統(tǒng)，現(xiàn)在只需要把后臺界面做得更方便、漂亮，或者增加一些組件的情況下:，你可以應該選擇方案 1 或者方案 3。
原因是你已經(jīng)非常明確你需要哪些組件，工作流的流程怎樣，甚至已經(jīng)有后端接口可以直接接入，那么二次開發(fā)一下前端框架可能就可以滿足你的需求了?；蛘哂梅桨?3，可以比較輕松地把數(shù)據(jù)接口接入，而不用對后臺接口做太多調(diào)整。
情況二還沒有后端，只有數(shù)據(jù)庫。
這個情況應該是絕大多數(shù)創(chuàng)業(yè)公司在尋找第一個后臺系統(tǒng)時遇到的情況，工程師資源全部集中在公司業(yè)務上，沒有人有精力和時間來開發(fā)后臺系統(tǒng)。然而后臺系統(tǒng)又極為重要，所以開始急沖沖地找一個方案。
在這種情況下，我們推薦使用方案 3，原因是后端接口還不成型，工作流不清晰可能還需要大量迭代。這種情況下直接開始固化后端是不明智的。
情況三沒有前端，只有后端接口。這樣的情況在創(chuàng)業(yè)公司，甚至不少大廠中也占有一定比例。沒有前端的情況下，有時候開發(fā)者甚至會直接采用直接查詢和修改數(shù)據(jù)庫的方式來使用“后臺系統(tǒng)”。
在這種狀態(tài)下，也推薦使用方案 3，直接將數(shù)據(jù)庫接入，同時用
拖拽、配置的方式生成前端。
react-admin
React-admin 是一款提供前端組件，同時還提供后端數(shù)據(jù)接口的框架。目前它在 github 上有 19.1K 的星。注意，通常來說我們講的“react后臺系統(tǒng)”一般英文翻譯為
react admin，而這款框架本身比較討巧，名字本身就叫
react-admin，請注意不要混淆了概念。
react-admin 的優(yōu)點非常明顯
- 支持常見組件，比如表格、文本輸入框、數(shù)字輸入框等
- 提供前端權限控制接口(但需要單獨與后端集成)
- 提供 i18n 可以翻譯界面
- 完成度較高，五年的老項目，代碼質(zhì)量過硬
- 代碼同時支持 TypeScirpt 和 JavaScript，開發(fā)體驗好
但它的不足也很明顯。
首先，組件的功能性較弱，因此需要的前端二次開發(fā)較重，只適合比較簡單的使用場景。如果需要二次開發(fā)，則需要前端工程師對這個框架和 React 本身了解較深。
其次，它的數(shù)據(jù)接口層比較輕，對于不同的數(shù)據(jù)(比如REST API)需要使用不同的接口，這些都需要單獨集成和調(diào)試。
最后需要考慮的地方是，雖然它在 GitHub 上有大量的贊(19000)，但真正使用的項目還不如其贊多(8700)，因此社區(qū)的活躍程度也并是非常高，react-admin 的最近一次代碼提交是幾個月前。
AdminJS
AdminJS 與 react-admin 非常類似，也是一款主要提供前端 React 模板，同時提供輕后端接口的框架。但它開始得比較晚，目前在 GitHub 上有 4800 個星。
AdminJS 的主要優(yōu)點有
- 支持部分常見組件，比如表格、文本輸入框、下拉菜單
- 文檔較全面，整個文檔由 JSDoc 寫成，非常詳細
- 項目較新，維護比較勤
- 代碼同時支持 TypeScirpt 和 JavaScript，開發(fā)體驗好
但是有以下幾個非常明顯的缺點，我認為如果你在考慮 AdminJS 的話，不如考慮 react-admin 或卡拉云。
首先，AdminJS 的使用面非常窄，目前在 GitHub 上只有 188 的使用。
其次，它的代碼復雜度極高，側面反應架構設計不合理。另一方面，如果去看它的文檔的話，會發(fā)現(xiàn)如果要在 AdminJS 上做二次開發(fā)，基本上就重新學了一套新框架了，時間成本上并不劃算，同時如果遇到問題卡住項目極容易難產(chǎn)。
當然即使如此，在為數(shù)不多的后臺框架里，AdminJS 也是較為優(yōu)秀的一款了。
卡拉云
卡拉云與其它的框架都不太一樣，它不光提供一個前端框架，還提供了一個完整的前端編輯器。同時，卡拉云還提供完整的后端接口，讓你可以直接接入自己的數(shù)據(jù)庫。在前端，你可以通過前端編輯器來配置組件，包括
- 表格
- 圖表
- 文本輸入
- 數(shù)字輸入
- 地圖
- 時間選擇組件
- 文件上傳組件
- 富文本編輯組件
- JSON 編輯組件
- 數(shù)據(jù)標注組件
等等
同時每個組件都有單獨的可配置項，每個可配置項均支持用 JS 來定制邏輯。因此即使是像表格這樣超復雜的前端組件，在卡拉云里你也可以通過細節(jié)配置，加上 JS 邏輯，來滿足任意復雜的需求。比如，下圖為卡拉云中對表格組件的配置選項，你可以針對每列動態(tài)隱藏、調(diào)整背景色，調(diào)整顯示類型比如圖片、鏈接等等豐富的配置功能。同時因為任何配置項都支持 JS，因此配置的靈活度幾乎等同于直接寫 React 代碼。
只要前端工程師會基本的 JavaScript(不會的話可能也不能叫前端了)，就可以在前端定制出任意復雜度的后臺。
在后端，卡拉云支持直接查詢和更新常見數(shù)據(jù)庫，如 MySQL，PostgreSQL和 MongoDB 等，同時也支持 REST
API 來調(diào)用你自己的 API 端口或第三方 API。
使用卡拉云的優(yōu)點非常明顯，你基本可以省掉要開發(fā)維護一個后臺系統(tǒng)要操的心了，這樣可以讓工程師專注于公司本身的業(yè)務線。同時不管是組件豐富度和完成度，以及權限系統(tǒng)的穩(wěn)固程度，卡拉云都比市面上其它框架和公司做得牢靠一些，具體詳情請參考
我們的文檔。
antd
antd 即
Ant Design 的簡寫，也就是螞蟻金服的著名前端框架。
antd 可以說是泛前端框架里的翹楚了，從概念上來說，它提供了很多常見的前端組件，包括表格、輸入框、下拉菜單等等，每個組件均提供一些參數(shù)以供配置使用。
但嚴格來說，antd 并不是特意為“后臺系統(tǒng)”而存在的，因此如果你想要用 antd 來搭建后臺系統(tǒng)的話，它只是幫助你把 CSS 和組件設計這兩件事情做了一些，但后臺系統(tǒng)中需要的邏輯還是需要自己開發(fā)的。 比如舉個例子，antd 提供了類似
Avatar 這樣的組件，用來展示登錄用戶頭像，但一個用戶是不是登錄了、登錄的邏輯是怎樣的，這些都是需要你自己提供邏輯的。
從經(jīng)驗上看，后臺系統(tǒng)與直接面向消費者(to C)的場景不同，后臺系統(tǒng)多數(shù)情況下可以承受較簡單甚至粗糙的 UI，以換取更豐富、復雜的功能。而面向消費者的場景通常則需要將功能做得足夠簡單，且 UI/UX 極為重要。因此，多數(shù)情況下開發(fā)后臺系統(tǒng)時，精力均在如何把對的數(shù)據(jù)，正確地連接和展示出來，同時提供組件以供用戶操作。
antd 提供了
展示 這一步，但其它的邏輯就需要前端工程師來黏合了。因此，antd 比較適合需求較為固化，不經(jīng)常更改，同時工程師資源有剩余的情況下。 如果需要快速迭代，則應該考慮上文中提到的前三種框架。
react-antd-admin
react-antd-admin 是在 antd 的基礎上，由
@jiangxy 開發(fā)的后臺系統(tǒng)。它只包含前端部分，因此如果需要任何權限控制或者與后端連接的話，需要單獨做二次開發(fā)。
這個項目在早期開發(fā)頻率還可以，因此在 GitHub 上積累了 1400 個星，但由于繁忙，后來就停止了開發(fā)。上一次代碼提交還是五年前，因此對比下來，不建議使用。同時作者自己也在 GitHub 的 readme 中也提到了安全和權限的問題:
安全/權限問題目前對安全&權限都沒考慮進去，如果有這方面的要求，只能后端校驗了。在請求后端接口時校驗用戶的身份和權限。權限問題也很麻煩，感覺不太好做成通用的東西，如果有需求的話，還是定制開發(fā)比較好。兼容性如果你在考慮使用 react-antd-admin 的話，建議直接在 ant 的基礎上自己開發(fā)，或者使用類似卡拉云這樣完成度較高的系統(tǒng)。
shards-dashboard-react
shards-dashboard-react是一套 react 下的后臺開發(fā)模板，注意這個模板的含義基本就是指它只包含了常見組件和其對應的 CSS，而不包含組件具體的邏輯處理。它的界面如下
如果你的項目中，只是需要添加更多的組件，特別是 Material 風格的組件，那么使用
shards-dashboard-react 會比較合適。但如果連后端接口都沒有，那么則需要考慮使用本文前面提到的三個框架或系統(tǒng)，
react-admin,
adminjs 或
卡拉云。
總結
本文中我們介紹了市面上最好的幾款 React 后臺框架，比較了它們的優(yōu)缺點。相信這篇文章可以幫助你在技術選型的時候，提供一些參考。如果你對卡拉云感興趣，歡迎聯(lián)系我們。如果你對 Vue 的框架感興趣，也歡迎閱讀
最好用的 7 款 Vue admin 后臺管理框架測評 和
7 個 Laravel admin 后臺管理系統(tǒng)推薦
在線咨詢
