Gatsby: Tutorial Part Four Issue

[rgroves]

Summary

I was following the Data in Gatsby (tutorial part four) and after performing the changes in the "Use a page query" section the About page gives the error TypeError: data is undefined

Relevant information

After updating src/pages/about.js with the code in the "Use a page query" section, when the page reloads you get the error mentioned above along with some diagnostic info.

I've found that the development server needs to be stopped and restarted after the about.js file is updated with the code specified. Then you are able to proceed onto the next part of the tutorial. Note that the tutorial does say to restart the development server, but says to do so after you add the siteMetadata in the prior step before updating src/pages/about.js.

Continuing on to the next part of the tutorial "Use a StaticQuery" I ran into a similar issue after updating src/components/layout.js and saving when the page reloads it yields the 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

Again, a restart of the development server fixes the issue.

I think the documentation just needs to be updated to state that restarts are needed after the changes are made in the steps indicated above.

I've been through a clean start of this tutorial a couple of times to verify, (with my last attempt being sure to copy and paste the code directly from the tutorial), but if anyone else can confirm that this isn't just me, then I will make an update to the docs and submit a PR.

[jonniebigodes]

@rgroves i've picked up on your issue and ran through part 4 of the tutorial. When you reach this part, it tells you to restart the development server which i did. Based on how gatsby is setup, that piece of data will be then picked up added to the data layer is available. I then moved onto modifying the about page with the code provided while the development server is running as it's expected and i'm presented with:

The error thrown is due to the fact that gatsby will run and output all of the page queries at build time, so adding this when the server is running will lead to the error.

Moved onto the how to use a static query will result in the error you've mentioned and i'm getting as you can see here:

Once again by the same reason as above.

As i and probably you know how gatsby works with the graphql queries, but not person that is following the tutorial, having these errors as they come into contact with the framework is not a good experience and it shouldn't block the at this early stage.

As you're willing to do so, make the adjustment to this section of the tutorial and submit a pr with the changes and see what the docs team as to say.

Nonetheless nice catch on your part 👍

[muescha]

should we then also do a rewording or the error message?

-and if refreshing the page does not fix it
+and if refreshing the page or restarting the dev server does not fix it

[muescha]

should we provide at first an workaround before we blame a gatsby bug there...

-This is likely a bug in Gatsby and if refreshing the page does not fix it, 
+Try refreshing the page or restarting the dev server. 
+If this not fix it, then this is likely a bug in Gatsby, 
please open an issue in https://github.com/gatsbyjs/gatsby/issues

[rgroves]

@muescha, it seems to me the proposed change to the error message is still saying the same thing, just in a different order. In any case, I think the error message thrown by gatsby should be a separate issue (if it is an issue) from the issue with the tutorial I'm trying to address here.

[muescha]

yes i will open a new issue. sorry

[rgroves]

As reported in the previous PR I tried walking through tutorial part four again, and I can no longer reproduce the issue.

There are various differences between the package.json and lock file from the starter repo used in this tutorial (gatsby-starter-hello-world) as they exist freshly cloned today versus the one cloned back on 9/28. If I go back and use the package.json and package-lock.json files as they existed on the 28th I'm able to reproduce.

In any case, I assume some other update has fixed the original reported issue so I'm closing this PR. This also closes issue #17979