StaticQuery silently fails when used inside wrapRootElement and wrapPageElement #7747
Comments
|
So |
|
The |
|
I ve got the same problem after many research it's appear that you need to put the file where is located your staticquery in the folder ./src else you will get "Loading (StaticQuery)" so what i did: and in inject-provider.js (that you can use esmodule so import and so on) your layout with the static-query. Certainly because babel compile only in src/*.js WILL BE GREAT to add this in the DOC |
|
I'm making a Gatsby plugin and I have to expose part of my plugin config to the browser. I'm exposing part of the config to GraphQL and using |
I seem to have run into this issue also. But my code is already inside the src. I use other StaticQueries without problem. Just one that is building a cache and used in wrapRootElement causes problems. |
|
It seems to work when doing the build. Its just in development that fails with the Loading text |
|
Also butting up against this issue while trying to expose some data from the Gatsby data through to the client for some initial state. Neither |
|
I'm also encountering this issue. Can confirm that wrapRootElement works fine with in build, but not in dev. |
|
I'm looking for a way to use StaticQuery in an npm package. Does anyone know if it's possible? |
|
@krabbypattified and @TylerBarnes - I have been looking through the Gatsby source for a way to do this. I have a workaround 😄 (i.e. hacky abuse of the I copy any components with queries from my local plugin directory to |
|
@elskwid thanks for the tip, I'm gonna give that a shot! |
|
Fyi, I was able to get my |
|
@antoinerousseau Yep, I'm seeing the same thing. This is a pretty knarly bug I think. At the moment if you want to initialize your providers with data from a StaticQuery you're kind of stuck. The knock on effect from that is that there's no simple/idiomatic way to share a single piece of static data globally across the application afaics. |
@elskwid Could you share that code? We started a new project and are again having this issue. |
|
@antoinerousseau and @jedrichards (and the rest of you 👋). We were able to get a component to stay mounted across page changes by using I created a import { ChildrenType } from '../../types'
import { SearchProvider } from '../Search'
import React, { Fragment } from 'react'
/**
* Component used to wrap the `PageElement`.
*
* Provides a way to connect state that can persist through page transitions.
*
* @param {Props} props
*/
const propTypes = {
...ChildrenType.isRequired,
}
const SiteContext = ({ children }) => (
<Fragment>
<SearchProvider>
{children}
</SearchProvider>
</Fragment>
)
SiteContext.propTypes = propTypes
export default SiteContextThen in import React from 'react'
import SiteContext from '../src/components/SiteContext'
const wrapPageElement = ({ element, props }) => {
return <SiteContext {...props}>{element}</SiteContext>
}
export default wrapPageElementYou can test out the mounting/unmounting by changing import { ChildrenType } from '../../types'
import { SearchProvider } from '../Search'
import React, { Fragment, PureComponent } from 'react'
/**
* Component used to wrap the `PageElement`.
*
* Provides a way to connect state that can persist through page transitions.
*
* @param {Props} props
*/
const propTypes = {
...ChildrenType.isRequired,
}
class SiteContext extends PureComponent {
componentDidMount() {
console.log('>>> SiteContext did mount')
}
componentWillUnmount() {
console.log('>>> SiteContext will unmount')
}
render() {
const { children } = this.props
return (
<Fragment>
<SearchProvider>
{children}
</SearchProvider>
</Fragment>
)
}
}
SiteContext.propTypes = propTypes
export default SiteContextWe see I hope that helps. |
|
@coxom this code is buried in a pretty complicated internal plugin at the moment. I should note that this process is only needed if you have a plugin or external library that needs to add fragments to the site. If you're looking for a way to get general usage fragments in a more standard setup just let me know, we have a way we're doing that too. 😉 Essentially, we have a file with GraphQL fragments in it (i.e. site-metdata-fragments.js): import { graphql } from 'gatsby'
export const siteMetadataFields = graphql`
fragment SiteMetadataFields on Site {
siteMetadata {
}
}
`Then, in By using this hook, the fragments are present when Gatsby extracts the queries, so you can use them in your app. Does that give you enough to go on? |
|
@elskwid I tried the strategy to copy the fragments into the .cache and I'm still getting the "Loading (StaticQuery)". Using gatsby 2.0.19 My use-case is similar to @krabbypattified. I'm loading translations and currencies. |
|
Ok there are few things that need to be solved:
|
gatsbot
bot
added
the
stale?
|
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open! Thanks for being a part of the Gatsby community! 💪💜 |
|
The project that I need this for just got active again. Any news on a fix? |
pieh
added
not stale
and removed
stale?
|
@pieh I am using that workaround but for a production release it would be useful to have the code only load once and not on every page change. |
|
@coxom fwiw I'm using |
|
Any updates on this? I’m running into a similar issue. Wrapping at the page level requires my component refetch the data on each page change. I’m trying to fetch translation strings from JSON to initialize i18next |
|
Top-level wrappers are pretty much a standard in the React ecosystem. I'm surprised this issue has only so little traction. We need a reasonable way to handle this as well. Passing providers on component level seems suboptimal at best. |
|
+1 |
|
Hi all. I have that issue only in iframe. where useMenuData has |
|
Getting the same problem when using the material-ui template from https://github.com/mui-org/material-ui/blob/master/examples/gatsby/plugins/gatsby-plugin-top-layout/TopLayout.js
Not sure I understand how to work around this from the above, other than moving EDIT: Interestingly, duplicating the query inside another component in the |
|
+1 |
|
I am going thru the same issue right now; see details at: https://stackoverflow.com/questions/63037661/loading-staticquery-white-screen-on-gatsby |
|
This was fixed in #25723 Static queries should now just work in Upgrade to |
|
Is this problem really solved? I keep getting the following error: I updated to the given version, and I do something like this (in gatsby-ssr.js): |
|
Getting the exact same issue. Can't seem to use static queries in any way whatsoever. The site fails with a |
|
I got the same error when try use StaticQuery in gatsby-ssr.js (wrapRootElement). My error: success Building production JavaScript and CSS bundles - 4.956s
success Rewriting compilation hashes - 0.004s
error Generating SSR bundle failed
Can't resolve 'public/page-data/sq/d/63159454.json' in '/Users/myname/GitHub/devchallenges/windbnb'
If you're trying to use a package make sure that 'public/page-data/sq/d/63159454.json' is installed. If you're trying to use a local file make sure that the path is correct.Check in {"data":{"site":{"siteMetadata":{"title":"Gatsby Default Starter","description":"Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.","author":"@gatsbyjs"}}}} |
|
Anyone knows how's going about this? 👀 |
|
I'm also seeing the same webpack error as @tranlehaiquan |
|
+1 |
Not building "Generating development SSR bundle failed" error see: gatsbyjs/gatsby#7747
|
+1 |
1 similar comment
|
+1 |
|
Seems not to work so far, and the workaround is #7747 (comment) |
|
Happy to know that my workaround is still the best option now 🥇
I have some thought; Maybe it can help now to run static query inside wraproot and wrappageelement |
|
This is still not working, can the issue be reopened please? |
|
please provide an optimal fix for this since it is very common usecase |
and others
Description
Using a
StaticQueryin a a component insidewrapRootElementorwrapPageElementresults in Loading (StaticQuery) both forgatsby-node.jsandgatsby-ssr.js.Steps to reproduce
Using this wrapRootElement implementation the issue appears:
When using this code, the context is empty which seems to be the reason.
Expected result
The context should be set for the
wrapRootElementandwrapPageElementAPIs or if this is intended, there should be a warning in StaticQuery if no context is available.Actual result
It fails silently and appears to be loading forever.
Environment
File contents (if changed)
gatsby-config.js: N/Apackage.json: N/Agatsby-node.js: see abovegatsby-browser.js: see abovegatsby-ssr.js: N/AIf given some general directions, I would be happy to contribute and make a PR for this issue.
The text was updated successfully, but these errors were encountered: