前言

@tanstack/vue-query 以其強(qiáng)大的緩存和狀態(tài)管理能力，極大地簡化了數(shù)據(jù)獲取邏輯。然而，當(dāng)它與 Vue3 復(fù)雜的響應(yīng)式系統(tǒng)結(jié)合時(shí)，如果不深入理解其工作原理，很容易陷入“重復(fù)請求”的陷阱。在最近一次開發(fā)中就遇到了這個(gè)問題，本文展現(xiàn)了從一個(gè)頁面加載時(shí)觸發(fā)4次重復(fù)API請求，到2次，并最終實(shí)現(xiàn)1次請求的解決過程，以免下次再掉進(jìn)這個(gè)坑里。

問題的初現(xiàn)：一個(gè)“勤奮過頭”的列表頁

我們有一個(gè)需求：開發(fā)一個(gè)包含Tabs切換、獨(dú)立篩選條件和分頁功能的數(shù)據(jù)列表頁面。技術(shù)棧是 Vue 3 (Composition API) 和 @tanstack/vue-query，并使用了一個(gè)名為 <cec-page-wrapper> 的高度封裝的表格組件。

頁面完成后，一切似乎工作正常，但打開瀏覽器網(wǎng)絡(luò)面板，我們驚恐地發(fā)現(xiàn)，每次加載頁面，獲取列表數(shù)據(jù)的API transactionList 竟然被調(diào)用了4次！

發(fā)生了什么？？？

第一階段：從4次請求到2次 —— 尋找“幽靈觸發(fā)者”

我們首先審查了代碼，試圖找出所有可能調(diào)用 loadData (即 useQuery 的 refetch) 的地方。

當(dāng)時(shí)的 script setup 核心邏輯:

// ...
const activeTab = ref('PROVIDER');
const tablePage = ref({ currentPage: 1, ... });
const filterParams = ref({ ... });

const { isFetching, data: tableData, refetch: loadData } = useQuery({
  queryKey: ['transactionList', activeTab, tablePage, filterParams],
  queryFn: async () => { /* ... */ },
});

watch(activeTab, () => {
  tablePage.value.currentPage = 1;
  loadData(); // Tab 切換時(shí)加載
});

onMounted(() => {
  getBusinessNodesList(); // 獲取下拉框選項(xiàng)
  loadData(); // 掛載時(shí)加載
});

// 模板中，分頁組件 @change 事件也調(diào)用了 loadData

經(jīng)過仔細(xì)的日志打印和分析，我們定位到了這4次請求的來源：

1. 第一次 (useQuery 自動觸發(fā)): useQuery 在組件掛載時(shí)，會使用初始的 queryKey 自動發(fā)起一次請求。
2. 第二次 (onMounted 手動觸發(fā)): onMounted 鉤子中明確調(diào)用了 loadData()。
3. 第三次 (watch(activeTab)): activeTab 在初始化時(shí)，watch 監(jiān)聽器被觸發(fā)，調(diào)用了 loadData()。
4. 第四次 (PageWrapper 初始化): 封裝的 <cec-page-wrapper> 組件在內(nèi)部的分頁器初始化時(shí)，會 emit 一次 @load-data 事件，再次調(diào)用了 loadData()。

根源: 我們犯了一個(gè)典型的錯(cuò)誤——不信任框架，手動控制一切。我們試圖在每個(gè)可能的地方都調(diào)用 loadData，卻沒有意識到 useQuery 的響應(yīng)式 queryKey 已經(jīng)為我們處理了大部分情況，從而導(dǎo)致了多次重復(fù)的調(diào)用。

解決方案 (V1): 我們決定信任 useQuery，并精確控制請求時(shí)機(jī)。

1. 禁用自動請求: 給 useQuery 添加 enabled: false 選項(xiàng)。
2. 添加 isMounted 守衛(wèi): 創(chuàng)建一個(gè) isMounted 標(biāo)志位，阻止分頁組件在 onMounted 完成前的初始化調(diào)用。
3. 統(tǒng)一入口: 在 onMounted 的最后，手動調(diào)用 refetch() 來發(fā)起唯一的第一次請求。

// ...
const { ..., refetch } = useQuery({ ..., enabled: false });
const isMounted = ref(false);

const handlePageChange = (pageInfo) => {
  if (!isMounted.value) return; // 守衛(wèi)
  // ...
  refetch();
};

onMounted(async () => {
  await getBusinessNodesList();
  searchParams.value = cloneDeep(activeFilters.value);
  await refetch(); // 手動觸發(fā)
  isMounted.value = true;
});

結(jié)果: 這個(gè)修改非常有效！請求次數(shù)從4次銳減到了2次。但為什么還有2次？

第二階段：從2次請求到1次 —— 深入響應(yīng)式依賴

我們再次審查代碼，發(fā)現(xiàn) onMounted 中手動調(diào)用的 refetch() 仍然是多余的。盡管我們禁用了它，但 watch 和其他地方的邏輯仍然可能在初始化階段觸發(fā) refetch。

更深層次的根源: useQuery 的 queryKey 依賴于 searchParams。而 searchParams 的初始值是通過 cloneDeep(activeFilters.value) 計(jì)算得來的。activeFilters 又依賴 filterParams 和 activeTab。整個(gè)依賴鏈條是這樣的：

activeTab -> activeFilters -> searchParams -> queryKey

在組件掛載的微任務(wù)隊(duì)列中，這些響應(yīng)式數(shù)據(jù)的初始化和 watch 的觸發(fā)順序存在我們未預(yù)料到的交互，導(dǎo)致了 searchParams 在短時(shí)間內(nèi)被更新了兩次。

最終的解決方案 (V2): 我們意識到，問題的關(guān)鍵不是去“堵”住所有的觸發(fā)點(diǎn)，而是讓觸發(fā)機(jī)制變得單一和可預(yù)測。

1. 回歸 useQuery 的自動行為: 我們移除 enabled: false，我們相信并利用它的自動加載能力。
2. 確保初始 queryKey 的穩(wěn)定性: 最重要的修改——在定義 searchParams 時(shí)，就立即用穩(wěn)定的初始值 cloneDeep(activeFilters.value) 對其進(jìn)行初始化。
3. 移除所有手動的首次加載調(diào)用: 刪除 onMounted 中的 refetch() 或 search() 調(diào)用。

最終只有1次請求的代碼:

// 1. 狀態(tài)定義：searchParams 在定義時(shí)就擁有了正確的初始值
const activeTab = ref('PROVIDER');
const activeFilters = computed(() => filterParams[activeTab.value]);
const searchParams = ref(cloneDeep(activeFilters.value)); // 關(guān)鍵！

// 2. useQuery: 默認(rèn)啟用，它會在掛載時(shí)自動使用上面的 searchParams 發(fā)起請求
const { isFetching, data: tableData, refetch } = useQuery({
  queryKey: computed(() => ['transactionList', activeTab.value, ..., searchParams.value]),
  queryFn: async () => { /* ... */ },
});

// 3. 事件處理：只負(fù)責(zé)更新狀態(tài)，不直接調(diào)用 refetch
const search = () => {
  activeTableState.value.currentPage = 1;
  // 只更新 searchParams，useQuery 會自動響應(yīng) queryKey 的變化
  searchParams.value = cloneDeep(activeFilters.value); 
};

// 4. 生命周期：只做與列表數(shù)據(jù)無關(guān)的初始化
onMounted(() => {
  getBusinessNodesList();
  // 不需要任何 loadData 或 refetch 調(diào)用！
});

為什么這次能成功？

• 單一入口: useQuery 的 queryFn 現(xiàn)在是獲取數(shù)據(jù)的唯一入口。
• 單一觸發(fā)器: queryKey 的變化是觸發(fā) queryFn 的唯一方式。
• 可預(yù)測的狀態(tài): 在組件掛載時(shí)，searchParams 的初始值是確定的、穩(wěn)定的。useQuery 使用這個(gè)穩(wěn)定的 key 發(fā)起了唯一一次初始請求。
• 清晰的職責(zé):
  • 用戶的輸入只改變 activeFilters (UI狀態(tài))。
  • 用戶的搜索動作 (@search, @change, reset) 才去調(diào)用 search()，將 UI 狀態(tài)“提交”給 searchParams (查詢狀態(tài))。
  • useQuery 忠實(shí)地響應(yīng) searchParams 的變化。

結(jié)論

還是要深入了解 Vue 3 響應(yīng)式系統(tǒng)和 vue-query 聲明式數(shù)據(jù)獲取的理念啊～～～不然有AI也要卡殼子，耽誤牛馬下班～

• 不要與框架對抗: 相信 useQuery 的響應(yīng)式能力，避免在 onMounted 或 watch 中進(jìn)行手動的、命令式的 refetch 調(diào)用。
• 分離狀態(tài): 將用于UI雙向綁定的狀態(tài)（如 activeFilters）和用于觸發(fā)數(shù)據(jù)請求的狀態(tài)（如 searchParams）分離開，可以有效切斷意外的響應(yīng)式連鎖反應(yīng)。
• 穩(wěn)定 queryKey: 確保 useQuery 在首次自動執(zhí)行時(shí)，其 queryKey 所依賴的所有數(shù)據(jù)都已處于穩(wěn)定和正確的初始狀態(tài)。

通過遵循這些原則，我們可以構(gòu)建出既簡潔又健壯的數(shù)據(jù)獲取邏輯，真正發(fā)揮出現(xiàn)代前端框架的威力。

到此這篇關(guān)于Vue3 + vue-query 的重復(fù)請求問題解決 的文章就介紹到這了,更多相關(guān)vue-query 重復(fù)請求內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論