重構多步驟表單流程：從 Pinia 管理到局部狀態綁定的實踐

將依賴 Pinia 的多步驟表單重構，提升程式碼的可讀性與職責清晰度。

在開發互動式網頁應用程式時，我們經常會遇到需要分步執行的複雜表單（例如：建立商店、安裝流程等）。這類功能通常包含多個步驟，每個步驟的資料可能互相依賴，且允許使用者暫時儲存或中途跳離。

在面對這類需求時，我們應該如何設計狀態與資料流，才能在擴充與維護之間取得平衡呢？

本文分享我遇到的情況及作法。

原始架構回顧與痛點

在最初的開發中，原作者採用了集中式的狀態管理。主要結構是一個主視窗檔案（x.vue），並搭配一個主 Store（x.store.js）以及五個對應步驟的 Store（step1~5.store.js）。

原作者的處理方式與設計邏輯

集中式初始化與賦值：初始化時，呼叫 API 取得所有表單的初始值並存入 主 Store 。接著透過 watch 監聽 currentStep（當前步驟) 的變化。當使用者切換步驟時，會自動將 主 Store 裡的狀態，直接賦值給對應 子步驟的 Store（ 不透過內部 action 更新 ）。
跨步驟資料傳遞：若 Step 1 填寫的資料需要帶入 Step 2，則預先在 step2.store.js 中宣告承接欄位，並在 watch 切換步驟時，將資料從 Step 1 的狀態傳遞過去。
流程控制：使用陣列記錄步驟順序，並根據陣列的 Index 來判斷目前處於哪個步驟。
業務邏輯處理：各步驟的 驗證規則 與提交都封裝在個別的 Store 裡面；圖片上傳則是在使用者操作當下直接呼叫 API。

痛點分析

雖然這種方式將各步驟的邏輯模組化，但隨著步驟增加，全域狀態與監聽器（watch）的交互會變得相當複雜。

當我們需要追蹤特定資料的變動來源時，容易產生過高的認知負擔，且隱式的狀態賦值容易造成非預期的副作用。

重構後的架構與設計

為了讓架構更輕量且易於追蹤，我捨棄了不需要全域共享的 Store 機制，改為在主檔案中統一管理狀態，並透過 v-model 將資料雙向綁定至各個子組件。重構後的核心程式碼結構

<template>
  <Step1
    v-if="currentStep === 'S1'"
    ref="componentRef"
    :initial-data="getInitialData()"
    v-model="step1Data"
  />
  <Step2
    v-if="currentStep === 'S2'"
    ref="componentRef"
    :initial-data="getInitialData()"
    v-model="step2Data"
  />
</template>

import { ref, reactive, computed } from 'vue';

// 宣告所有表單所需資料
const componentRef = ref(null);
const xData = reactive({}); 
const step1Data = reactive({});
const step2Data = reactive({});

// 根據後端資料或初始狀態計算出流程
const stepFlow = computed(() => {
  // 處理流程判斷邏輯
});

// 整理每個表單所需的初始值
const getInitialData = (stepName) => {
  // 回傳初始化資料
};

const prevStep = () => { /* 切換至上一步 */ };
const nextStep = async () => {
  if (componentRef.value?.submitForm) {
    await componentRef.value.submitForm();
  }
};

架構解析：重構亮點與狀態機的關聯

狀態機（Finite State Machine, FSM）概念的引入
在重構後的架構中，我 捨棄了依賴陣列索引（Index） 的控制方式，改為使用與後端配合的 字串標識（如 S1, S2 等） 來標示步驟。這種做法與有限狀態機（FSM）的概念不謀而合：

明確的狀態節點：系統只會處於明確定義的節點（State）中。例如 S1、S2。
受控的轉換：流程控制只允許合法的轉換發生（例如從 S1 進入 S2）。這避免了因陣列順序變動或索引計算錯誤而產生的非預期狀態，大幅降低了除錯的難度。

移除不必要的全域狀態管理
當資料不需要跨頁面共享時，引入全域 Store 反而會增加耦合度。改用 reactive 與 v-model 後，資料流向變得非常明確，開發者能直覺地掌握哪個變數在何處被修改。
職責分離與單一職責原則
我刻意避免在主檔案 x.vue 中處理各步驟的細節邏輯。 主檔案只專注於流程控制（下一步、上一步、暫存狀態） ，而表單的 內部驗證與細部處理則由各子組件負責。子組件統一向外暴露（expose）submitForm 方法，讓父層只需呼叫該方法即可觸發驗證或請求，無須判斷當前步驟的型態。
優化圖片上傳體驗
在原架構中，圖片會在操作當下直接上傳，如果使用者中途取消或未完成流程，可能會產生未被使用的孤立檔案。新做法改為在最終按下「送出」時統一上傳，確保資料的完整性，也省去處理取消上傳（abort）的額外負擔。

結語

這次重構的目的是為了讓程式碼更具可讀性與可維護性。
透過將局部邏輯交還給各個步驟組件、統一表單提交行為，並結合狀態機的設計思維，我成功降低了多步驟表單的維護成本。
在此記錄自己的處理方法，希望這個實踐能為未來的我及觀看者處理類似複雜表單時提供一些靈感！