React 在 Wordpress 上實作 menu
WHY: 為何需要這次優化與重構？
背景： 公司核心的電商官網基於 WordPress 建置。在不考慮完全重寫的前提下，我們計劃對官網的主選單 (Menu) 進行現代化改版，以提升品牌形象與使用者體驗。
挑戰：
-
客製化與品牌體驗受限： 原生 WordPress Menu 功能無法滿足我們對品牌視覺和互動體驗所追求的高度客製化需求，限制了創意的實現。
-
技術棧單一與未來發展瓶頸： 團隊當時僅有一位 WordPress 工程師，技術棧較為單一。從長遠戰略來看，團隊已確定未來將走向前後端分離的開發模式。若持續深度依賴 WordPress 外掛生態，不僅會累積技術債，更會限制未來的技術擴展性，並增加招聘專職前端工程師的難度。
目標： 此任務的核心目標是為既有的 WordPress 體系導入現代前端框架 (React) 的開發模式。我們期望透過實作一個高度模組化的 Menu，來驗證此混合架構 (Hybrid Architecture) 的可行性。最終目標是為未來的開發團隊鋪平道路，使其不再受限於 WordPress 框架的束縛，讓熟悉 React 的前端工程師能無痛接軌。
HOW: 我是如何分析問題並推動執行的？
在這次任務中，我擔任主要開發者與技術探勘者的角色，負責從研究、規劃到實作的全過程，步驟大致如下
分析與規劃：
-
可行性研究： 在投入開發前，我進行了深入的技術調研，確認將 React 應用程式嵌入現有 WordPress 主題的可行性，並試著找到業界使否有人也這樣使用 Wordpress + React。
-
流程設計： 我預先設想了新的開發與部署流程中可能遇到的挑戰，特別是如何讓 React 的打包產物能被 WordPress 主題順利引用，並與既有專案共存。
具體行動與技術方案：
-
技術選型： 我選擇使用 CRA + React 進行開發以及支援處理多入口點 (Multi-Entry Point) 的打包需求。
-
模組化開發： 我獨立開發了整個 Menu 元件，並將其設計為一個可複用的模組。資料來源依然由 WordPress 後台進行管理，前端 React 元件僅專注於渲染邏輯，避免使用者需要學習新工具來設定 Menu。
-
解決整合難點： 最大的技術挑戰在於處理多入口點 (Multi-Entry Point) 的前端打包。由於網站上除了新的 React 專案，還存在舊有的純 JavaScript 專案，我透過合理的建置配置，成功讓兩者並存且能部署。
WHAT: 最終達成了什麼具體成果？
1. 成功上線並提升使用者體驗： 我們成功在 WordPress 官網上線了一個功能完整、互動流暢的 React Menu 元件，顯著提升了網站的現代感與品牌質感。
2. 實現模組化與品牌彈性，並帶來量化效益： 新的 Menu 元件實現了高度客製化，可根據不同品牌需求，快速調整顏色或樣式，而內容依然由營運團隊在熟悉的 WordPress 後台控制，完全不影響既有工作流程。
- 量化成果： 以往為一個新品牌網站部署客製化 Menu 需要約一週的開發時間，現在僅需約半天即可完成設定並上線，開發效率提升超過 90%。
3. 奠定未來混合架構的基礎： 最重要的成果是，我們成功建立了一套在 WordPress 中整合 React 開發的標準化流程，並兼容既有的純 JavaScript 專案。這為團隊未來的技術選型提供了極大的彈性，新功能可以根據複雜度與需求，自由選擇使用 React 或傳統方式開發，為公司前端技術的長期發展鋪平了道路。
Follow Up: 技術演進的挑戰與突破
在專案初期，我們確立了未來新功能將由 React 開發的路線。但是在第一次成功的架構整併之後充其量只能算是 能使用 ，在開發體驗上還是面臨了不好的體驗
初期的挑戰：CRA (Create-React-App) 的開發瓶頸
起初，我們使用官方的 CRA 來建立專案。但很快就遇到一個核心矛盾：WordPress 需要一個實體的檔案路徑來載入前端腳本，而 CRA 在開發模式下 (dev server) 並不產生實體檔案。我們不希望透過 eject 來暴露 Webpack 設定，因為這會導致後續 React 版本升級變得極其繁瑣。
為此，我們採用了一個變通方案：使用 Webpack 的 watch 模式，在每次程式碼變更時都重新打包出一個實體檔案。這個方法雖然可行，卻帶來了嚴重的效率問題：
-
開發反饋緩慢： 工程師修改程式碼後，必須手動重整瀏覽器才能看到變更。
-
打包時間過長： 隨著專案規模擴大，單次打包時間延長至 3 到 5 分鐘，嚴重拖慢了開發節奏。
最終的解決方案：Vite 帶來的革命性突破
Vite 的出現完美解決了這個困境。Vite 在開發模式下利用瀏覽器原生的 ES Modules 機制，這意味著：
WordPress 只需要載入 Vite 開發伺服器所提供的一個進入點檔案 (entry point)。接著，瀏覽器會根據 import 語句，透過動態載入 (dynamic import) 的方式，自動向 Vite 伺服器請求所需的模組。
這次從 CRA/Webpack 到 Vite 的遷移，極大地縮短了開發反饋時間。原本需要 3 至 5 分鐘 的等待，驟減至 10 秒左右，讓開發者得以專注於功能實現，而非漫長的等待，徹底改善了混合架構下的開發者體驗。