前端頁面組件怎麼拆提示詞（組件樹設計、狀態放在哪一層、Props 接口、可複用組件識別）
開始做一個複雜頁面（後台詳情頁、多步驟表單、帶篩選的列表），不知道怎麼拆組件、狀態該放在哪裏時用：給出頁面描述或原型，AI 先畫組件樹，再決定每份狀態的歸屬和數據流向，定義每個組件的 Props，並指出哪些組件值得抽成通用組件。
通用大模型 對話模型通用
你是一名擅長組件設計的前端架構師。請在寫代碼之前，先幫我設計頁面的組件結構。 - 框架：[框架]（例：React、Vue 3） - 頁面描述（區塊、交互、數據來源；有原型可描述原型）： [頁面描述] - 已有的通用組件庫：[已有組件庫]（例：Ant Design + 團隊內部組件） - 狀態管理方案：[狀態管理]（例：服務端數據用 TanStack Query，全局狀態用 Zustand） 請輸出： 1. 組件樹：用縮進列表表示，每個組件寫一句職責說明。拆分依據：單一職責、重複出現的結構、獨立變化的區域、需要單獨測試的邏輯。避免拆得過細（只被用一次且不足十行的部分不必單獨成為組件）。 2. 狀態清單：列出頁面上所有的狀態，逐條決定它屬於哪一類、放在哪裏： - 服務端數據（列表、詳情）：交給數據請求層緩存，不要複製一份到本地狀態； - 地址列狀態（篩選條件、頁碼、當前標籤頁）：放在查詢參數裏，刷新與分享時保持； - 表單狀態：放在表單組件內部或表單庫中； - 介面狀態（彈窗開關、展開收起）：放在離使用它最近的組件； - 真正的全局狀態（當前用戶、主題）：才放進全局狀態管理。 對每份狀態說明：哪些組件讀取、哪些組件修改、為什麼放在這一層。 3. 數據流：畫出關鍵交互（例如修改篩選條件 → 列表刷新）中數據和事件的流向，檢查是否存在層層傳遞過深的屬性，給出解決方式（組合、上下文、調整狀態位置）。 4. Props 接口：為主要組件寫出 Props 類型定義（名稱、類型、是否必填、說明），以及組件對外觸發的事件。 5. 可複用識別：哪些組件可以抽成通用組件放進組件庫，哪些屬於業務組件；不要為了「可能複用」過早抽象。 6. 目錄結構建議（components、features、hooks 或 composables 的劃分）。
高亮處換成你自己的內容：[框架]、[頁面描述]、[已有組件庫]、[狀態管理]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[頁面描述] 按區塊寫清楚：每塊顯示什麼、有哪些操作、操作後會影響哪些區塊。例如「頂部篩選欄修改後，列表刷新並回到第一頁；點擊某行在右側抽屜顯示詳情，抽屜中修改後列表對應行更新」。
常見坑：
- 把接口返回的數據複製到全局狀態裏再手動同步，數據不一致的問題層出不窮。服務端數據交給數據請求庫管理。
- 篩選條件和頁碼放在組件內部狀態，刷新頁面就丟失，也沒法把連結分享給同事。
- 為了「以後可能複用」，把業務組件抽象成一堆配置項，最後誰都不敢改。先在業務裏用起來，出現第二、第三次重複時再抽象。
追問技巧：設計確認後追問「按這個設計生成組件骨架代碼，每個組件只寫 Props 類型和結構，不寫樣式」，再逐個填充。
示例輸出
示例，僅供參考（訂單列表頁，節選）
OrderListPage 頁面容器：讀取地址列查詢參數，組合各區塊
├─ OrderFilters 篩選欄：修改後更新查詢參數並重置頁碼
├─ BatchActionBar 批量操作：僅在有選中項時顯示
├─ OrderTable 表格：展示數據、行選擇
│ └─ OrderStatusTag 狀態標籤（通用，可放入組件庫）
├─ Pagination 分頁：讀寫查詢參數中的頁碼
└─ OrderDetailDrawer 詳情抽屜：根據查詢參數中的訂單編號加載詳情| 狀態 | 類型 | 位置 | 讀取者 | 修改者 |
|---|---|---|---|---|
| 篩選條件、頁碼 | 地址列狀態 | 查詢參數 | 頁面容器、列表請求 | 篩選欄、分頁 |
| 訂單列表數據 | 服務端數據 | 數據請求緩存 | 表格 | 批量操作成功後使緩存失效 |
| 選中的行 | 介面狀態 | 頁面容器 | 表格、批量操作欄 | 表格 |
| 當前查看的訂單編號 | 地址列狀態 | 查詢參數 | 詳情抽屜 | 表格行點擊 |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～