feat(openapi-fetch): add onError handler to middleware

[luchsamapparat]

Changes

This PR adds an optional onError handler to the middleware feature. It allows handling errors thrown by fetch in three ways:

• return nothing which means that the error will still be thrown, but useful for logging,

  client.use({
    onError({ error }) {
      console.error(error);
      return;
    },
  });

• return another instance of Error to be thrown instead,

  client.use({
    onError({ error }) {
      return new Error("Oops", { cause: error });
    },
  });

• or return a new instance of Response which means that the fetch call will proceed as successful.

  client.use({
    onError({ error }) {
      return Response.json({ message: 'nothing to see' });
    },
  });

How to Review

See additional tests in packages/openapi-fetch/test/middleware/middleware.test.ts

If multiple middlewares with onError are configured, they are executed in reverse order like onResponse. I'm not sure if that's intuitive or not. 🤔

Checklist

• Unit tests updated
• [-] docs/ updated (if necessary) 👈 I'll amend the commit with docs if this feature request is accepted
• [-] pnpm run update:examples run (only applicable for openapi-typescript)

[changeset-bot]

🦋 Changeset detected

Latest commit: 4e32f31

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
openapi-fetch	Patch
openapi-react-query	Patch
swr-openapi	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[luchsamapparat]

Before middleware was added to openapi-fetch, I created a wrapper for fetch to log requests, responses and failed requests (e.g. network errors, etc.). When migrating to the middleware approach, I wasn't able to implement logging for failed requests which is why I added that feature in this PR.

I could of course keep my fetch wrapper for handling failed requests, but that would spread the logging logic across two places.

[drwpow]

I really like this, thank you! I agree with your implementation of not throwing an error on any non-OK response, but just handling the instances where fetch() itself throws.

Tests look great, too!

Only things we need to merge this PR:

• Update the documentation to mention this method (since docs update on merge). You don’t have to write much; just anything that mentions it exists, basically.
• Add a patch changeset with npx changeset in the root (in 0.x, we’re using minor versions to indicate breaking changes, and this is not a breaking change)

[luchsamapparat]

I updated the docs. Feel free to make suggestions if something is missing or could be explained better somehow (or weird phrasing as I'm not a native speaker 😄).

Just to be sure: since this is a new feature, shouldn't it be a minor changeset instead of a patch?

[drwpow]

I updated the docs. Feel free to make suggestions if something is missing or could be explained better somehow (or weird phrasing as I'm not a native speaker 😄).

Just to be sure: since this is a new feature, shouldn't it be a minor changeset instead of a patch?

Thanks so much! This all looks great. But yes this should be a patch changeset ONLY because it’s 0.x. You’re correct—1.0.0 and greater, this would be a minor. But before 1.0.0, we reserve minor versions for breaking changes (many other libraries do it as a convention). So patches get bugfixes AND features.

Once this has a patch changeset added, happy to approve and merge 🙂

[zsugabubus]

Is it really necessary to reinvent try...catch? Why return X sometimes behaves like return X but other times like throw X? Is it still JavaScript or a totally different language?

[luchsamapparat]

I updated the docs. Feel free to make suggestions if something is missing or could be explained better somehow (or weird phrasing as I'm not a native speaker 😄).
Just to be sure: since this is a new feature, shouldn't it be a minor changeset instead of a patch?

Thanks so much! This all looks great. But yes this should be a patch changeset ONLY because it’s 0.x. You’re correct—1.0.0 and greater, this would be a minor. But before 1.0.0, we reserve minor versions for breaking changes (many other libraries do it as a convention). So patches get bugfixes AND features.

Once this has a patch changeset added, happy to approve and merge 🙂

I amended the commit with a patch changeset 👍

[drwpow]

Awesome work. Thank you!

[drwpow]

@zsugabubus I’m not sure what you’re asking. If you have a feature request or bug to report, please open an issue using the appropriate template