If you have specific needs, ideas, or suggestions for the new Field Picker in Content Relationship fields on Slice Machine, we’d love to hear from you!
This feature is designed to replace GraphQuery and fetchLinks, by letting you visually select which fields to retrieve — right from the Slice Machine UI.
Let us know what’s working well, what’s missing, and how it could better support your use cases.
For bugs or unexpected behavior, please contact support directly.
Use case suggestion template:
Feature Name: Short name for the feature.
Description: What it does and how you'd use it.
Impact/Benefit: Why it matters and how it would help.
Since using this feature the route resolver doesnt work anymore and creates errors. I am using it like this:
clientConfig: {
routes: [
{
type: 'article',
path: '/magazin/:category/:uid',
resolvers: {
category: 'category'
}
},
When activating this feature our whole production site crashes because every prismic request errors out!
We've been able to reproduce the issue and are working on a fix. In the meantime, you can always roll back to your previous content relationship configuration and your website should work again.
Are there plans to support selecting the slices in the linked content type? I am using graphQuery to do some sub menus on my sites so the header_menu has a content relationship to sub_menu which only has slices in it. When I try to select the slices they dont come up after updating to the newest slicemachine version.
I believe this approach to make menus was suggested in some prismic docs at some point, so I was hoping for this new feature to make that implementation easier. Looking forward to remove all graphquery stuff from my sites if this is supported.
Right now, you can’t select slices from a Content Relationship field.
That’s why nothing appears in the “Allowed type” selection.
For this use case (building menus with nested slices), we currently recommend sticking to the previous approach using GraphQuery to fetch the slices manually.
It’s still the most reliable method.
That said, we’re exploring a dedicated feature to better support menus and navigation structures. Your example helps reinforce that need, and we’ve noted it.
Let us know if you'd like to be updated when that feature is ready.
I really like the new Content-Relationships. Thanks for this useful new feature.
However, there seem to be something off with the generated TypeScript types.
Types of content-relationships are now generated as follows:
Quick question — have you updated Slice Machine and your adapter to the latest versions? We recently fixed several issues related to generated TypeScript types.
Here are the commands to run depending on your framework:
How do I test this new feature before I push it to production? When I update and save changes in slice machine locally, the API responses are unchanged. I assume I will need to push my slice machine changes to Prismic for the changes to take effect on the API, but wouldn't this break my Production website?
@ben.jackson Thanks for reaching out about this. You should be safe to push to production, and you can always undo your changes if your website breaks for any reason.
To see the changes in the API, you'll need to push your slice machine changes to Prismic, then publish something (anything) in your Prismic repo. Then the changes will appear.
Any content relationship that wasn't fetching data will continue to work as usual. Any content relationship that you are currently fetching data with using fetchLinks or graphQuery will also stay the same, because using either of those will override the new data fetching.
This means that you can progressively convert from fetchLinks or graphQuery. You can verify that the correct data is being fetched by running your query without fetchLinks or graphQuery. If everything looks good, then you can remove them from your queries in production and be good to go.
Let us know if you have any questions about this or anything else.
Hey @Levi, finally found some time to play with this new content relationship flow and still have a few questions
One question I have is that when working with typescript its still a very verbose process with handwaving type casting that never really felt right to me. Would there be any guides on how best to parse the related content fetched in these calls? I'll include a snippet of what im currently doing for some context if that helps
const home = await prismic
.getSingle("home", {
// Leaving for related content context, would remove `graphQuery` with recent prismic changes
graphQuery: `
{
home {
...homeFields
services {
...servicesFields
service {
...serviceFields
}
}
}
}
`,
})
.catch(() => null)
// I need to manually loop and process the related content to make sure everything returned is as expected
const services = home?.data.services
.map((item) => {
// It would be great to have the prismic client filter out anything not filled, broken, etc.
if (
item.service.link_type !== "Document" ||
!isFilled.contentRelationship(item.service)
) {
return null
}
// I have to cast here which is REALLY unfortunate. I would LOVE for this to just of type `ServiceDocument`, especially since in slicemachine you might choose only a subset of fields. That logic not being co-located with where you fetch the data can be harmful for ongoing management
const service = item.service as typeof item.service & ServiceDocument
if (service.isBroken) {
return null
}
return service
})
.filter(isNonNullable)
TLDR, prismic provides these nice content model types like ServiceDocument which I want to use throughout my typescript (ex: <ServiceDocumentCard serviceDocument={serviceDocument} />) but the fetched data from the client are basically never these clean types and so is either impossible to actually use, dangerous in runtime (even more so now that whats return is being moved outside of code), or requires a bunch of manual work on my part to doublecheck everything before moving on
Anything that allows me to remove all the graphQuery fields in my codebase is a win for sure, but would love some better documentation / guides / tutorials on actually fetching typesafe related content data in a TS codebase
@jordankid93 As long as you've updated all the packages as @benjamin.martin shows above, when you use the new content relationship field, all the types for the fetched data in relationships are now taken care of for you. It doesn't use the nice content models types such as ServiceDocument, but it can prevent you from having to do type casting.
An alternative approach you could take for your component to avoid casting is to type your props as:
I also use multiple type selection, I have an ArticleList slice that should show a mixture of content types (Blog, CaseStudy, Guide). I am not sure how to approach this now. The marketing team can then build resources pages based on theme across different types.
Before jumping into solutions, I’d actually love to dig a bit deeper into how you structured things.
For example — why did you decide to create separate content types for Blog, CaseStudy, and Guide?
What makes them different in your setup? Structure? Design?
Understanding that will help us figure out the cleanest way to support your ArticleList use case.
Both structure and design vary between them (whilst sharing some similarities), however we class them all as "Resources" for our audience. They have their own url structure in the site, /blog/[uid] and /customers/[uid] for example. The shared properties like Thumbnail, Label, Title allow us to create slices that our content creators can use to bundle resources based on "theme" rather than type.
Hi!
I'm running into the same limitation that I'm not able to select multiple content types. The setup is very similar as the one ben.jackson has described above.
Not being able to have 1 field for all possible resource types would make it necessary to create one field for each resource type and would make it quite verbose for content creators and would force them to leave the other fields blank.
Would appreciate if you could bring the ability to enable multiple content types back as I've used this feature on previous projects as well and found it very useful.
Thanks!
For bugs or unexpected behavior, please contact support directly.
