feat: Introduce "source" concept #626
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The following introduces a "source" concept that can be used to query different types of resources. The long-term vision here is: - `SanityInstance` should no longer be an inherited tree structure. This will rather be a single object which contains global information (e.g. token). There will be no re-use of any state across `SanityInstance`. - All hooks/functions which works on documents will also accept a `source` parameter. This is a single parameter (instead of the `projectId`/`dataset`) tuple that can easily be passed around. If you're making higher-order helpers you just need to accept a single source object. - There are top-level functions which constructs these `source` objects. In the future these objects will also contain type information. These should also be owned by `@sanity/client`. In this PR we're mapping it to the existing experimental resource API, but the intention is for `@sanity/client` to provide a proper source-based API which we're re-exporting/using here in SDK. - We'll introduce a new "default source" context as well. This is _outside_ of the `SanityInstance` so that you can change it. - There will be no special support for placing multiple sources in the context. The user can always define their own context if they want to have access to multiple `source` objects. This gives them more flexibility in how to structure their applications. - If you have fully static data sources you can always hard-code them in single file: `export const PRODUCTS = datasetSource(projectId, "datasets")`.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The following introduces a "source" concept that can be used to query different types of resources. The long-term vision here goes much broader:
SanityInstanceshould no longer be an inherited tree structure. This will rather be a single object which contains global information (e.g. token). There will be no re-use of any state acrossSanityInstance.sourceparameter. This is a single parameter (instead of theprojectId/datasettuple) that can easily be passed around. If you're making higher-order helpers you just need to accept a single source object.sourceobjects. In the future these objects will also contain type information. These should also be owned by@sanity/client. In this PR we're mapping it to the existing experimental resource API, but the intention is for@sanity/clientto provide a proper source-based API which we're re-exporting/using here in SDK.SanityInstanceso that you can change it.sourceobjects. This gives them more flexibility in how to structure their applications.export const PRODUCTS = datasetSource(projectId, "datasets").(This is based on #619)
What to review
Testing
Fun gif