Closed travi closed 6 years ago
I would suspect this is hapenning in build
only because some of your entries might not have linked sponsors (or there is a typo somewhere in markdown). This will happen only in build because we don't mount all pages in develop - this is done just client side when you open site in a browser.
Try adding some console logging before you try to access frontmatter.sponsor.frontmatter
:
if (!frontmatter.sponsor) {
console.log("this frontmatter doesn't have linked sponsor field", frontmatter)
}
you should see in console which entry is at fault here
ah. your description made me realize what i missed without the debugging. the mappings were working fine for all actual meetings, but the slug creation was too aggressive now that markdown files existed for things other than meetings.
i added filtering so that slug creation that used the meeting template is now limited to meetings. i used a property that only exists on a meeting, which works but feels a bit hacky. since i'm still pretty new to gatsby and graphql, i'd be more than open to a suggestion if there is a more direct way to filter this.
either way, thanks a lot for helping me track down the issue and for your work on gatsby. i continue to be impressed the deeper i get.
👍 I'll close this, as issue was resolved
yep that works. the only reason i didnt close myself was in case you had a recommendation for improving, but i didnt highlight the question very well:
i used a property that only exists on a meeting, which works but feels a bit hacky. since i'm still pretty new to gatsby and graphql, i'd be more than open to a suggestion if there is a more direct way to filter this.
what i have works to keep me moving and i can always improve as i learn, but if there is a recommended way, i'd love to learn tips like that early in my journey
Maybe you can check how it is done on gatsbyjs.org - https://github.com/gatsbyjs/gatsby/blob/master/www/gatsby-node.js#L278-L311
we get parent node (which should be File
type) and that node would have sourceInstanceName
property (which is what you set as name
in gatsby-config.js
), and use that to determine whether MarkdownRemark node is Meeting or Sponsor etc
great, that sounds much more in line with what i was hoping for. i'll give that a shot for sure. thanks again!
I have this working, albeit with painful behavior in develop mode. tl;dr Any edit loses the mapping for that node.
For Markdown, each post can map to one more more topics, where both are in Markdown. Let's say PostA has, in its front matter: topics: ["topicA", "topicB"] where those map to a value in the front matter of some markdown documents. sourceNodes setups up the mapping and makes the nodes, gatsby-config "mapping" does the mapping, the Topic.tsx works fine listing all those posts with that topic.
But if I edit any part of of post, the listing breaks. The query which grabs the topics fields, and extracts the front matter for the posts for the topic, returns all the front matter...except the one I just edited. Which is now null. Meaning, the mapping doesn't work for the edited target.
Restarting gatsby develop
doesn't help. I have to blow away .cache and rebuild.
This makes for a suboptimal authoring experience.
I wondered if perhaps editing, from an immutability perspective, changed node.id but graphiql seems to have that be consistent.
Description
my goal is to set up relationships between details in frontmatter of several different groups of markdown files. i was able to get this working for
gatsby develop
with the approach to mapping that i found here. however, when i rungatsby build
, it fails with a WebpackError due to failing to read a property ofnull
, which is one of the mapped relationships that worked undergatsby develop
. i was able to continue setting up more mappings that worked withgatsby develop
but failed the same way withgatsby build
.Steps to reproduce
data-structure
branchnvm install
npm install
npm start
(runsgatsby develop
). load the (early WIP, so no judging :) ) site in the browser and note that things are rendering w/o issuenpm run build
(runsgatsby build
). note the webpack errorExpected result
gatsby build
should complete successfully, resulting in a site that works the same as the one available fromgatsby develop
Actual result
Environment
File contents (if changed)
gatsby-config.js
:package.json
:gatsby-node.js
:gatsby-browser.js
: N/Agatsby-ssr.js
: N/A