I'm happily using prismic and the slice machine, I really love it, but from time to time I have a slice that I'm just not sure how to model, because it kind of needs some nested logic.
I really appreciate you bringing in the repeatable groups feature to have multiple repeatable groups in a slice, that already solved quite some issues, but here's my remaining one:
So what I have (in the design) is a list of let's call it categories, this is a repeatable group. Now I kind of want to have a title field in each group, but then I need another repeatable group inside the group to have a list of images. I can't find a way to do that currently. I understand that endless nested repeatable groups is probably not something good to do.
But I'm not sure how to best model such a slice otherwise, to stay flexible and the client can later add or remove groups.
I know that I could do two separate repeatable groups, but I think that's not intuitive for the client and also everyone would need to make sure that the separate groups items fit and are in code combined. What if there are 5 titles, but only 4 lists of images for example?
I theoretically could create another slice just for one item that has a title and a list of images, but then I would need an option to make a slice selectable as field in a repeatable group in my main slice.
Nested repeatable groups are indeed not currently doable in Prismic. But there may be other ways to achieve what you want! Just so we're on the same page, you'd want to be able to repeat category, and those categories would have one title and repeatable image fields? Like this:
├── Repeatable Zone
└── Category
├── Title
└── Repeatable zone
├── Image
├── Image
├── Image
└── Category
├── Title
└── Repeatable zone
├── Image
├── Image
├── Image
If so, an alternative for what you're trying to do could be to create a custom type for what you're displaying inside the category (with a title field and a repeatable group of images), then use a Content Relationship field in the category. In order to access and display that content, you can then use GraphQuery to retrieve the linked document data.
Like this:
├── Repeatable Zone
└── Category
├── Content Field Relationship
And the Custom Type:
├── Title
└── Repeatable zone
├── Image
├── Image
├── Image
That makes sense yes, and it's the structure I need.
However, managing content for inside a slice somewhere else (as content type, same hierarchy as a page) and named completely different (slice <-> content type) is not something I would give a client or editor, think that's just too confusing.
Would I would love to have is referencing another slice instead of a content type, then I could do what you proposed, but stay inside slices (obviously there's currently no way in the admin dashboard to edit something like this). Maybe for the future an idea to create a space to add something like reusable blocks, that then could be referenced in slices (would love to see that).
If there's no other way, that's a bit sad, because I think two nested hierarchies are happening in almost every project I have at least once. More than that is very unlikely I guess, but 2 levels would be nice to create something like this.
I guess the best thing I could do currently is then something like:
├── Repeatable Zone
└── Category
├── Title
├── Repeatable Zone
└── Category Content
├── Image
and then match them in the code, hoping that the client manages to keep the same number and order of repeatable zones
not would I would ideally choose to do, but then at least everything is inside the slice together
I think it's pros and cons, with the right nomenclature it might be easier to explain that the page has content "blocks" inside them and everything inside a category is its own block, which would avoid potentially page-breaking bugs if they don't have the same number/order of repeatable zones. But what you're saying makes sense, if your priority is the ease of having everything on one page so your client has a better experience that would be one way to do it
Nested groups or Slices have been a long-requested feature and we understand the need for it from you and other users' use cases. This is something that's being worked on and thought about. Our team is looking at ways to make this work in the best possible way:
Thank you for your feedback, and feel free to check out that thread, you may find some other ideas to make your project work in a more efficient way for everyone involved!
In the process of designing the solution while talking to developers like you who use Prismic, we realized that groups within groups are complex and do not align with our vision of creating the simplest page builder for marketing websites.
and like others, I have to disagree, I don't know why groups within groups would be complex, like mentioned 2 levels of nesting are pretty much needed for almost every normal website and yes, you said you focus on the 80% of standard use cases, but then I just have to HOPE that my case is covered? how can I sell the client a cms when I don't know yet if it's capable of managing their content
think that's not a good direction to go honestly, and if it's not possible doing groups within groups because of other reasons like it could indefinitely expand and cost more (money? bandwidth?) or is not manageable in the admin editor, then please be honest about that and say that
you want to create "the simplest page builder for marketing websites" but that means not having to send editors to custom content types just for adding some content that should live inside a slice ON the page, please keep that in mind
I love the product, and I love and appreciate the recent updates in the whole product, but I need to know that the cms is capable of managing all my use cases BEFORE the project starts, and not hoping that I somehow can model it via some hacks, that's just my honest feedback
I'm Côme, I'm product manager for the developer tools team at Prismic. I wanted to share some additional details here.
We indeed want to make the easiest page builder for marketing websites. But that doesn't mean we want to ignore complex cases as the one you shared. Because we know they exist and come quite often.
But we believe that very often these use cases can be solved in a more elegant way, providing a great editor experience, than by adding an "all in one" generic feature.
Here your example is perfect. The items you want to repeat inside the categories are actually just images. Said differently you want to make lists of images into a list of categories.
This use case of repeating images, whether it's in a group field or not, is super common and we believe we can adress it specifically.
Not coming with a final solution here, just ideas, but what if you could simply do this?
``
└── Category (Group field)
├── Title (Key Text field)
├── Image gallery (Image field - repeatable)
that's the most dynamic version I can create which is still ok'ish for the editor because it's all in one place, but do I like it? no
there should be no need to add a row number and also the title and images should be together
looking forward to what you come up with, pretty sure it will work somehow, the development of the last months made me very happy, and I hope this will somehow be added so I can be more confident to choose prismic for clients
