本文是深入淺出 ahooks 原始碼系列文章的第二篇,這個系列的目標主要有以下幾點:
- 加深對 React hooks 的理解。
- 學習如何抽象自定義 hooks。構建屬於自己的 React hooks 工具庫。
- 培養閱讀學習原始碼的習慣,工具庫是一個對原始碼閱讀不錯的選擇。
注:本系列對 ahooks 的原始碼解析是基於 v3.3.13
。自己 folk 了一份原始碼,主要是對原始碼做了一些解讀,可見 詳情。
系列文章:
本文來講下 ahooks 的核心 hook —— useRequest。
useRequest 簡介
根據官方文件的介紹,useRequest 是一個強大的非同步資料管理的 Hooks,React 專案中的網路請求場景使用 useRequest 就夠了。
useRequest 通過外掛式組織程式碼,核心程式碼極其簡單,並且可以很方便的擴充套件出更高階的功能。目前已有能力包括:
- 自動請求/手動請求
- 輪詢
- 防抖
- 節流
- 螢幕聚焦重新請求
- 錯誤重試
- loading delay
- SWR(stale-while-revalidate)
- 快取
這裡可以看到 useRequest 的功能是非常強大的,如果讓你來實現,你會如何實現?也可以從介紹中看到官方的答案——外掛化機制。
架構
如上圖所示,我把整個 useRequest 分成了幾個模組。
- 入口 useRequest。它負責的是初始化處理資料以及將結果返回。
- Fetch。是整個 useRequest 的核心程式碼,它處理了整個請求的生命週期。
- plugin。在 Fetch 中,會通過外掛化機制在不同的時機觸發不同的外掛方法,擴充 useRequest 的功能特性。
- utils 和 types.ts。提供工具方法以及型別定義。
useRequest 入口處理
先從入口檔案開始,packages/hooks/src/useRequest/src/useRequest.ts
。
function useRequest<TData, TParams extends any[]>(
service: Service<TData, TParams>,
options?: Options<TData, TParams>,
plugins?: Plugin<TData, TParams>[],
) {
return useRequestImplement<TData, TParams>(service, options, [
// 外掛列表,用來擴充功能,一般使用者不使用。文件中沒有看到暴露 API
...(plugins || []),
useDebouncePlugin,
useLoadingDelayPlugin,
usePollingPlugin,
useRefreshOnWindowFocusPlugin,
useThrottlePlugin,
useAutoRunPlugin,
useCachePlugin,
useRetryPlugin,
] as Plugin<TData, TParams>[]);
}
export default useRequest;
這裡第一(service 請求例項)第二個引數(配置選項),我們比較熟悉,第三個引數文件中沒有提及,其實就是外掛列表,使用者可以自定義外掛擴充功能。
可以看到返回了 useRequestImplement
方法。主要是對 Fetch 類進行例項化。
const update = useUpdate();
// 保證請求例項都不會發生改變
const fetchInstance = useCreation(() => {
// 目前只有 useAutoRunPlugin 這個 plugin 有這個方法
// 初始化狀態,返回 { loading: xxx },代表是否 loading
const initState = plugins.map((p) => p?.onInit?.(fetchOptions)).filter(Boolean);
// 返回請求例項
return new Fetch<TData, TParams>(
serviceRef,
fetchOptions,
// 可以 useRequestImplement 元件
update,
Object.assign({}, ...initState),
);
}, []);
fetchInstance.options = fetchOptions;
// run all plugins hooks
// 執行所有的 plugin,擴充能力,每個 plugin 中都返回的方法,可以在特定時機執行
fetchInstance.pluginImpls = plugins.map((p) => p(fetchInstance, fetchOptions));
例項化的時候,傳參依次為請求例項,options 選項,父元件的更新函式,初始狀態值。
這裡需要非常留意的一點是最後一行,它執行了所有的 plugins 外掛,傳入的是 fetchInstance 例項以及 options 選項,返回的結果賦值給 fetchInstance 例項的 pluginImpls
。
另外這個檔案做的就是將結果返回給開發者了,這點不細說。
Fetch 和 Plugins
接下來最核心的原始碼部分 —— Fetch 類。其程式碼不多,算是非常精簡,先簡化一下:
export default class Fetch<TData, TParams extends any[]> {
// 外掛執行後返回的方法列表
pluginImpls: PluginReturn<TData, TParams>[];
count: number = 0;
// 幾個重要的返回值
state: FetchState<TData, TParams> = {
loading: false,
params: undefined,
data: undefined,
error: undefined,
};
constructor(
// React.MutableRefObject —— useRef建立的型別,可以修改
public serviceRef: MutableRefObject<Service<TData, TParams>>,
public options: Options<TData, TParams>,
// 訂閱-更新函式
public subscribe: Subscribe,
// 初始值
public initState: Partial<FetchState<TData, TParams>> = {},
) {
this.state = {
...this.state,
loading: !options.manual, // 非手動,就loading
...initState,
};
}
// 更新狀態
setState(s: Partial<FetchState<TData, TParams>> = {}) {
this.state = {
...this.state,
...s,
};
this.subscribe();
}
// 執行外掛中的某個事件(event),rest 為引數傳入
runPluginHandler(event: keyof PluginReturn<TData, TParams>, ...rest: any[]) {
// 省略程式碼...
}
// 如果設定了 options.manual = true,則 useRequest 不會預設執行,需要通過 run 或者 runAsync 來觸發執行。
// runAsync 是一個返回 Promise 的非同步函式,如果使用 runAsync 來呼叫,則意味著你需要自己捕獲異常。
async runAsync(...params: TParams): Promise<TData> {
// 省略程式碼...
}
// run 是一個普通的同步函式,其內部也是呼叫了 runAsync 方法
run(...params: TParams) {
// 省略程式碼...
}
// 取消當前正在進行的請求
cancel() {
// 省略程式碼...
}
// 使用上一次的 params,重新呼叫 run
refresh() {
// 省略程式碼...
}
// 使用上一次的 params,重新呼叫 runAsync
refreshAsync() {
// 省略程式碼...
}
// 修改 data。引數可以為函式,也可以是一個值
mutate(data?: TData | ((oldData?: TData) => TData | undefined)) {
// 省略程式碼...
}
state 以及 setState
在 constructor 中,主要是進行了資料的初始化。其中維護的資料主要包含一下幾個重要的資料以及通過 setState 方法設定資料,設定完成通過 subscribe 呼叫通知 useRequestImplement 元件重新渲染,從而獲取最新值。
// 幾個重要的返回值
state: FetchState<TData, TParams> = {
loading: false,
params: undefined,
data: undefined,
error: undefined,
};
// 更新狀態
setState(s: Partial<FetchState<TData, TParams>> = {}) {
this.state = {
...this.state,
...s,
};
this.subscribe();
}
外掛化機制的實現
上文有提到所有的外掛執行的結果都賦值給 pluginImpls。它的型別定義如下:
export interface PluginReturn<TData, TParams extends any[]> {
onBefore?: (params: TParams) =>
| ({
stopNow?: boolean;
returnNow?: boolean;
} & Partial<FetchState<TData, TParams>>)
| void;
onRequest?: (
service: Service<TData, TParams>,
params: TParams,
) => {
servicePromise?: Promise<TData>;
};
onSuccess?: (data: TData, params: TParams) => void;
onError?: (e: Error, params: TParams) => void;
onFinally?: (params: TParams, data?: TData, e?: Error) => void;
onCancel?: () => void;
onMutate?: (data: TData) => void;
}
除了最後一個 onMutate 之外,可以看到返回的方法都是在一個請求的生命週期中的。一個請求從開始到結束,如下圖所示:
如果你比較仔細,你會發現基本所有的外掛功能都是在一個請求的一個或者多個階段中實現的,也就是說我們只需要在請求的相應階段,執行我們的外掛的邏輯,就能完成我們外掛的功能。
執行特定階段外掛方法的函式為 runPluginHandler,其 event 入參就是上面 PluginReturn key 值。
// 執行外掛中的某個事件(event),rest 為引數傳入
runPluginHandler(event: keyof PluginReturn<TData, TParams>, ...rest: any[]) {
// @ts-ignore
const r = this.pluginImpls.map((i) => i[event]?.(...rest)).filter(Boolean);
return Object.assign({}, ...r);
}
通過這樣的方式,Fetch 類的程式碼會變得非常的精簡,只需要完成整體流程的功能,所有額外的功能(比如重試、輪詢等等)都交給外掛去實現。這麼做的優點:
- 符合職責單一原則。一個 Plugin 只做一件事,相互之間不相關。整體的可維護性更高,並且擁有更好的可測試性。
- 符合深模組的軟體設計理念。其認為最好的模組提供了強大的功能,又有著簡單的介面。試想每個模組由一個長方形表示,如下圖,長方形的面積大小和模組實現的功能多少成比例。頂部邊代表模組的介面,邊的長度代表它的複雜度。最好的模組是深的:他們有很多功能隱藏在簡單的介面後。深模組是好的抽象,因為它只把自己內部的一小部分複雜度暴露給了使用者。
核心方法 —— runAsync
可以看到 runAsync 是執行請求的最核心方法,其他的方法比如 run/refresh/refreshAsync
最終都是呼叫該方法。
並且該方法中就可以看到整體請求的生命週期的處理。這跟上面外掛返回的方法設計是保持一致的。
請求前 —— onBefore
處理請求前的狀態,並執行 Plugins 返回的 onBefore 方法,並根據返回值執行相應的邏輯。比如,useCachePlugin 如果還存於新鮮時間內,則不用請求,返回 returnNow,這樣就會直接返回快取的資料。
this.count += 1;
// 主要為了 cancel 請求
const currentCount = this.count;
const {
stopNow = false,
returnNow = false,
...state
// 先執行每個外掛的前置函式
} = this.runPluginHandler('onBefore', params);
// stop request
if (stopNow) {
return new Promise(() => {});
}
this.setState({
// 開始 loading
loading: true,
// 請求引數
params,
...state,
});
// return now
// 立即返回,跟快取策略有關
if (returnNow) {
return Promise.resolve(state.data);
}
// onBefore - 請求之前觸發
// 假如有快取資料,則直接返回
this.options.onBefore?.(params);
進行請求——onRequest
這個階段只有 useCachePlugin 執行了 onRequest 方法,執行後返回 service Promise(有可能是快取的結果),從而達到快取 Promise 的效果。
// replace service
// 如果有 cache 的例項,則使用快取的例項
let { servicePromise } = this.runPluginHandler('onRequest', this.serviceRef.current, params);
if (!servicePromise) {
servicePromise = this.serviceRef.current(...params);
}
const res = await servicePromise;
useCachePlugin 返回的 onRequest 方法:
// 請求階段
onRequest: (service, args) => {
// 看 promise 有沒有快取
let servicePromise = cachePromise.getCachePromise(cacheKey);
// If has servicePromise, and is not trigger by self, then use it
// 如果有servicePromise,並且不是自己觸發的,那麼就使用它
if (servicePromise && servicePromise !== currentPromiseRef.current) {
return { servicePromise };
}
servicePromise = service(...args);
currentPromiseRef.current = servicePromise;
// 設定 promise 快取
cachePromise.setCachePromise(cacheKey, servicePromise);
return { servicePromise };
},
取消請求 —— onCancel
剛剛在請求開始前定義了 currentCount 變數,其實為了 cancel 請求。
this.count += 1;
// 主要為了 cancel 請求
const currentCount = this.count;
在請求過程中,開發者可以呼叫 Fetch 的 cancel 方法:
// 取消當前正在進行的請求
cancel() {
// 設定 + 1,在執行 runAsync 的時候,就會發現 currentCount !== this.count,從而達到取消請求的目的
this.count += 1;
this.setState({
loading: false,
});
// 執行 plugin 中所有的 onCancel 方法
this.runPluginHandler('onCancel');
}
這個時候,currentCount !== this.count,就會返回空資料。
// 假如不是同一個請求,則返回空的 promise
if (currentCount !== this.count) {
// prevent run.then when request is canceled
return new Promise(() => {});
}
最後結果處理——onSuccess/onError/onFinally
這部分也就比較簡單了,通過 try...catch...最後成功,就直接在 try 末尾加上 onSuccess 的邏輯,失敗在 catch 末尾加上 onError 的邏輯,兩者都加上 onFinally 的邏輯。
try {
const res = await servicePromise;
// 省略程式碼...
this.options.onSuccess?.(res, params);
// plugin 中 onSuccess 事件
this.runPluginHandler('onSuccess', res, params);
// service 執行完成時觸發
this.options.onFinally?.(params, res, undefined);
if (currentCount === this.count) {
// plugin 中 onFinally 事件
this.runPluginHandler('onFinally', params, res, undefined);
}
return res;
// 捕獲報錯
} catch (error) {
// 省略程式碼...
// service reject 時觸發
this.options.onError?.(error, params);
// 執行 plugin 中的 onError 事件
this.runPluginHandler('onError', error, params);
// service 執行完成時觸發
this.options.onFinally?.(params, undefined, error);
if (currentCount === this.count) {
// plugin 中 onFinally 事件
this.runPluginHandler('onFinally', params, undefined, error);
}
// 丟擲錯誤。
// 讓外部捕獲感知錯誤
throw error;
}
思考與總結
useRequest 是 ahooks 最核心的功能之一,它的功能非常豐富,但核心程式碼(Fetch 類)相對簡單,這得益於它的外掛化機制,把特定功能交給特定的外掛去實現,自己只負責主流程的設計,並暴露相應的執行時機即可。
這對於我們平時的元件/hook 封裝很有幫助,我們對一個複雜功能的抽象,可以儘可能保證對外介面簡單。內部實現需要遵循單一職責的原則,通過類似外掛化的機制,細化拆分元件,從而提升元件可維護性、可測試性。
參考
本文由mdnice多平臺釋出