Asynchronous useItemStartListener callback

[mwdiaz]

We have some asynchronous logic that we'd like to run in order to determine whether there's a specific scenario where we'd want to proactively cancel an upload. While it would certainly be possible to put this logic in a useRequestPreSend hook, the current structure of our state management is such that it would be vastly more simple (and preferable, since it wouldn't require refactoring anything) if this specific check could be done in useItemStartListener instead of useRequestPreSend.

I'm curious if there's a technical reason why this wouldn't be possible, especially since useBatchStartListener supports an asynchronous callback. Thanks!

[yoavniran]

Hey @mwdiaz
useItemStartListener is asynchronous and does support canceling as its doc page explains:

Did you try and find any issue?

[mwdiaz]

Ah, so perhaps it's just that the types are incorrect? ItemCancellableEventHook is typed as a CancellableHook which accepts a callback parameter that doesn't include a promise as a valid return value.

type CancellableHook<T> = (cb: (obj: T, options: CreateOptions) => boolean | void, id?: string) => void;

vs. useRequestPreSend, which specifically allows the callback to return Promise<PreSendResponse | boolean>:

export const useRequestPreSend: (cb: (data: PreSendData) =>
    PreSendResponse | boolean | Promise<PreSendResponse | boolean> | Promise<boolean>) => void;

If it is just a types issue, I can work around with a @ts-expect-error directive until it's fixed upstream, but I hadn't actually tried yet.

[yoavniran]

Oh, ok.
yes, indeed a fairly big oversight since all cancellable events are asynchronous in nature and therefore, their hook-equivalents as well.
Will fix.
Thanks!

[yoavniran]

opened #643 to fix

[yoavniran]

@mwdiaz v1.7.1 now available with the fix.

[mwdiaz]

Thanks! I just checked and the TypeScript errors are gone 👍