feat(core): add locale parameter to client.fetch()#2977
feat(core): add locale parameter to client.fetch()#2977
Conversation
🦋 Changeset detectedLatest commit: 21067ed The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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 |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Bundle Size ReportComparing against baseline from No bundle size changes detected. |
jorgemoya
changed the title
jorgemoya
changed the title
Unlighthouse Performance Comparison — VercelComparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores. Summary ScoreAggregate score across all categories as reported by Unlighthouse.
Category Scores
Core Web Vitals
|
core/client/index.ts
Outdated
| requestHeaders['Accept-Language'] = locale; | ||
| // Use explicit locale when available (required inside unstable_cache where | ||
| // getLocale() would fail), fall back to next-intl for normal requests. | ||
| const resolvedLocale = locale ?? (await getLocale()); |
There was a problem hiding this comment.
Instead of passing in the resolved locale, could we do the same as above where we try/catch instead? Mostly asking here cause I am not sure we want to modify the client and I am trying to think of a way where we don't have to.
There was a problem hiding this comment.
Curious, why not modify the client?
There was a problem hiding this comment.
I just don't want to make a change that we don't have to. I would also say changing the client deserves it's own PR.
There was a problem hiding this comment.
So I played with this for a bit. Honestly, if we can't modify getChannelId or beforeRequest, what is the point of this PR? Keep in mind the interface adds an optional prop (a patch change imo).
Passing locale is the only way to have this available in unstable_cache and (eventually) use cache . It will be required for use cache. Since we will be passing locale to all queries within these cache contexts, I think it makes sense that we phase out getLocale entirely.
In fact, I would make locale mandatory, not optional. I have a PR for it already 😆 .
jorgemoya
force-pushed
the
LTRAC-226/locale-param
branch
from
009c3b5 to
8d4b254
Compare
jorgemoya
force-pushed
the
LTRAC-226/locale-param
branch
from
8d4b254 to
4428639
Compare
jorgemoya
force-pushed
the
LTRAC-226/locale-param
branch
from
4428639 to
d54fbd1
Compare
…equest Add optional locale parameter to client.fetch() for use in cached contexts. Wrap headers() call in beforeRequest with try/catch so it gracefully degrades inside unstable_cache. No changes to getChannelId or beforeRequest callback signatures. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jorgemoya
force-pushed
the
LTRAC-226/locale-param
branch
from
d54fbd1 to
21067ed
Compare
jorgemoya
changed the title
2 participants
Linear: LTRAC-226
What/Why?
Prerequisite for guest query caching with
unstable_cache.localeparameter toclient.fetch()for use in cached contexts wheregetLocale()is unavailableheaders()call inbeforeRequestwith try/catch so it gracefully degrades insideunstable_cacheNo changes to
getChannelIdorbeforeRequestcallback signatures.Second in a series of PRs splitting #2910 into smaller pieces. Depends on #2976.
Rollout/Rollback
Backwards compatible —
localeis optional and all existing call sites continue to work unchanged. Rollback is a simple revert.Testing
pnpm buildpassespnpm lintpasses🤖 Generated with Claude Code