Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi! This is a proof of concept PR for a
beforeReturnhook (discussed in #696) that is less strict about return type thanafterResponse.Important note: this PR at least needs some work to be done in terms of types, although basic usage is fully covered.
Why ❔ :
afterResponsebeforeReturnopposed toafterResponseKey usage points 🔑 :
beforeReturncallback is what gets returned by kybeforeReturnis called at the end of hook life-cyclebeforeReturnis not called if request is erroneous andthrowHttpErrorsis not offbeforeReturnallows any return from callbackbeforeReturncallbacks ({ beforeReturn: [cb1, cb2, ... ] }) each subsequent callback is invoked with the result of the previous callback invocationPotential workflow ➡️ :
As I see it,
afterResponsecan be used to perform additional network operations based on a response (combine multiple requests together, simply send additional requests, or even some exotic retry logic that needs some customized behavior); whereasbeforeReturncan be used to ensure consistency of the returned value. Basically,afterResponseis for anything that actually alters the Response,beforeReturnis to derive data from ResponseKey developing points 🖊️ :
beforeReturn, it is required to infer return type from lastbeforeReturncbextendand theoptionsargument for ky methods require to consider type collisions among them andbeforeReturnexit valueMisc:
While TypeScript-related code is kind of unattractive, it is still the required minimum to derive return type from
Options, in a sense that anything else inOptionsthat affects the returned value would need the same approach to reflect it through typesPR progress state 🚧 :
Waiting for comments whether the idea is welcomed
Thanks for taking time to review my PR!!