-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
feat(gatsby): Load static query results in Gatsby runtime #25723
feat(gatsby): Load static query results in Gatsby runtime #25723
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.
It looks good even if I have some comments. I'm not sure I'm entirely wrapping my head around it semantically (that's on me, not you).
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.
Does this also need a develop side of this with static queries over websocket?
Also in-flight stuff is missing.
Do we have any runtime tests for this?
Otherwise LGTM, great work!
Your pull request can be previewed in Gatsby Cloud: https://build-3ce63284-7a05-4066-8bd5-bc8732a96c29.staging-previews.gtsb.io |
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.
Cleanup is missing from inFlight stuff and I'd personally unify and lightly abstract those, but it's also okay to also keep specific solution for both, as long as we clean it up.
The test failures seem to be genuine errors (or at least changes that need updating in the tests). |
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!
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.
Could you answer @pieh comment? Otherwise LGTM.
Published a canary at |
Hello @sidharthachatterjee @freiksenet I think this breaks integration with Storybook, for example, DanailMinchev/gatsby-starter-testing#31 :
I was following https://www.gatsbyjs.org/docs/visual-testing-with-storybook/ tutorial |
@DanailMinchev Thank you so much for reporting! Can you open an issue please with a link to your reproduction? I’ll take a look tomorrow! |
@sidharthachatterjee Thank you for your quick reply, apologies, I think another dependency breaks the Storybook integration, I will have a look and let you know in a separate issue, thank you |
Looks like it is related to |
Hey @sidharthachatterjee, I'm also seeing the above issue (I tried isolating just a gatsby upgrade and it's still problematic). I can't see any network calls being made to the I think that this change has also busted conditional page builds for static queries. Previously, as this was embedded into js, a change to a static query result would change the webpack compilation hash, and you get a full rebuild (not ideal but at least the content isn't stale). Now any change in the static query result is not affecting the pages (conditional page builds is only interested in the page-data). This effectively has broken static queries with condtional page builds |
@herecydev Yup, conditional page builds only handles page data changes and will need more work to support this. We didn't block on it since it's experimental but should fix that soon (can you open an issue for this please?)
Regarding this, are static query results not loading for your site? They are preloaded and heavily cached globally per site so it might be easy to miss. In case you have a reproduction, could you please open an issue? Thanks! |
Yep I'll create a ticket for conditional page builds and create a simple PR for the docs (effectively warning people against using static query for now) I'll try to put a repro together later, what I can say that might help is that none of the page-data has any staticQueryHashes in there (it's all empty arrays). I've glanced through your PR and that seems to be the "glue" that's necessary for the data to be fetched. |
That's super helpful! Thank you so much 🙌
You're correct. If it's empty for pages that does include static queries, that's a bug. |
Yep, all empty (tried pages created from "pages" and templated via |
@herecydev Feel free to assign me to the issue with the reproduction. I'll investigate immediately. |
Thanks, it won't be for several hours unfortunately. Hopefully it's simple to repro 🤞 |
Actually only took a few minutes: https://github.com/herecydev/gatsby-static-query-bug Clone, |
@herecydev Thank you! Just tried it out. Can't reproduce. Works perfectly fine for me. Can you try running |
…5723) * Load static query results in Gatsby runtime * Update snapshots * Add in flight check and caching * Revert loader.loadPageSync behaviour * Use optional chaining * Use memoized get across loader * Refactor loader and clean up * Remove console.log * Add a separate in flight map per page * Add back assertion for Promise in loader * Make fetchPageDataJson a class function * Ensure static queries work in wrapRootElement * Disable gatsby-ssr wrapRootElement * Fix static query result fetch calls when using __PATH_PREFIX__ * Add back gatsby-ssr * Add preload headers for static query results * Return undefined when page is broken in loader * Set error state in pageDb * Fix tests
Static query results in Gatsby are currently imported as JSON by webpack. This means that static query results are included in your site's JavaScript bundles.
This is different from how page query results are written and loaded on the client by Gatsby. They are loaded by the Gatsby runtime instead and hence live outside of the webpack pipeline. This ensures that a single data change doesn't invalidate your entire site's JavaScript assets.
This PR makes the handling for Static Queries similar.
(This was previously opened as #23837 but then superseded by several more granular PRs of which this is the last)