🔧 阿川の電商水電行
老闆要求用Nextjs+Shadcn寫一個Ruoyi管理後台架子，支持KeepAlive+Tab視窗，主打一個國際接軌
為啥就換Shadcn了
因為Shadcn太火了，不少大大小小的火出圈的AI項目，就是基於Shadcn搭建的，比如assistant-ui，為了與時俱進，與國際接軌，要求我必須整出一套對接好Ruoyi-pro，支持KeepAlive的管理後台架子，準備穩步迭代部分舊有項目和開發新項目，主動迎接AI程式碼智能體的時代，為團隊插上AI賦能翅膀。
反正閒著也是閒著，那就整吧～
shadcn是真“一用一個不吱聲”
看是該給的都給了，實則要啥沒啥，簡直“如給”
但不用慌，這回就到了體現React社區強大之處的時候了～
我想整個Tree，有麼？
- 社區：rc-tree
- 需求：因為ruoyi中有幾處需要tree的地方，比如使用者管理
-
演示：
開發心得：主要是定制上，demo的樣式沒法用，定制起來些許阻礙，不過好在都有辦法解決，花了一天整合出了Shadcn版本，可以為了道友們節省一些精力。
我想整個table，有麼？
- 社區：tanstack table
- 需求：不用問了吧，必須得有的，而且還得支持折疊，選中，翻頁等功能
-
演示：
開發心得：當開發折疊的時候，發現折疊打開的時候，下方的數據會被擠到下一頁的問題，一時不知怎麼解決，翻了文檔，居然真有解決辦法，很輕鬆就解決了，從這一點就能看出來，這個庫有多神，table是玩明白了，面面俱到。
我想整個表單，有麼？
- 社區：react-hook-form
- 需求：不用問了吧，表單太關鍵了
-
演示：
我想整個toast，有麼？
- 社區：sonner
- 需求：不用說了，基本需求
-
演示：
我想整個路由導航進度條，有麼？
- 社區：bprogress
- 需求：Nextjs的路由跳轉的時候，避免不了加載過程，有些時候網絡比較慢，那麼點擊導航的時候看起來像沒反應，體驗不好，加個進度條，提示一下頁面正在加載。
-
演示：
我想整個路由切換動畫，有麼？
- 社區：motion
- 需求：路由切換的時候，最好給個過渡動畫，不然切換太突兀，觀感不好，需要改善一下體驗
-
演示：
我想整個引導教程，有麼？
- 社區：driverjs
- 需求：引導教程
-
演示：
我想整個icon，有麼？
- 社區：iconify
- 需求：簡單好用，海量icon，無需引入太多，僅傳入一個icon字符即可。
-
演示：
keep alive：全網你就找吧，Nextjs的app路由的的keepalive，我這個是獨一份解決方案
三步驟，一步一登梯
- 第一步：keepAlve，
- 第二步：tab導航，因為沒有tab導航的keepalive就是吃醬牛肉不配蒜醬啊，沒有靈魂，現實來看就是，你得讓keepAlive有生命週期，光靠菜單，就會永遠快取，得可以關閉，tab欄就是給你管理keepAlive用的
- 第三步：useActive-可以監聽切換窗口的hook，這步看似不起眼，但實則才是能否完整keep alive的驗金石
方案介紹
本方案為 Next.js 提供了靈活的頁面快取（KeepAlive）能力，適用於多標籤頁、頁面狀態保留等複雜場景。
主要文件說明
- keep-alive：頂層組件，提供全局 KeepAlive 能力
- keep-alive-sign：標記需要快取的頁面或組件
- keep-alive-slot：定向渲染插槽，實現精確渲染
- keep-alive-route：內部業務核心組成，通常無需關注
使用方法
第一步：在頂層 Layout 包裹 KeepAlive
在頁面的 layout 組件（如管理後台 dashboard 的 layout.tsx）中包裹 KeepAlive：
<KeepAlive>{children}</KeepAlive>第二步：在需要快取的頁面中使用 KeepAliveSign
// 客戶端渲染，並且需要快取的組件
const MenuView = () => {
return <div>菜單頁面</div>;
};
export default function MenuPage() {
const customId = "自定義id";
return (
<div>
{/* 其他組件，可為服務端或客戶端組件。key 用於複雜場景避免渲染錯位 */}
<KeepAliveSign key={customId} routeId={customId} ClientView={MenuView}>
...
</KeepAliveSign>
</div>
);
}- routeId：路由唯一標識，必須唯一，用於標記快取頁面
- key：唯一標識，建議複雜場景下使用，避免渲染錯位
- ClientView：需要被快取的客戶端組件
第三步：在 KeepAliveSign 內使用 KeepAliveSlot 實現定點渲染
與服務端組件組合渲染時，KeepAliveSlot 可實現精確定位：
export default function MenuPage() {
const customId = "自定義id";
return (
<div>
<KeepAliveSign key={customId} routeId={customId} ClientView={MenuView}>
{/* 其他組件，可為服務端或客戶端組件 */}
<KeepAliveSlot id={customId} />
{/* 其他組件，可為服務端或客戶端組件 */}
</KeepAliveSign>
</div>
);
}- id：需與 KeepAliveSign 的 routeId 保持一致，無需設定不同值
KeepAlive
Tab導航，拖拽，快取
useActive
路由增強：沒有配置的約定式路由，就剩約定了，沒有大用處
Next.js 原生採用約定式、基於文件系統的路由機制。
那為什麼還需要額外配置路由？
主要是為了滿足更複雜的業務需求，例如：
- 支持 KeepAlive 頁面快取
- 多標籤頁（Tab）視窗
- 菜單權限控制
- 函數式路由跳轉
- 自動補全路由 path，減少重複配置
- 以及其他路由元信息的靈活擴展
本方案透過配置化的數據結構和統一的 routerHelper 工具，將所有與路由相關的業務接口集中管理，極大簡化了路由與接口的維護流程，提升了項目的可擴展性和長期可維護性。
主要文件說明
- router-name：為每個路由分配唯一標識
- routes-config：配置路由的基本信息
- router-provider：增強路由能力，如自動補全 path、提供函數式跳轉等
- router-type：路由相關的類型定義
如何創建一個新路由
第一步：在 router-name.ts 中添加路由名稱
export enum ROUTE_NAME {
// ... 其他路由名稱
user,
}第二步：在 routes-config.ts 中添加路由配置
import { ROUTE_NAME } from "./router-name";
import User from "@/pages/User"; // 假設你有一個User頁面組件
const routesConfig = {
user: {
id: "user",
meta: {
title: "common:UserPageTitle",
icon: "FundProjectionScreenOutlined",
},
},
};
export default routesConfig;第三步：路由跳轉
可在全局任意位置透過函數方式跳轉，組件外也能直接調用：
routerHelper.jumpTo(ROUTE_NAME.dashboard);ruoyi對接
登錄
角色管理
使用者管理
菜單管理
這個項目的魂，是貫徹實踐了MVC模式
看到這個矩陣了嗎，我實現純前端的Antd版本，也實現了Nextjs的Shadcn版本，最難的對角線完成了，足以說明MVC模式的強大，“一套代碼，多套元件庫，支持純前端和Nextjs模式”，有沒有很熟悉，類似一套代碼，多端運行。
我這個是跨中跨，跨的平方，這是MVC模式，或者準確是Flux模式的真誠實踐，不敢說最佳吧，真誠肯定有了，我已經用我這套模式在我的實際工作中兩年了，給我帶來了解放。
現在我的許多業務，完全托管給AI了。
所以說，項目好好寫，業務能分層，有一個清晰統一的套路，是對接AI賦能的關鍵。
你不信？我也不想去自證啥，只能說，你不妨試試，沒什麼損失，不需要你肯定我什麼，但凡能幫你一點，就證明了價值傳導給你了，那麼就算可以了，你要是還能成為更好的自己，繼續傳遞價值，那就是圓滿了，非常好了，我向你致敬，同志。
為啥要用Shadcn，相比Antd，mui又如何？
這個問題太難回答了，我的觀點是當下無腦選shadcn，因為最契合現在AI程式碼智能體時代、
用過這三個元件庫的我，怎麼描述我對三個元件庫的直觀感受呢？em～～就像樂高
Antd
Mui
Shadcn
這三張圖就是我對這三大元件庫的感受，shadcn結合原子化樣式+足夠碎，使其有著更好的組合空間，天花板很高，並且結合AI，可以很容易生成我們想要的東西，
項目地址和預覽地址
還有好多功能細節，玩法技巧，這裡就不作贅述，有興趣的朋友可以自行探索。
源碼已經開源，java用的就是Ruoyi芋道作為後端例子，有興趣的可以自行運行起來。
前端是一個Monorepo，放在了根目錄下的frontend資料夾下，直接運行npm run start即可運行。
什麼你想要Antd版本，有的，兄弟，包有的！
題外話
我寫這個項目，不是為了證明我技術多牛批，也不是證明我文章寫得有多好，而是我想把前端搬磚這件事情，變成他本來該有的樣子。
- 別太糾結用不用，還是用什麼去做狀態管理
- 也不要反覆辯論，用react還是vue，哪個好了
我們應該達成共識，基本的共識，我們在寫的是什麼？是簡單的代碼字符麼？是你抖機靈搞抽象說的元子或是寂寞麼？都不是的
我們在寫的是我們的“道”，每個編程人都應有自己的碼道。
那麼回歸事情的本質，我們為啥用狀態管理，是因為我們要實現業務分層，簡單說就是MVC，準確說flux模式，目的就是業務看起來清晰，維護輕鬆愉快，減輕壓力。
那麼糾結react還是vue，取決於你自己的感受，當你想表達自己的“道”，那麼更純粹，更貼近直覺的，更貼近編程語言習慣，便是最舒服，最自然，我選擇React。
我做遊戲多年轉行做的前端，開始寫Vue，實話實說，一頭霧水當時，知識點好多，但是沒幹多久，我就換React了，一下就行雲流水了，只有有編程功力，那麼寫React就相當順手。
還有咱們得說一個事實，大廠的編程人是要相對有實力的，他們對編程的理解和品味，應該是相對不錯的，大廠普遍選擇React，自然也印證了，在詮釋“道”的方式上，React更被青睞。
當然你也可以說，我說這麼多，MVC分層到底怎麼是魂了，到底怎麼厲害了？
我沒必要去自證這些了，我就算說的天花亂墜，該不接受的還是不接受，你叫不醒。
但是我還是堅持不懈的，傻傻的去實踐，我的目的是讓這浮躁的，充滿噪音的前端圈子，帶去一點安靜的慢力量，
慢下來吧，同志們，帶我們去未來的不一定非得是錢，有個強大平靜的心靈也是可以的。
技術支持
歡迎加入「閒 D 島 🏝️」技術交流群，這裡有大廠工程師、獨立開發者、外包團隊和熱心小夥伴，氛圍純淨，技術交流活躍，期待你的加入！
- 閒 D 島 1 群（500+ 人）：551406017
- 閒 D 島 2 群：1002504812
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
