-
Notifications
You must be signed in to change notification settings - Fork 481
refactor: consistently apply current perspective for previews #8655
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
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
No changes to documentation |
⚡️ Editor Performance ReportUpdated Thu, 27 Feb 2025 14:52:16 GMT
Detailed information🏠 Reference resultThe performance result of
🧪 Experiment resultThe performance result of this branch
📚 Glossary
|
Component Testing Report Updated Feb 27, 2025 2:51 PM (UTC) ❌ Failed Tests (2) -- expand for details
|
63ab336
to
0fbe326
Compare
@@ -193,6 +193,7 @@ export function collate<T extends {_id: string; _type: string}>(documents: T[]): | |||
res.set(publishedId, entry) | |||
} | |||
|
|||
// note: this attaches versions to the `draft` property, which is likely ok for most practical purposes |
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.
Oh! We are treading the same path 😅.
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.
🤝
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.
This is great! Still works as expected in my testing. Thanks 🙌.
…h result previews
ReleaseId from `@sanity/client` is deprecated as there is no guarantees of release ids starting with `r`
…r search result previews
Description
This is a somewhat big refactor of how we resolve values for previews internally.
Previously, for each document the studio was previewing, we'd fetch a version of the preview for each known release.
This created some overhead (althought the requests are batched), but most notably it caused an issue with previews ending up showing referenced values from the published version.
This is now solved by always applying the current perspective stack when fetching preview values. The perspective stack is applied recursively, so if a document type has
someReference.title
in it's preview config, thetitle
of the referenced document will also reflect the current perspective (i.e. what thetitle
is in the selected release).Making the perspective apply to previews enabled me to remove some layering logic, since this is now done in the query that fetches the previews.
Using the just the current perspective stack poses a challenge: Sometimes you want to preview something that does not exist in the current perspective. For example: you are in the
drafts
perspective, but you want to preview a document that only exists as a version (i.e. it has neither a draft nor a published variant). This happens e.g. when previewing document list items or search results since we these collections using perspective=raw because we want people to still find version documents that exists outside of the current perspective.For these cases, we always have a version id, so in these cases we'll fetch:
If the document doesn’t exist in the current perspective, it certainly exist in it’s own version perspective, so that means we’ll always have something to preview.
Things to note:
useDocumentVersionInfo()
-hook. We no longer have preview for the version documents because we didn't have any use for that at the moment. We can always come back to that decision in the future, but for now, they return a stub with _id, _createdAt, _updatedAt, _rev, etc.Other changes
useDocumentVersionInfo(<documentId>)
-hook that will return the versions that exists for the given document idgetPreviewStateObservable()
so it no longer requires a fallback title – the fallback can trivially be applied in the consumer end, and it lead to a bunch of cases where we passed an empty string as the third argument.What to review
This should be reviewed a bit carefully. Esp. in terms of API changes and naming (is it sensible and understandable?)
Testing
We have fairly good test coverage already, and e2e tests already made me aware of a few oversights. Would love some additional testing of everything related to previews, search and references e.g:
Notes for release