-
Notifications
You must be signed in to change notification settings - Fork 2
Add all fields when fetching content #162
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
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.
Pull Request Overview
This PR refactors the GraphQL fragment generation to use common base fragments for all content types, expanding metadata and URL fields. The changes unify the fragment handling approach instead of treating media types as a special case.
- Replaced media-specific fragment logic with universal base type fragments that apply to all content types
- Expanded
InferredUrlandInferredBasetypes to include additional metadata fields - Updated URL, link, and contentReference property handling to use fragment spreading
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
baseTypeUtil.ts |
Refactored to provide common fragments for all base types instead of media-specific ones |
infer.ts |
Added comprehensive metadata fields and expanded URL structure to match GraphQL schema |
createQuery.ts |
Updated to use ContentUrl fragment for URL types and apply base fragments universally |
createQueryExperiences.test.ts |
Updated test expectations to reflect new common fragments in all generated queries |
createQuery.test.ts |
Updated all test snapshots to include new base fragments and ContentUrl fragment usage |
convertProperty.test.ts |
Adjusted fragment count threshold from 101 to 105 to account for additional common fragments |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| _modified: string; | ||
| _score: number; | ||
| _id: string; | ||
| _track: string; |
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.
I'm not so sure about the fields above _metadata. Some of them might make sense when we implement free text search in the SDK. For example, _fulltext can return a lot of data and this data only makes sense when you do a free text search. This field is an aggregation of all searchable properties, which can be a lot.
This PR adds all non-user defined fields (like
_metadata) to the response when calling the functiongetContentByPath. It also completes the non-scalar values (like URL)