-
Couldn't load subscription status.
- Fork 78
Refactor edge-config to prepare for Next.js support #882
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
Conversation
🦋 Changeset detectedLatest commit: d0c5005 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.
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
254f697 to
7829266
Compare
f4ab323 to
4a4582d
Compare
cb3bcd4 to
b7242b1
Compare
b7242b1 to
b864cf4
Compare
This change refactors the edge-config implementation in preparation for supporting Next.js specific builds. The key goal is to prepare the function interfaces where we intend to push the "use cache" boundaries for Next.js support so they are stringly typed. This is to help with optimizing a fast path for "use cache" that can avoid some serialization. One concession in this refactor is we need to move from a closure for the dev-only SWR edge config fetcher. The problem with this architecture is the function created in the closure won't be accessible to the the individual methods (like get) when they are behind a "use cache" because functions are not serializable. The technique now employed is a lazy created SWR deduper that is keyed off the connection string. This implementation does not consider garbage collection when clients are collected because 1) this is dev only and dev servers don't live very long and 2) this library does not typically require creating arbitrarily many clients since connections are typically stable for the lifetime of a deployment. We could use a FinalizationRegistry but that would limit support to runtimes that provide this and require some careful conditional requiring which just adds bundling complexity.
b864cf4 to
7a03863
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the next-legacy/.next folder checked into git on puprose?
This change refactors the edge-config implementation in preparation for supporting Next.js specific builds. The key goal is to prepare the function interfaces where we intend to push the "use cache" boundaries for Next.js support so they are stringly typed. This is to help with optimizing a fast path for "use cache" that can avoid some serialization.
One concession in this refactor is we need to move from a closure for the dev-only SWR edge config fetcher. The problem with this architecture is the function created in the closure won't be accessible to the the individual methods (like get) when they are behind a "use cache" because functions are not serializable. The technique now employed is a lazy created SWR deduper that is keyed off the connection string. This implementation does not consider garbage collection when clients are collected because 1) this is dev only and dev servers don't live very long and 2) this library does not typically require creating arbitrarily many clients since connections are typically stable for the lifetime of a deployment. We could use a FinalizationRegistry but that would limit support to runtimes that provide this and require some careful conditional requiring which just adds bundling complexity.