Skip to content

resource query (resource migration 1/3)#71

Merged
interim17 merged 42 commits intomainfrom
feature/resource-query
Mar 19, 2026
Merged

resource query (resource migration 1/3)#71
interim17 merged 42 commits intomainfrom
feature/resource-query

Conversation

@interim17
Copy link
Contributor

@interim17 interim17 commented Mar 11, 2026

Problem

Advances #40

Line count inflated by formatting stuff. Next priority needs to be getting those pre commit checks up and running so we can iron that out.

Next PR in series is here: #72

Solution

We have created a single resource collection in the CMS. Now we need to consume these resources.

The primary goals of this PR are to successfully convert those resource markdown files into useful gatsby nodes, build the pages associated with resources, and query the resource nodes wherever they are needed.

gatsby improvements and upgrades come along for the ride.

Resource Nodes

Up until now, all our nodes in our gatsby data layer were of type MarkdownRemark. This has pros and cons. In this PR we create a type Resource that implements Node

This resource type is flat, relative to MarkdownRemark, in that it does not have frontmatter or fields but only top level properties.
It is also flat relative the resource .md files in that it does not have a nested ResourceDetails field, but only top level properties.

It can be queried with allResource and resource which is a nice option to have.

These nodes are created explicitly in onCreateNode. The MarkdownRemark nodes are created, mysteriously, by a plugin.

Resolvers

Resolvers can take direct advantage of these nodes, we should have done this before. See the resources resolver for a nice pattern using context.nodeModel.findOne(resourceQuery(name)) This typing and way of handling the resolver replaces the @link directive in a way that is more pleasant.

onCreateNode and createPages

We make resource nodes and resource pages in a way that is extendable to other forthcoming types. We map over TEMPLATE_KEY_TO_TYPE. This wasn't strictly necessary for this PR but it's good practice and I know another use is right around the corner. When we want to make an Allenite node or page, or a Program node or page, it will be set up.

interim17 and others added 29 commits February 19, 2026 14:23
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@netlify
Copy link

netlify bot commented Mar 11, 2026

Deploy Preview for project-idea-board ready!

Name Link
🔨 Latest commit 1a233ec
🔍 Latest deploy log https://app.netlify.com/projects/project-idea-board/deploys/69bc0c59c48c66000891bde2
😎 Deploy Preview https://deploy-preview-71--project-idea-board.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

Comment on lines +108 to +124
resources: {
resolve: async (source, _args, context) => {
const names = resolveToArray(source.resources);
const results = await Promise.all(
names.map((name) =>
context.nodeModel.findOne(resourceQuery(name)),
),
);
results.forEach((result, i) => {
if (!result) {
const msg = `Resource "${names[i]}" not found for idea "${source.title}". Check for typos and ensure the resource file exists with the correct templateKey.`;
reporter.error(msg, new Error(msg));
}
});
return results.filter(Boolean);
},
},
Copy link
Contributor Author

@interim17 interim17 Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A different way to handle the resolution, using context.nodeModel.findOne, where before we would use a @link directive in the schema. Both are valid ways of doing things. I think I prefer this way because we get a bit more color, as in the example of doing error handling with the reporter.
https://www.gatsbyjs.com/docs/reference/graphql-data-layer/node-model/#findOne

Do we really need error handling here? We have some now.

interim17 and others added 8 commits March 10, 2026 22:50
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 28 out of 28 changed files in this pull request and generated 4 comments.


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

You can also share your feedback on Copilot code review. Take the survey.

materialsAndMethods: MaterialsAndMethods!
authors: [String!]!
nextSteps: [String!]
authors: [String!]

This comment was marked as resolved.

Comment on lines +112 to +114
names.map((name) =>
context.nodeModel.findOne(resourceQuery(name)),
),

This comment was marked as outdated.

@interim17 interim17 changed the title Feature/resource query resource query (resource migration 1/3) Mar 11, 2026
@interim17 interim17 marked this pull request as ready for review March 11, 2026 15:13
Comment on lines +1 to +50
import * as React from "react";
import { Helmet } from "react-helmet-async";

import { Link, PageProps, graphql } from "gatsby";

const ResourcesPage: React.FC<PageProps<Queries.ResourcesIndexQueryQuery>> = ({
data,
}) => {
const { allResource, site } = data;

if (!allResource || !site) {
return <p>Data not found.</p>;
}

const { nodes } = allResource;
const title = site.siteMetadata?.title || "Title";
return (
<section>
<Helmet title={`Resources | ${title}`} />
<div>
<h1>Resources</h1>
<ul>
{nodes.map((node) => (
<li key={node.slug}>
<Link to={node.slug}>{node.name}</Link>
{node.description && <p>{node.description}</p>}
{node.type && <p>{node.type}</p>}
</li>
))}
</ul>
</div>
</section>
);
};

export default ResourcesPage;

export const resourcePageQuery = graphql`
query ResourcesIndexQuery {
site {
siteMetadata {
title
}
}
allResource {
nodes {
slug
...ResourceFields
}
}
Copy link
Contributor Author

@interim17 interim17 Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly a proof of concept, just showing in all the relevant places that the new data and approach is working.

@interim17 interim17 changed the title resource query (resource migration 1/3) resource query (resource migration 1/2) Mar 11, 2026
@interim17 interim17 changed the title resource query (resource migration 1/2) resource query (resource migration 1/3) Mar 11, 2026
(rapid local changes in junction length and intensity) increases ~30–60
minutes before migration onset in a subset of fields of view. Here is a link for no reason: [link](https://allencell.org/).
minutes before migration onset in a subset of fields of view. Here is a link
for no reason: [link](https://allencell.org/).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😄

@interim17 interim17 requested a review from rugeli March 18, 2026 21:31
Copy link

@frasercl frasercl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will have to make a point to learn a bit more about Gatsby! I left a couple basic clarifying questions about the style and architecture, at least one of which is bound to be dumb, but this is looking good as far as I can tell.

Comment on lines +12 to +17
const {
DATASET_PATH,
RESOURCES_GATSBY_NODE_KEY,
MARKDOWN_REMARK_GATSBY_NODE_KEY,
TEMPLATE_KEY_TO_TYPE,
} = require("./gatsby/constants");
Copy link

@frasercl frasercl Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another optional clarifying question: any rhyme or reason to what gets CommonJS-style vs ESM-style imports? I guess these and the files in gatsby/ are either config or server-side...?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Historical anachronism from gatsby's age and the template this repo was started from.

I think webpack handles src and gatsby-browser.js and Node directly handles the other gatsby configuration files. I think we would need to migrate everything at once and it's just been low on my list, but it is starting to get annoying. Maybe I should do that next. Gatsby supports ESM now, it didn't always.

https://www.gatsbyjs.com/docs/how-to/custom-configuration/es-modules/

IdeaFrontmatter["preliminaryFindings"]
>["figures"][number];

export type ResourceTemplateQuery = Queries.ResourcesByIdQuery;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Large block comment above is very helpful for understanding why this works despite the red squiggle TS throws up on Queries

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes... Curious if it smells bad to you to be defining types downstream of the generated types.

In cell-catalog we wrote types based on what we expected the queries to give back which gave rise to some interesting bugs. This way is a little annoying, but it keeps the data layer and the front end in tighter lock step.


import { Link, PageProps, graphql } from "gatsby";

const ResourcesPage: React.FC<PageProps<Queries.ResourcesIndexQueryQuery>> = ({

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing some query types with Query at the end in the graphql declaration, resulting in this QueryQuery name in TS, and some without. Any reason for some to be one vs. the other?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm just style, I think before we were using the generated types we had a pattern of putting query at the end of the name, and now should probably be moving away from that since it produces the redundancy.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity: any reason this file is a plain .js file?

Copy link
Contributor Author

@interim17 interim17 Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We initialized this repo from a template, we are migrating away from their style over time, but some things are in the old style which included a lot of plain JS.

I'm tackling patterns like this as I hit them, to avoid massive, unreviewable refactors.

@interim17 interim17 merged commit e33bdec into main Mar 19, 2026
5 checks passed
@interim17 interim17 deleted the feature/resource-query branch March 19, 2026 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants