Hey, Prismic community! I'm back with another "best practices" question.
We're looking to implement slice variations as part of a broader effort to limit complexity within our slice library. I've read through the documentation and it appears there are several ways that we could use them. I'm looking for opinions on how we should use them.
I've thought of three potential use cases:
Layout variations. These seem like the obvious and most common use case.
Content variations. For example, a variation for unique content and a variation for shared/reference content (via a content relationship). For example, imagine a "copy and single image" slice whose content is sometimes unique to a specific page and sometimes shared across many pages.
Style/theme variations. This seems like a use case better addressed through a field within the slice variation, or even a linked document that defines the theme (the advantage here being that when we want to add/update a theme, we wouldn't have to update the data model for every slice).
It seems like a reasonable assumption that we wouldn’t want to over-use slice variations for too many use cases. For example, if we wanted to use slice variations for 3 layout variations, 3 themes, and 2 content options, that would be 18 variations (3x3x2). Too many! So which use cases are the best?
I assume that we'd want to use variations to handle layout differences. For example, a "Copy and single image" slice with variations for "Copy left" and "Copy right." But I'm wondering if variations would also be a good way of supporting reference/shared content, or whether you have another recommended approach for that (ex: dedicated slices).
And if you have ideas on how to most scalably implement global themes, I'd love input there, too! I've been fascinated by the MacStadium approach ever since they demoed it in one of last year's Prismic meetups.
Of the 3 you listed I would say the 2 first are the most obvious.
Although I think you could throw simple style variations (not themes) in to the first one as well, as long as you're not getting too complex.
Also, in most cases I think it would be OK to mix the first 2, depending on how much variations you have.
Looking at your example ideas above, a mix of custom/reference content and layout would translate into something like this for me if they would be combined slice names:
But when looking at that, and thinking about how this would be if we wanted to add one for centred content as well, that equals 2 more variations, and of course this could get messy. Maybe then one is better off deciding what to use variations for.
So in this case, since Reference/Custom content would generate very different fields for input, but Left/Right/Center would generate no extra fields, it might be better to reserve variations for Reference/Custom content in this slice, while having the layout of the slice in a select field inside.
As for themes, if your site and every slice in it would consist of 3 individually styled themes, then definitely a content relationship is the way to go in my opinion. This way one could easily add themes later on without updating each slice. That said, you may want theme decisions on a page level rather than slice level, if so it's obviously better to put the content relationship on page level as well.
We like the idea of supporting themes at the slice level so that pages don’t feel too heavily templated. To avoid updating each slice when we add/update a new theme, we’re exploring the “content relationship” approach that you mentioned—specifically what MacStadium shared in the Prismic Meetup (timestamped video).
If there's a different approach we should consider (or if Prismic is working on a more productized approach to themes), please let me know!
You raise a good point about how using variations to control multiple aspects of a slice could very quickly multiply into a mess. I was initially surprised by your suggestion to use variations for controlling custom/reference rather than layout—especially since variations are visually presented so well to the end user.
Thinking more about your suggestion, though, it makes sense to me: if the layout differences are simple (ex: left/right/center) and don’t affect the other fields, then that could just live as a select field without complicating the editor experience.
For the scenario where we sometimes want to use a slice for reference content and sometimes want to use it for custom content, is there any other approach (aside from variations) that we should consider?
We want to be Prismic’s next big success story, so please share any advice that you can!
As far as I know there's no other implementation of theming in the works right now, other than variations. But as mentioned, I think the content relationship works really good for theming at scale.
For the slice with either reference content or custom content, the only other solution I can think of is just making two different slices. But to me, variations sounds like the go-to-solution for this.
I really like that you think things trough thoroughly before rebuilding, that paves the way for success!
Thanks again for sharing perspective, Sam! I'll try to circle back with where we land on this. Our team has a lot of cleanup to do, but I'm hoping that we can someday show off our hard work as a "site of the month" at one of the Prismic meetups
