Gatsby: Location of useStaticQuery usage breaks app

[mcclaskiem]

Description

I have a menu component that relies on a staticQuery to populate it's contents. Depending on where I import and use this component I get the below error:

Error: The result of this StaticQuery could not be fetched.

This is likely a bug in Gatsby and if refreshing the page does not fix it, please open an issue in https://github.com/gatsbyjs/gatsby/issues

Steps to reproduce

I have a menu component that I import and place inside of my layouts/index.js file which will result in the above error.

I then move this menu component inside of my header component which is imported and used inside of layouts/index.js, this also results in the above error.

If I move the menu component into pages/index.js it renders as intended. _I will note that I have my page query commented out as well on this page._

Project Notes:
gatsby-browser.js

  return (
    <Provider store={store}>
      <Resize>
        <Layout> // layouts/index.js
          {element}
        </Layout>
      </Resize>
    </Provider>
  );

layouts/index.js

  return (
    <ThemeProvider theme={_theme}>
      <LayoutContainer>
        <Helmet>
          <meta charSet="utf-8" />
          <title>My Title</title>
        </Helmet>

        <Header />   // Tried my menu component inside of this component

        <AsideNav />

        // Tried my menu component here

        <Modals />
        <FlashMessages />
        <GlobalStyle isProducts={isProducts}/>
        <Main role="main" isProducts={isProducts}>
          <Container showModal={showModal}>
            {children}
            {/* <animated.div style={springProps}>{children}</animated.div> */}
          </Container>
        </Main>
        <Footer />
      </LayoutContainer>
    </ThemeProvider>
  );

Expected result

This menu component should be usable inside of a global component so that it can be accessed from any view.

Actual result

Component throws error depending on where it is used.

Environment

  System:
    OS: macOS 10.14.4
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.1.0 - /usr/local/bin/node
    Yarn: 1.15.2 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
  Languages:
    Python: 2.7.16 - /usr/local/bin/python
  Browsers:
    Chrome: 74.0.3729.131
    Safari: 12.1
  npmPackages:
    gatsby: ^2.4.3 => 2.4.3
    gatsby-cli: ^2.5.13 => 2.5.13
    gatsby-image: ^2.0.29 => 2.0.41
    gatsby-plugin-favicon: ^3.1.5 => 3.1.6
    gatsby-plugin-google-analytics: ^2.0.14 => 2.0.19
    gatsby-plugin-react-helmet: ^3.0.8 => 3.0.12
    gatsby-plugin-react-svg: ^2.0.0-beta1 => 2.1.1
    gatsby-plugin-root-import: ^2.0.5 => 2.0.5
    gatsby-plugin-sass: ^2.0.10 => 2.0.11
    gatsby-plugin-sharp: ^2.0.37 => 2.0.37
    gatsby-plugin-styled-components: ^3.0.7 => 3.0.7
    gatsby-source-filesystem: ^2.0.23 => 2.0.33
    gatsby-source-graphql: ^2.0.14 => 2.0.18
    gatsby-transformer-sharp: ^2.1.14 => 2.1.19
    gatsby-transformer-yaml: ^2.1.10 => 2.1.12
  npmGlobalPackages:
    gatsby-cli: 2.5.13

[jonniebigodes]

@mcclaskiem based on the description you supplied, Gatsby's working as it should. The file gatsby-browser.js is intended for another purpose. More on that here, here and here. staticQuery in a short generalistic way of putting it is intented to work with pages and components to be consumed by said pages. Not at that level. One thing that i concede and i've mentioned in another issue, is that the message c ould be a little less misleading. I fully understand that the message is trying to cover a large ammount of cases but it can also lead to cases like this for instance.

[mcclaskiem]

@jonniebigodes Thanks for the response! So if I understand it correctly, a component that uses a staticQuery can only be used inside of a pages/* file or a component being used as a template inside of the createPages function.

The documentation uses a header as an example which led me to think it could be used in a global sense. So that header is really being used on say pages/index.js and/or some "detail" page template component, for say a blog entry.

If you wanted to make a global menu that is dynamic would the preferred approach with Gatsby be to resolve a graphQL query inside the component and use something like memo() to cache it?

[gatsbot[bot]]

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!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[good-idea]

I'm having what I think is a similar issue. I'm using useStaticQuery within a Navigation component, which is part of my Layout component that is used on every page. My query is fairly large, so I broke my Navigation component up into several files:

.
├── components
│   ├── Footer.tsx
│   ├── Layout.tsx
│   ├── Navigation
│   │   ├── NavCategory.tsx
│   │   ├── Navigation.tsx
│   │   ├── index.ts
│   │   ├── queries.ts
│   │   └── styled.ts
│   └── Text.tsx
├── images
├── pages
│   ├── 404.tsx
│   └── index.tsx

My query is within queries.ts, which looks like this:

import { graphql } from 'gatsby'

export const categoriesQuery =
  /* GraphQL */
  graphql`
    query MyQuery {
      site {
        id
      }
      allPrismicCategories {
        totalCount
        edges {
          node {
            id
            data {
              title {
                text
              }
              subcategories {
                subcategory {
                  id
                  document {
                    data {
                      title {
                        text
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  `

The odd (and frustrating) thing is: this sometimes works. Then, sometimes I'll change the query, and then I get the ambiguous "The result of this StaticQuery could not be fetched." error. (This even happened once when I removed the /* GraphQL */ comment)

This will always work when I create and execute the query inline with my Component, like so:

export const Navigation = () => {
  const { allPrismicCategories } = useStaticQuery(
    graphql`
      query NavQuery {
        site {
          id
        }
        allPrismicCategories {
          totalCount
          edges {
            /* etc... */

Is there a way to get this to work reliably when the query is defined in its own separate file?

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[unclecheese]

@good-idea Did you have any luck with this? I'm experiencing the same issue.

[good-idea]

hey @unclecheese , I ended up reverting and putting the query into the body of the component. It now loos like this:

export const Navigation = ({ currentUri, ...rest }: NavigationProps) => {
  const { prismicMenu } = useStaticQuery<QueryResult>(
    graphql`
      query NavQuery {
        // ...my query
      }
    `
  )

  return (
    // some jsx
  )

[unclecheese]

Thanks for the reply, @good-idea . One thing I didn't realise was that useStaticQuery only works when it is called from a component within the src/ directory. In my case, it was in a thirdparty component, which was obscuring it from the build. That's a key point that might be missing from the docs.