refactor: consistently apply current perspective for previews #8655
Conversation
This file contains 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 latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
|
No changes to documentation |
⚡️ Editor Performance ReportUpdated Thu, 20 Feb 2025 16:51:56 GMT
Detailed information🏠 Reference resultThe performance result of
🧪 Experiment resultThe performance result of this branch
📚 Glossary
|
|
Component Testing Report Updated Feb 20, 2025 4:54 PM (UTC) ❌ Failed Tests (6) -- expand for details
|
bjoerge
force-pushed
the
sapp-2116
branch
2 times, most recently
from
63ab336 to
0fbe326
Compare
…h result previews
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
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.titlein it's preview config, thetitleof the referenced document will also reflect the current perspective (i.e. what thetitleis 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
draftsperspective, 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
getPreviewStateObservable()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