Skip to content
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

Interceptors aren't chained #371

Open
veloware opened this issue Jun 20, 2022 · 8 comments
Open

Interceptors aren't chained #371

veloware opened this issue Jun 20, 2022 · 8 comments

Comments

@veloware
Copy link

veloware commented Jun 20, 2022

Describe the bug
Interceptors aren't chained, in that global interceptors at the provider level, are overridden if an interceptor is introduced at the useFetch() hook level

There does seem to be a work around, at the hook level -

request: async ({ options }) => {
        globalOptions.interceptors?.request?.({ options });
        ...

However, that could easily be forgotten on a case per case basis, and is no different that just housing the 'global' interceptor code in a standard function, and just invoking that, which defeats the purpose of a global 'interceptor'

⚠️ Make a Codesandbox ⚠️
Please do this to easily reproduce the bug.

To Reproduce

  • introduce a request interceptor at the provider level, to say, add a request correlation-id header
  • introduce a request interceptor at the hook usage level, to say, add another request header
  • When running the hook, the provider level request interceptor does not run.

Expected behavior
Both should run, probably the global first, then the more specific interceptor at the hook level second

@krishnasaga
Copy link
Contributor

@veloware I came across the same problem and solved very similar approach as you mentioned.
I think you can create a pull request with this change so it can be reviewed ?

@alon-green
Copy link

@veloware how can you access the globalOptions?

@veloware
Copy link
Author

veloware commented Dec 6, 2022

@alon-green there is a 2nd arg you can pass to useFetch as a callback, its the first arg of that callback, e.g. -

useFetch(url, (globalOptions) => ({
   ...
    interceptors: {
      request: async ({ options }) => {
        globalOptions.interceptors?.request?.({ options });
        ...

@alon-green
Copy link

@veloware thanks for the answer, but I already pass options in the useFetch, in nested hook, I need access to the option of the provider

@veloware
Copy link
Author

veloware commented Dec 6, 2022

in the case above though, the globalOptions is not passed to the callback, it's provided by the callback. Those will be the options that were set at the <Provider options={xxx}> level

@alon-green
Copy link

But I can't access the provider, can't I take it from the context or something?

@krishnasaga
Copy link
Contributor

@veloware Let me try to create a CodesandBox of this

@krishnasaga
Copy link
Contributor

@alon-green here is the CodeSandbox https://codesandbox.io/s/usefetch-use-http-todo-list-app-managed-state-forked-x1ru0p?file=/src/index.js. If this code sandbox is clarifying solution to your problem or still, it is a problem. now you can modify the code sandbox to help us to understand better. hopefully we can solve it.

@veloware

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants