Skip to content

feat(openapi-fetch): add transform options for response data handling #2253

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Newbie012
Copy link

Changes

This PR adds the option to transform the response data. This is useful when you want to deserialize the returned output. This is not achievable via middleware.

How to Review

I would personally start from reading the test. The PR is quite minimal.

Checklist

  • Unit tests updated
  • docs/ updated (if necessary)
  • pnpm run update:examples run (only applicable for openapi-typescript)

@Newbie012 Newbie012 requested a review from a team as a code owner April 13, 2025 23:23
@Newbie012 Newbie012 requested a review from duncanbeevers April 13, 2025 23:23
Copy link

netlify bot commented Apr 13, 2025

👷 Deploy request for openapi-ts pending review.

Visit the deploys page to approve it

Name Link
🔨 Latest commit 9321c34

Copy link

changeset-bot bot commented Apr 13, 2025

🦋 Changeset detected

Latest commit: 9321c34

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

Copy link
Contributor

@drwpow drwpow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for submitting! The “this is not achievable in middleware” callout is a great observation, and would also like to fix. Thank you for the proposal!

But since this is a bigger change, I’d like to pause on this and back up to a proposal first. Please Open an issue that has a more in-depth proposal for how you’d like to fix this flaw in middleware, and discuss some tradeoffs.

Adding another API that is 90% similar to what the middleware is doing now, but with some minor differences, isn’t a cohesive API design because it gives users multiple ways to accomplish the same goals.

Instead, I’d love to see a proposal that goes more in depth on:

  • How is the current middleware API sufficient?
  • What serialization/deserialization is needed?
  • What are some alternatives—how might the middleware API be modified to accomplish these goals?

Thinking through this more holistically will benefit more users, and end up as a stronger design. To that end, would love to align more on the plan so we fix the real problems you’re pointing out, but in a way that improves everyones’ experience.

@drwpow drwpow self-assigned this May 3, 2025
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

Successfully merging this pull request may close these issues.

2 participants