We totally hear you on the need to connect different content types through a single field, especially for flexible rendering like “Resources” or “Card Lists”. It’s a valid pattern, and clearly something that was working well for some of you with GraphQuery and the legacy pattern.
Right now, we’re still evaluating the best way to support those more advanced use cases without compromising clarity or simplicity for everyone else.
We’re looking into a few options, whether it’s revisiting multiple types directly, or exploring new modeling patterns that could solve the same problem more elegantly.
So while we can’t commit to anything concrete just yet, it’s definitely on our radar, and your feedback is helping us shape the direction
Hey @Levi , thanks for chiming in and apologies for such a delayed reply ha
Anyways, what you mentioned above is not what im seeing in practice. At least not how you seem to imply.
In order to get the nice types I still have to manually loop over the returned items and perform the link_type check as in my example above. Is there a way prismic could handle this for me? Maybe via a noBroken parameter or something? It just feels cumbersome to have to manually check all the items myself when (I assume) prismic is already doing some sort of parsing behind the scenes? Maybe thats a poor assumption on my part and the fetching is much more straightforward in reality
Thanks for your feedback. In your example, you’re still using GraphQuery, which means you're not fully in the new setup we did for content relationship without GraphQuery.
Could you provide us with an example that doesn't use GraphQuery and explain what you think is missing to enhance the developer experience?
TypeScript Array.prototype.filter doesn’t handle type narrowing great, one way to work around that is to provide it with the isFilled.contentRelationship helper ((service) => isFilled.contentRelationship(service) should also work).
We cannot guarantee the data object is present (there are some edge cases where it might not be present when the linked document is empty), that’s why using the non-null accessor is required before checking the title field.
Sure thing. My issue exists even if im not using GraphQuery. Below is an example of what I mean.
In Prismic I' have a very straightforward “Homepage” model that contains a repeated group (blog_posts), and inside each of those items is a ContentRelationship to a “BlogPost” page (blog_post).
I would expect, or maybe hope, that the prismic client would be able to handle the cases of broken/empty relationship links for me when I’m requesting these documents. I does fetch these documents, but maybe as part of the params object it’d be nice pass a flag so that the client can filter out any empty or broken documents from my results, returning an appropriately typed response.
As it is now, I must do that myself for every ContentRelationship field I request. The below example is if its in an array, but the same general process must be done even if its a top-level ContentRelationship
I feel I either need to A) still cast these filtered items to overlap with the generated prismic types (ex: BlogPostDocuments), B) use some other generated prismic type across my codebase that these items “naturally” satisfy (does this exist?), or C) explicitly type out all the fields from the generated prismic types I want in my other components (ex: <BlogPostCard title={blogPost.title} description={blogPot.description} … />)
I’m actually really curious to know how you handle things @lihbr! Right now doing this isnt the end of the world, but it is tedius and something I’d love to not have to think about if possible. When working with clients building their sites, these are the last kinds of things I wanna have to worry about. I actually found out about the isBroken because a client accidentally deleted something and it took down the whole site. As the developer I obviously take responsibility and learned from that mistake, but I’d much rather they just didn’t see an item on a page (cause it was filtered out) than the whole component error’d out
Totally understand the limitations. And from what Im gathering it seems like there isn’t any OOTB solution and these filtering steps are the recommended way to do things.
In that case I guess this can just serve as docs for folks who might come after wondering if there’s another way to handle things ha. Maybe there is some other generated type or util that im not aware of that can give me what I’d like, but if not then it is what it is. Still really like and enjoy using Prismic ha.
Hi @jordankid93, thanks a lot for the detailed explanation!
From the code you shared, I can confirm this is the best approach to use for now, but I agree things can be improved:
isFilled helper
It’s true that it can be unexpected to check for isBroken when isFilled.contentRelationship can be expected to make this check (it's not). We'll review that with our team and consider updating the helper to also do that check (but it's not as straightforward as it seems, as there are some historical reasons why the helper is not doing that check)
API flag
I agree that the idea of having some kind of flag to provide the API with for it to filter all non-filled/broken values is interesting. We'll discuss that internally!
Type improvements
Regarding types, it's important to understand that a document type (e.g. BlogPostDocument) and a content relationship type (e.g. FilledContentRelationshipField<"blog_post">) are different types that share some overlaps (especially when fetching all fields from the content relationship), but unfortunately, one cannot be used as a replacement for the other, that's why TypeScript throws an error when trying to do so. Casting is generally fine (after the kind of checks you make), but is far from being ideal.
We do generate internally the content relationship exact types (you can see them inside your prismicio.d.ts file). We could export them for them to be reused throughout the codebase, but there are some considerations for us to review before moving forward with that (as it would mean each content relationship fields would yield a dedicated, exported type, which can get messy when different slices/documents need to render a BlogPostCard that would need to be typed accordingly for example)
I hope this answers your questions regarding the existing capabilities of Prismic generated types and that it brings some lights to some of the challenges we're facing. We agree there is room for improvement, and in that regard, your feedback is really great to help us prioritize those
Honestly, I’m just pleased to hear there’s a chance for some improvement ha. I can imagine you guys are working on other more pressing matters so just hearing you’ll bring it to the team for internal discussion is a win in my book.
Is this for some reason also affecting slices added to a customtype? My Article page is a customtype, and I added new fields to a slice, which is reflected in the Prismic CMS and in code, but the API doesn’t return it. I’m using the client.getSingle(“article”… .
I’m not sure that I understand your problem, as it should not have an impact. Could you share your models? The custom type (JSON) + the slice (JSON) you’re referring to?
Also, you confirm you have an article document on Page Builder with the slice added and everything is published?
I can’t get slices within linked documents to appear in the API, which is annoying.
So I continue to rely on the clunky graphyquery on pages, where I have to specify every single slice, of which there a tons, regardless if it has content relationship or not, and in some cases fetch links as well.
Please make it so the field picker includes an “include slices” option which adds the data object to the linked document, so I can access it using: linked_doc_uid.data.slices
Hey. No problem. I have 2 main use cases on my site :
A gallery which allows you to select slides which contain a grid of different slices (eg. TeamProfile). In my GridGallery slice there is a repeatable group field with a content relationship field linking to a gallery_section custom type. This gallery section allows me to have three different slices (TeamProfile, Logo, and FeatureCard) a these are nested so don’t show up in API.
Hey all,
