Nested groups. (Again)

[Vladyslav.L]

Hey guys,
I know that there is no way of using nested groups. Officially.

But I just realized, that it is actually works well, if add a group inside another groud on model.json:

[
  {
    "grid": {
      "type": "Group",
      "config": {
        "label": "Grid",
        "repeat": true,
        "fields": {
         ......
          "boxes": {
            "type": "Group",
            "config": {
              "label": "Boxes",
              "repeat": true,
              "fields": {...}
            },
          .........
          }
        }
      }
    }
  }
]

I just want you to confirm that this is a hidden feature or a bug and if I can use it in production.

Thanks

[cerrutti (Sergio Cerrutti)]

Thanks @Vladyslav.L for sharing this. It would be awesome to have this feature, I have to do messy content models because I can’t create nested groups, and it happens a lot.

[benjammartin (Benjamin Martin)]

Hi Vladyslav,

This was an experiment. We decided to not continue with it.

I recommend to not use this in production.

Instead of generic nested groups, we are building specialized fields. The idea is to solve specific content problems with the right tool, rather than a generic nesting system. For example, fields like repeatable link already follow this approach.

Could you tell us more about your use case? What are you trying to model? We want to help you find the best solution with what we have, or take your case into account for future specialized fields.

[Vladyslav.L]

Hello Benjamin,

Thank you for your response. I will no longer use it in production.

I am experiencing a problem when attempting to create a list of grids or a grid containing different types of content within grid items.

I am aware that I can use a group of content relation fields, but it is somewhat cumbersome to use them in that context.
Custom types and CR fields are suitable for combining different styles of a single type, such as grid item variants (tall, wide, dark, light, etc.) to be displayed in a grid.

However, in that case, I am forced to create a custom type for a single variant of a grid item, simply because I must.

Additionally, the primary issue with CR fields is the absence of a preview.

[benjamin.martin (Benjamin)]

So, you need a way to define lightweight, inline structures within a group without creating a full Custom Type and wiring it up via a Content Relation.

What you're describing is a real gap, and your use case is a good concrete example of it.
I'll make sure it's on our radar as we think about the next round of specialized fields.

[cerrutti (Sergio Cerrutti)]

Hi @benjamin.martin,

I think this feature would be prioritized. I'm building from scratch a huge website (custom plan) with 50 slices and maybe 20-25 content types, and I have problems in almost any slice to build the correct model because I can't nest groups. I've ben using the undocumented way to set nested groups (just one more level) and it worked great, but even with this trick is not always enough. Sometimes I would need 3 or even 4 levels of grouped content.

Current way to do this is to create more custom types for every card or portion of content, and then use relationships, but even this way it's impossible to handle it a lot of times.

So we are currently changing the visual design and UX to avoid more than 2 levels of hierarchy, in my opinion this the worst scenario for a designer and a developer, where content model is the blocker to build something, not any technical or business reason.

I know I don't have to use that trick for nested groups but it's the only way to at least save the problem in a few places and avoid the client to add new documents, the website will have more than 5000 documents in 12 languages, I can't say to my client: "You have to create 1000 documents and the only reason is there is no nested groups in Prismic".

Now if I start using cloud Type builder, I'm afraid nested groups can disappear, at least with local generation I can control what can I do with model building.

So, after building at least 30 Prismic sites, since a lot of years, long time before SliceMachine even born, I please ask you to take this feature and solve such a common problem for all people using Prismic. In my opinion, if you ask me, this is the only thing I could change of Prismic right now.

About your approach creating specialized fields (I guess you talk about repeatable fields like LinkField or ImageField in the future), these are great to improve the content builder UX, but not enough to model content, maybe I need to repeat number and currency fields for a list of prices in a list of cards, in a list of tabs, specialized fields don't help to build this.

Once again, thank you so much for all your work, Prismic is such a great tool and you're doing an amazing work.

[kris.bogdanov]

@cerrutti I'm with you, I actually decided to take the risk and implemented the trick suggested by OP in my production website because I needed it for my navbar.

But now I'm worried about migrating to the Type Builder, how can we be sure that the nested groups won't disappear. Because if they do, I'm definitely better to just sticking with Slice Machine for the time being until the team officially implements nested groups

[cerrutti (Sergio Cerrutti)]

I've checked Type Builder and nested groups are not shown in the UI, SliceMachine at least show them.

[kris.bogdanov]

Thanks for checking! So at this time we should definitely not migrate over!

[cerrutti (Sergio Cerrutti)]

I mean, I see nested groups, but not their children fields. I guess there is no problem to migrate since the model will be the same, but maybe if we save any change there, they just disappear, I don't think they are managing this since it's not official as they said.

I hope they will find a solution for us

[benjamin.martin (Benjamin)]

Hi,

Thank you for pushing on this

Can you share the one use case that's hurting mos, the actual slice and the nesting you're trying to model (e.g., prices → cards → tabs)? With that one example, I can confirm Slice Machine covers it and shows exactly where the current ceiling bites.

Thanks again

[cerrutti (Sergio Cerrutti)]

Hi again @benjamin.martin,

Thanks for the quick reply.
I'm going to show you one of the worst, my model should be like this (screenshot down below):

• Title [Rich]
• Cities [Group repeat]
  • Options [Group repeat]
    • Title [Rich]
    • Icon [Select]
    • Plans [Group repeat]
      • Title [Rich]
      • Description [Rich]
      • Prices [Group repeat]
        • Name [Text]
        • Value, currency, unit (some fields...)
        • Popular [boolean]
      • Footnote [Rich]
      • Footnote Icon [Select]

As you can see, only fields in bold are valid right now, and if you want, I can show you a lot of common examples where this is a problem. So the way it is now, I have to create custom content type for every City Option, and add slices inside for every Plan, or something like that, looks ugly but, imagine doing this in 12 languages and dozens of pages, creating not reusable content, only because the content model has no depth at all.

I hope you find this useful, thank you in advance.

[kris.bogdanov]

I'm sharing another very common usecase (which you can also see on the Prismic marketing website) - a navbar dropdown slice with multiple columns (and the links in the dropdown are not simple links with text, but also include subtitle + logo)