-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reevaluate window.fetch
each time HttpLink
uses it, if not configured using options.fetch
#8603
Conversation
Should help with a variety of strategies for instrumenting window.fetch, as discussed in issue #7832.
// #7832), or (if all else fails) the backupFetch function we saved when | ||
// this module was first evaluated. This last option protects against the | ||
// removal of window.fetch, which is unlikely but not impossible. | ||
const currentFetch = preferredFetch || maybe(() => fetch) || backupFetch; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: There should no runtime difference between maybe(() => fetch)
and backupFetch
, as backupFetch
is also maybe(() => fetch)
. In both cases the fetch
variable is resolved during execution time of the maybe lambda. What is reason for the backupFetch
fallback / the extra maybe(() => fetch)
?
What is the reason for backupFetch
here?
const currentFetch = preferredFetch || maybe(() => fetch) || backupFetch; | |
const currentFetch = preferredFetch || backupFetch; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bripkens A maybe(() => fetch)
expression executes the () => fetch
function immediately and returns the current result, or undefined
if the function threw an exception. It's the shortest way I've found to evaluate possibly-undefined global variables without obtaining a reference to the global object, and TypeScript infers the return type reliably.
To my way of thinking, this means the maybe(() => fetch)
expression we evaluate here could be different from backupFetch
, which was evaluated when the module was first imported (possibly long ago). I think this difference allows window.fetch
to be wrapped after the HttpLink
is created (the goal of #7832, IIUC). If we switch to preferredFetch || backupFetch
here, then we're stuck with one of those values for all time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, my bad, sorry @benjamn. I misunderstood what maybe
is doing! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A typeof fetch === "undefined"
check might be clearer, but that’s a nit. I don’t like this maybe()
function or relying on thrown ReferenceError
in a callback, but I can tolerate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🌮
This should help with a variety of strategies for instrumenting
window.fetch
, as discussed in issue #7832.