-
Notifications
You must be signed in to change notification settings - Fork 35
feat: determine LP reference and RTE paths during query resolution #214
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
Staging -> master [Bug Fix: Multiple stack import failing]
Deepak-Kharah
left a comment
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.
Looks good
Deepak-Kharah
left a comment
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.
Change looks good!
Deepak-Kharah
left a comment
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.
LGTM!
As of 5.1.2, for live preview, we determine all possible reference paths and JSON RTE paths at runtime by fetching content types and recursively iterating over them. For very complex content types, this process results in a lot of reference paths caching which becomes impossible.
This change adds a new custom field
cslp__metato each content type node, which resolves with the value of reference paths and JSON RTE paths. This leads to a significant improvement in speed, as no expensive runtime calculation has to be done.To resolve
cslp__meta, we iterate over the content types and the Gatsby query (using theinfoargument of the resolver -info.operation) and collect the reference and RTE paths.