feature: link related ideas

[interim17]

Problem

Closes #42

Would be nice to get this in before design review next week so that as many pieces of the design puzzle as possible are in place.

Solution

This address the issue about by adding a "related ideas" field to ideas.

Idea relations are flat, not parent-child. No in depth styling:

I also followed the pattern from "resources" and made an Idea node in our data layer.

I've been aiming for this for a while, while the plugin will in fact create a MarkdownRemark node for all our .md files, and we can definitely query them, I think it's best for our main data structures to be explicitly typed and non-overlapping.

Attendant to that change:

• pulled the last types out of gastby-node.js and into base.gql
• Now use a resolver for IdeaPost instead of Frontmatter and extracted it into a seprate file (the file move is just for org/readabiltity)
• refactored IdeaRoll to clean up tech debt, and query new Idea nodes
• add related ideas config to decap
• add related idea query/render to idea-post.tsx

[netlify]

✅ Deploy Preview for project-idea-board ready!

Name	Link
🔨 Latest commit	558376e
🔍 Latest deploy log	https://app.netlify.com/projects/project-idea-board/deploys/69d52e97ccb07a0008c760c9
😎 Deploy Preview	https://deploy-preview-84--project-idea-board.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Copilot]

Pull request overview

Adds support for linking “related ideas” between idea posts by introducing a first-class IdeaPost node type in Gatsby’s data layer, wiring up CMS configuration, and updating idea listing/detail pages to query/render the new node shape.

Changes:

• Add a related_ideas relation field to the Ideas collection in Decap CMS and surface it on idea detail pages.
• Introduce an explicit IdeaPost GraphQL node type + resolvers (parallel to Resource) and move schema definitions into gatsby/schema/base.gql.
• Refactor IdeaRoll and the idea-post template to query IdeaPost nodes instead of MarkdownRemark.frontmatter/fields.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
static/admin/config.yml	Adds a “Related Ideas” relation field to the Ideas CMS editor.
src/types/index.ts	Updates Idea post typing to use ideaPost query result shape.
src/templates/idea-post.tsx	Switches to querying ideaPost and renders related ideas.
src/pages/ideas/dev-example.md	Adds example related_ideas frontmatter.
src/components/IdeaRoll.tsx	Refactors idea list to use allIdeaPost query and simplified rendering.
gatsby/utils/gatsby-resolver-utils.js	Adds ideaPostQuery helper for nodeModel lookups.
gatsby/schema/base.gql	Defines the new IdeaPost node type and related schema types.
gatsby/resolvers/resolvers.js	Adds IdeaPost field resolvers (including relatedIdeas).
gatsby/constants.js	Adds constants for IdeaPost typing and ideas slug directory.
gatsby-node.js	Wires schema customization and resolvers for IdeaPost, and updates page creation logic.

Comments suppressed due to low confidence (1)

gatsby-node.js:10

• gatsby-node.js still imports stringWithDefault, resolveToArray, and resourceQuery from gatsby-resolver-utils, but they are no longer referenced in this file after moving logic into createIdeaPostResolver. Removing these unused imports will avoid confusion and potential lint failures.

const { createIdeaPostResolver } = require("./gatsby/resolvers/resolvers");
const {
    stringWithDefault,
    resolveToArray,
    resourceQuery,
} = require("./gatsby/utils/gatsby-resolver-utils");

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[meganrm]

would it cause a problem if people select a related idea 1 -> 2 and 2->1?

I know you asked about this, and I think it might be best to have it always be "select any ideas this a descendant of "

[interim17]

I don't think it would cause a problem, but the question exposes the one way nature of this design.
As this is writte now:
associating 1 and 2 in the context of 1, doesn't mean that 1 and 2 are associated in the context of 2.

Stably identifying ideas with parent child relationships means that we need to edit multiple markdown files anytime we create one of these links. So if 1 and 2 have a parent-child relationship, and we define that when editing Idea 1, we then need to also edit 2 to mark the parent relationship. You would resolve peers by looking at shared parents.

Interestingly, gatsby nodes have a built in parent/child data structure, but I think this would be a hacky way of exploiting it, if we used it for this purpose.

[interim17]

I guess my question is: in practice are ideas really likely to have obvious parent-child relationships? What conversations with scientists or toy examples show that being the case? Or are they more likely to be loosely networked and associated? That loose association is also captured somewhat with tags.

[meganrm]

I think we said this is the only change that is needed: changing it to "select ideas this is a child/descendent of" or something

[interim17]

Mostly the same code as our our old frontmatter resolver, just in a new file and with "relatedIdeas" added

[ShrimpCryptid]

LGTM! Haven't done anything with Gatsby/GraphQL before so left a bunch of questions.

[ShrimpCryptid]

Nit: Order these above IdeaPost?

[ShrimpCryptid]

What does this pageQuery do? Why were some of the fields (id, html, frontmatter) removed? Is that because the below properties are now inside of ideaPost instead of frontmatter?

[interim17]

Will quick answer and then if you want more detail happy to talk about it.

This template is used to make a page for every markdown file in pages/ideas. The query grabs data from a corresponding node in the data layer that Gatsby makes.

Gatsby reads through all our markdown files and constructs a data layer that we can query and then only the data we actually query is used when building the site. The idea is to have everything the static site needs up front with all data you need and none that you don't. So this query tells Gatsby, find the idea post with a matching ID and get me exactly this data I need to build my page. Stuff in the markdown content that isn't queried doesn't make it to the build.

The change from markdownRemark to ideaPost is because we used to rely a plugin that had one type of node, so every data node was a MarkdownRemark but that got a bit confusing as data structures diverged. We've been migrating to have more typed nodes, like IdeaPost or Resource etc. When refactoring the query to reflect that, I noticed we were getting fields we didn't really need so removed them.

[ShrimpCryptid]

Is this filter filtering out drafts?

[interim17]

yes