Hello and happy new year, Prismic friends! I'm looking for some help implementing something Sadek mentioned in a recent meetup.
We have a good amount of "reference content" that exists on multiple pages. For example, the same testimonial/review (or blurb about our company) is used across multiple pages. Currently, that content is duplicated across every document that uses it. If we wanted to make a change to that content, we'd need to make the change on each document where it's been duplicated. Ideally, we'd have a one-to-many content relationship and be able to update the content from one document/place.
Is there any guidance on how to implement this in Prismic? I assume that we'd link from a slice to a document that holds the reference content, but any advice the community can offer (or point to) would be much appreciated!
Thanks for pointing me to the right docs, Priyanka! I suspect that this gives us everything we need. I'll circle back here if I/we have more questions.
Hi, @Priyanka! Our team (led by @jehovany.cruz) is working on a proof of concept that allows us to link from a slice (controlling layout) to a document (controlling shared content). This allows us to manage shared content from a single document even though that content is used across multiple pages/documents. For example, imagine an author's bio listed on every blog post they've authored, or a blurb about our company that's listed on multiple landing pages.
We're now trying to figure out how to manage different types of shared content. For example, one piece of shared content might be comprised of a heading, text field, and a single image. Another piece of shared content might be comprised of multiple images and no text. Off the top of our heads, we can think of at least six different types of shared content—where the relevant fields would be different based on the type of shared content.
We want to make the content relationship easy for developers to maintain and easy for content writers to understand/use. One thought was to create a custom type for each different type of shared/reference content. This would expand our list of custom types but make it obvious to the content creator what data that shared content needs. Another thought was to create a single custom type ("Shared content"), managing the different fields through document tabs. This avoids having a bunch of single-document custom types but might make for a more confusing content creator experience.
Any thoughts on the above? If the question or our situation is unclear, please let me kno! I'm also tagging @samuel, as we've been having a related conversation about Prismic best practices.
I don't think there's a correct answer to this. Both of your ideas sound well-thought-out. Personally, my preference would be to create separate Custom Types for each type of shared content. This would ensure a solid architecture and avoid confusion with the inputs (though I know it can be a bit annoying to create additional Custom Types.)
However, I'm curious if there's a compromise. An author sounds like a piece of structured data — it necessitates an avatar, name, bio, etc. However, a company blurb is much more amorphous. So maybe you could create one Custom Type for each data structure ("Author", for example), and then another general "boilplate" Custom Type that includes a Rich Text field (or even a simple Slice Zone) to allow for more dynamic content, which you could use your company blurb, a row of logos, and other content without a rigid structure.
Let me know if that helps at all or if it leaves any questions unanswered.
Thanks for sharing this idea, Sam! I've shared it with our team and I'm sure it'll help us make a more informed implementation decision.
As a side note, I've really appreciated your thoughts on the various architectural questions I've asked and I'd love to see more of these architectural best practices documented in self-serve content! The Prismic community needs more best practices elevated to general/common knowledge.
However, some of these resources were written before Slice Machine, so they might not represent the most efficient way to do things. We're looking at reworking this content — exactly in line with what you're suggesting. So, stay tuned!