Skip to content

Conversation

@thomasheartman
Copy link
Contributor

@thomasheartman thomasheartman commented Dec 18, 2025

Adds a new createFetcher function that's exposed from useApiGetter.

Much like in #6541, I'm tired of having to manually redeclare the fetcher in each and every fetching hook, especially when it's always the exact same. As such, I'd like to create a shared standard.

... But that didn't work the last time. Presumably because existing uses weren't updated. I'd suggest that if we do this, then we should update all existing hooks so that the next time someone copies an existing fetch hook, they get the new fetcher instead of the old one.

Additionally, this createFetcher function has two improvements on the existing fetcher function:

  1. It takes the path and errorTarget as part of an object instead of positional parameters. Because both params are of type string, it's possible to mix up the order, so I think it makes sense to enforce the object here.
  2. Returns a function that returns the fetcher instead of returning the fetcher directly. All the places in the code where we use the fetcher function, we use it as () => fetcher(args). If it's always gonna be a function, why don't we just do that directly?

Follow-up work:

Replace all existing usages of const fetcher = and the other fetcher function, such that we can standardize this.

…ses)

Adds a new `createFetcher` function that's exposed from `useApiGetter`.

Much like in #6541, I'm tired of having to manually redeclare the fetcher in each and every fetching hook, especially when it's always the exact same. As such, I'd like to create a shared standard.

... But that didn't work the last time. Presumably because existing uses weren't updated. I'd suggest that if we do this, then we should update all existing hooks so that the next time someone copies an existing fetch hook, they get the new fetcher instead of the old one.

Additionally, this `createFetcher` function has two improvements on the existing `fetcher` function:
1. It takes the path and errorTarget as part of an object instead of positional parameters. Because both params are of type string, it's possible to mix up the order, so I think it makes sense to enforce the object here.
2. Returns a function that returns the fetcher instead of returning the fetcher directly. All the places in the code where we use the `fetcher` function, we use it as `() => fetcher(args)`. If it's always gonna be a function, why don't we just do that directly?
@vercel
Copy link

vercel bot commented Dec 18, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Review Updated (UTC)
unleash-docs Ignored Ignored Dec 18, 2025 0:37am

@github-actions
Copy link
Contributor

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@kwasniew kwasniew self-requested a review December 18, 2025 13:10
@github-project-automation github-project-automation bot moved this from New to Approved PRs in Issues and PRs Dec 18, 2025
@thomasheartman thomasheartman added the 👤 all-human No LLM tools used label Dec 18, 2025
@thomasheartman thomasheartman changed the title chore: add new standardized fetcher (and hopefully update all other uses) chore: add new standardized fetcher Dec 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

👤 all-human No LLM tools used

Projects

Status: Approved PRs

Development

Successfully merging this pull request may close these issues.

3 participants