Hi @JLernDesign, and welcome to DatoCMS!
You can make a single-link field in your menu_item model. That can link to the other single-instance page models, like this:
Then when you edit a menu item, you can link it to one of the single-instance models:
The dropdown is clearer than the input box right now, because the single-instance models don’t have record titles set up, so they just chose a random text field to use as its name, e.g.:
(You can fix that by giving those single instance models another text field to use as their names. Or just use the dropdown.)
In any case, once you have that set up, you can then query menu_items for all the single-instance models they link to, like this:
query MyQuery {
allMenuItems {
id
title
slug
model {
... on AboutRecord {
id
_modelApiKey
}
... on ExpertiseRecord {
id
_modelApiKey
}
... on PsilocybinRecord {
id
_modelApiKey
}
... on ServicesPageRecord {
id
_modelApiKey
}
}
}
}
I forked your project into a sandbox environment so you can take a look as an example. I’ll DM you the link in a moment here.
However, I should note that this is a somewhat unusual way to compose schema for multiple pages. Single-instance models might make sense for really unusual pages (like a contact form) , but you don’t necessarily need a separate model type for every informational page.
As a hypothetical example: About, Expertise, Services, Psilocybin, could all potentially be records under one “Page” model. That “Page” model can have a Structured Text field and/or Modular Content Fields. Then you use Blocks to make reusable sections, like a “Quote” block that contains text and byline, a pricing block, etc. The different pages can then pick and choose the blocks they want to use in order to compose the final layout.
That way, your schema can be a lot simpler (just one model for all your pages, with reusable blocks). And your frontend template would be reusable across pages, since it would know how to render each block type as a component and build up from there.
The benefit of this approach is that it’s more maintainable long-term (easy to change page layouts both in the CMS and in the frontend, easy to add new blocks as components, etc.). The downside is that it might require a bit more upfront setup since you can’t just hardcode model fields directly into each frontend page.
Up to you which you prefer, but that’s what we see most often (and it makes sense for most websites).
Your way is fine too, it just requires a little more manual linking in the CMS and query, since single-instance models have no inherent relationship to each other. They’re just independent things. In fact, if you want, you can just hardcode their IDs into your frontend nav and not have to retrieve them from GraphQL at all, since technically they are separate models and templates anyway.