Use Dynamic Zone inside component

[wac2007]

Hello people,

I'm trying to add a Dynamic Zone inside a repeatable component but this option doesn't show inside a custom component.

Here what i'm trying to accomplish:

The options:

There's a way to "unlock" this feature or this isn't possible yet?

[derrickmehaffy]

Hello,

I see you are wanting to ask a question that is not really a bug report or a feature request, questions should be directed to the following places per the README.md:

• Stack Overflow
• Slack

For now I will mark this issue as closed, we try to keep Github clean and only for bug reports and feature requests unless there is a technical discussion that needs to happen before an RFC needs to be created. However in all 3 cases there are templates to be followed.

If you have questions or believe this was closed in error do feel free to reply.

[soupette]

@wac2007 for UI reasons we have limited the number of nested components to one. It means that you cannot create a component inside another component which is already embedded into another one.
However, the back-end and front-end code works for n levels of nested components so you can still manually create them directly in the files.

[MartinN3]

Even if you add dynamic zone inside component - it just doesn't seem to work. Not in admin nor in API.

In admin only input type text gets rendered.

And in GQL mutation is created - it cannot be mutated - it won't pass validation.

So i would say that having dynamic zone in component is not possible for now at all.

EDIT: API mutation works as expected, that means dynamic zone inside component is indeed possible. I will elaborate on my GQL mutation to validate correct implementation.

[Riya3006]

@wac2007 for UI reasons we have limited the number of nested components to one. It means that you cannot create a component inside another component which is already embedded into another one.
However, the back-end and front-end code works for n levels of nested components so you can still manually create them directly in the files.

can we add dynamic zone also inside a component through backend?

[odididi]

@MartinN3 EDIT: API mutation works as expected, that means dynamic zone inside component is indeed possible. I will elaborate on my GQL mutation to validate correct implementation.

Any hints on how you got this working?
I manually added a dynamic zone field in the model definition, however i can create anything.
Also get a This dynamic zone is not available error on the admin UI

[rlvk-vk]

@MartinN3 EDIT: API mutation works as expected, that means dynamic zone inside component is indeed possible. I will elaborate on my GQL mutation to validate correct implementation.

Any hints on how you got this working?
I manually added a dynamic zone field in the model definition, however i can create anything.
Also get a This dynamic zone is not available error on the admin UI

Yeah me too. Would be great with a solution to this, as I really need 1 level of nested dynamic zones for my current project.

[Sylvanik]

Does someone find a solution about this problem ? I see that someone solve the problem on a forked project 5 days ago.

[soupette]

Enabling the usage of a dynamic zone inside a component is not a feature we want to enable in Strapi.
@Sylvanik you can either fork the package like @benderillo did or customise your app to enable this feature.

[benderillo]

@soupette do you know if there is any plan to implement what @alexandrebodin proposed a while ago in this ticket: #5124 ?
I feel like this is more solid approach that would help many people steer clear of nesting DZ inside components. I would try and do something like this on my own fork but I am a backend dev and any frontend work is extremely painful for me because it takes ages to traverse through the source code in order to understand how things work together.

[soupette]

Which solution are you referring to in the issue?

The one that would allow creating an entry from another entry?

[benderillo]

Yes, that't the one.

alexandrebodin commented on 10 Apr 2020
@JabStrapi @Aurelsicoko I think we shoul offer support for creating relation entries directly inside the Content Manager creation view at some point so the user don't start overusing componnets instead of relations

[soupette]

For the moment, we don't plan on adding this feature to the CM we are currently actively working on other features like internationalisation and then the V4.

[ValterSantosMatos]

Hi @soupette, first of all keep the good work, however I need to mention this is a real showstopper for us / our company to adopt Strapi as a headless CMS, we simply can't build a component system on our FEs that mirrors what we have on our CMS, kind of what storyblok is doing (https://www.storyblok.com/). @benderillo we will borrow your fork and see if we can still continue with Strapi.

[benderillo]

@ValterSantosMatos keep in mind that you still need to add the DZ in json file first. The change I made on my fork is to make DZ work in the Admin UI after it has been added in the json file. Keep in mind also, that the change was quick and I have not spent enough time investigating if I accidentally broke something else.
After making that fork I realised that I can't really go with the approach and what I really need is much more user-friendly UX for creating type entries for relational fields in content manager plugin. But it doesn't look like this is coming any time soon.

[choychris]

I am also looking for this feature.

[Aurelsicoko]

Could you all share more details with us about the use case of having a DZ into a component? Feel free to share your content-type structure, I would like to know more about why there is no alternative in terms of content structure.

[benderillo]

@Aurelsicoko I initially wanted it so that I can have a user-friendly content authoring experience for Online Course creation with Strapi content manager plugin.

A Course collection type may have many Chapters.
Each Chapter may have many Lessons.
And each Lesson can be either a Lecture or Survey or Quiz.

An Educator needs to be able to open an Editor for new Course(type entry), type in a title, pick a thumbnail, and some other info.
Then normally, they would have a visual component/button to add a Chapter which would add an input component for the chapter to the Course editor window (pretty much like when you add repeatable components now).

And when inside a Chapter editor widget, the educator would click another visual signifier to add a Lesson to the Chapter. Upon clicking this signifier(button/icon) the educator should be presented with a choice of type of the Lesson to add.

As you can see, this workflow currently impossible in Strapi when you go with normal relational types. But doable with the components once you allow DZ in the component (this is needed for picking a type of the component to insert as a Lesson).
In my case it is not about content structure but the editor UX that I require.
Basically, what I am saying, content manager UX for working with relations is very poor at the moment (limited to a tiny drop-down lists tacked away to the small fixed position panel on the right hand side of the editor). A user can't move those around (like we can with other type fields when customising the view) and can not create a related entry without leaving the editor.
Building ones own editor UI for authoring with all these capabilities is a significant development investment.
Components give you all of that freedom.

[derrickmehaffy]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/add-entries-to-multiple-related-collections-in-one-view/2891/2

[Aurelsicoko]

@benderillo Thank you for the explanations! As you mentioned, it isn't a content structure limitation, in your use case, everything is possible. However, the content editing experience is bad because you have to move from the Course, then Chapter, then Lesson edit views to write and build an entire course.

For example, a possible solution would be to allow you to create a very advanced and custom layout for the Edit view of a Course. I would love to have more use cases like this one to ensure it's our role as a CMS to handle such as specific use cases or is it on your side to develop a custom view by yourself to be able to contribute this way.

[drazik]

I have the following use case for which I was planning to use repeatable components with dynamic zones:

I have a single type for my home page. On this home page, I want the user to be able to add as many sections as they want. Each section can have a title and some content. The content would be a collection of items that can be either some rich text or a CTA. So I made a RichText component with a rich text field and a CTA component with label and URL fields. I then made a Section component with a title field and I was planning to use a Dynamic Zone for the content field so the user can choose between RichText or CTA for each part of the content.

I think I can use collection types and relations for that. But it leads to very poor content editing experience for my users as they will have to write each content part isolated, then add relations in the good order, without any context.

[Aurelsicoko]

@drazik Your use case makes sense! You could also create a Section component with two fields (title, content) and put it within a giant dynamic zone to divide it per section. I know that visually speaking it could make the contributing experience harder but from a content structure perspective it's the same. FYI, I've shared your use case with the team as it's the first time it would make sense to have a DZ > Component > DZ (Page > Section > Content blocks).

[drazik]

If I understand your proposition correctly, it doesn't exactly sound the same as my use case. I want a section to have a single title and and collection of "content parts". If I create a Section component with title and content fields and then put it in a dynamic zone, I will get a collection of Sections. Which I would also get if I use a repeatable Section component 🤔 .

[FitFingers]

... it would make sense to have a DZ > Component > DZ (Page > Section > Content blocks).

I second this; this is how I build all my CMS websites.

In my case, I have a layout that uses a vertical page flow where the top-level component in a Page is always a Section. This gives the user a selection of options (such as the section heading, icon, anchor link, background, fluid/fixed width, vertical space etc) that, if added to each component individually, would really clutter up the individual component options (think of all those options unnecessarily added to a rich-text component where you only need a richtext field).

[Krislunde]

I frequently run into annoyances where I need a DZ inside a component. For example, I tend to model content sections so that clients can use Strapi as a CMS, and needed to build a "Popular products in [multiple store fronts]" section. The storefronts had separate collections for the products they offered (because of unique suppliers), and thus I wanted a DZ wherein the component Featured Products has a DZ with multiple optional Relational Fields for different content types.

Another recent example is: I was building a main menu single-type with a dynamic zone filled with menu components for easy client use. The Menu DZ had components such as "External link" "Internal Link", "Dropdown submenu" (here I'd like a sub DZ with new options for internal link (relational), external link, etc. I wish internal link and external link could be combined, but I cant have nested dynamic zones so I need to duplicate functionality since I cant nest optional relational content.

To make it worse, I'll have to make duplicates of internal link and external link components if I want to add other content types other than generic pages, such as links to articles in the main menu, or store fronts.
External link, Internal page link, internal article link, internal shop link, dropdown submenu with only internal pages, dropdown internal submenu with only internal articles, etc.

Strapi really needs DZ inside component functionality.

[ico85]

Hi @soupette, first of all keep the good work, however I need to mention this is a real showstopper for us / our company to adopt Strapi as a headless CMS, we simply can't build a component system on our FEs that mirrors what we have on our CMS, kind of what storyblok is doing (https://www.storyblok.com/). @benderillo we will borrow your fork and see if we can still continue with Strapi.

It really is a show stopper because it's such a common usecase to nest components. It makes strapi useless.

[liamb13]

Another use case:
Ability to use Dynamic Zone's to create a grid structure.
It'd be great to have a component called 'section' which contains some fields; 'class', 'background', 'full-width', 'title', 'column-count'
Within 'section', dynamic zones would then be used to essentially place columned items.

Why not just have multiple dynamic zones for every combination of lockups? Here are just some potential components that could be used as a column:

1. Video Embed
2. Rich Text
3. Image
4. Sign Up Form
5. Social Icons

To do even just 2 column components for the above is 25, or with some adjustments 10 (using repeaters, and a ltr/rtl field. However, if you want 3 columns, it quickly gets up to 625 combinations, or again with some tweaking 70, or getting really hacky with a bunch of repeaters and 'order' fields maybe 5, however, if you're using Graph QL and you never use 1 of those 5 lockups, the frontend won't develop or build.

Worth noting in this example it might not even require DZ -> Component -> DZ and instead could be Repeater -> DZ

[lansolo99]

@liamb13
This is exactly what I'm looking for : be able to build a simple flexible layout using nested dynamic zones.

I did that very often using ACF with Wordpress. I'm looking workarounds to get this running.

I'm eager on seeing this feature released, because Strapi has a lot of capacities otherwise..

[derrickmehaffy]

cc @yanniskadiri

[liamb13]

@derrickmehaffy Any chance of this issue reopening, or at least be reconsidered internally? It's been almost two years since it was initially closed, and I think it's clear that many companies consider this a vital feature in order to adopt Strapi, mine included. We've been trying to work with it, but it's proving to provide less than satisfactional ux for our end users.

You know what, yes I will reopen it. :) Since this is largely related to #11319

As mentioned in the related issue, I'm not a decision maker on either topic but I can (and have) brought it up with the relevant teams.

While I understand I’m not adding much more to prior discussions. Can I quick state, seeing that email notification has given me excitement and appreciation for the Strapi team. While a feature we’ve all asked for for a little while. Knowing it’s back in discussions brings me joy, we may sometime soon see this feature built into the UI.

It’s an amazing community and this drive will surely bring more users back to the Strapi ecosystem.

[wesleyguirra]

@derrickmehaffy Where we can follow the status of this?

[derrickmehaffy]

@derrickmehaffy Where we can follow the status of this?

The only place is here, at the moment I have not seen a confirmation from our product team that we will do this. It's still being considered at this time.

[Nuli18]

@derrickmehaffy Where we can follow the status of this?

https://portal.productboard.com/strapi/1-roadmap/tabs/2-under-consideration

I've seen this and it could be a good alternative to make the product team listen to this feature request.

[derrickmehaffy]

@derrickmehaffy Where we can follow the status of this?

https://portal.productboard.com/strapi/1-roadmap/tabs/2-under-consideration

I've seen this and it could be a good alternative to make the product team listen to this feature request.

The product board isnt entirely up to date, but during StrapiConf we will be announcing our new public roadmap and the public portal that will allow every to suggest, comment (publicly), and vote on feature requests, enhancements, ect.

The product team is well aware of this request and it's sister one about nested components.

[wesleyguirra]

Sorry if I appear somewhat redundant and rude, but as people have said it's a big block for a lot of people using Strapi as the main CMS, i.e. I'm currently using it, but currently searching for an alternative to solve this problem, a lot of people are ready to help here, including me, but we are almost lost in this discussion that takes more than 2 years now.

Please let us know, how we can push the product team to listen and ask this request, as this doesn't seem to be too complicated at all, and also should be prioritized as many users are cogitating to change their CMS tool away from Strapi due to this limitation.

[Fabioni]

Sorry if I appear somewhat redundant and rude, but as people have said it's a big block for a lot of people using Strapi as the main CMS, i.e. I'm currently using it, but currently searching for an alternative to solve this problem, a lot of people are ready to help here, including me, but we are almost lost in this discussion that takes more than 2 years now.

Please let us know, how we can push the product team to listen and ask this request, as this doesn't seem to be too complicated at all, and also should be prioritized as many users are cogitating to change their CMS tool away from Strapi due to this limitation.

Hey, did you find a good alternative to Strapi with this feature?
Storyblok seems quite nice but also expensive.

[ssyberg]

Sorry if I appear somewhat redundant and rude, but as people have said it's a big block for a lot of people using Strapi as the main CMS, i.e. I'm currently using it, but currently searching for an alternative to solve this problem, a lot of people are ready to help here, including me, but we are almost lost in this discussion that takes more than 2 years now.
Please let us know, how we can push the product team to listen and ask this request, as this doesn't seem to be too complicated at all, and also should be prioritized as many users are cogitating to change their CMS tool away from Strapi due to this limitation.

Hey, did you find a good alternative to Strapi with this feature? Storyblok seems quite nice but also expensive.

@Fabioni My last response to this got marked as off topic so I suspect they'll bury this one too 😆 but take a look at PayloadCMS

We're sticking with Wagtail for the time being.

[wesleyguirra]

Yeah I take a look, right now I'm still waiting for Strapi team to consider and implement a fix to this limitation as it will take less effort on our side here, but honestly as long it's not implemented we are moving away from Strapi we know that every change takes time, but c'mon 2 years, people saying this is a big limitation and being ignored, that's not healthy for a tool like Strapi.

[graphicfox]

Also tried to push Strapi for our client but this limitation made them decide against it. Is there any news or workarounds?

[wesleyguirra]

No news yet, I'm following currently and sadly it's not a top priority on the team board, even after a lot of people ask for this.

[dopry]

I needed this on my current project. We started on Wagtail which supports nesting with its StreamField and Blocks, which are analogous to DynamicZones and Components. I had some issues with Wagtail. It doesn't support GraphQL out of the box and implementing it requires writing a lot of boilerplate. It also doesn't treat SVGs as images, bu as documents with a separate media browser. Strapi totally won on those fronts and the overall look and feel and UX. The only reason we didn't choose it was because strapi's inability to implement nested dynamic zones.

In our component hierarchy, we define 3 types of components

• Sections - A top-level layout (grid, 2 columns, 3 columns, sidebar right, sidebar left, etc), 1 or more dynamic zones depending on layout requirements
• ComponentLayouts - a layout that can be nested inside a section (column, main with left floated aside, etc), 1 or more dynamic zones depending on layout.
• LeafComponents - structured content, no dynamic zones

The rules for our component hierarch design are as follows.
A Page is an entity with a body that is a dynamic zone that allows LeafComponents or Sections.
A Section only allows ComponentLayouts or LeafComponents in its dynamic zones
A ComponentLayout only allows LeafComponents in its dynamic zones.

For our use cases we don't need infinite recursion, just a few tiers are are perfectly happy with limitations that prevent infinite recursion. This is level of layout control is an essential need of our editorial teams. We weren't able to achieve it with Strapi at this juncture because nested dynamic zones are not possible at all.

[ssyberg]

It doesn't support GraphQL out of the box and implementing it requires writing a lot of boilerplate.

@dopry we're planning on using https://github.com/GrappleGQL/wagtail-grapple and in our initial testing it's been great, did you try that package?

[dopry]

It doesn't support GraphQL out of the box and implementing it requires writing a lot of boilerplate.

@dopry we're planning on using https://github.com/GrappleGQL/wagtail-grapple and in our initial testing it's been great, did you try that package?

Yes, but you need to explicitly specify which fields you want to expose to graphql and implement resolvers for tcustom blocks you develop. It's a lot of boilerplate. Strapi is far easier in this regard. There are significantly fewer development steps to expose a component to graphql with Strapi. Strapi is also written in react so we are able to reuse our react component library in the strapi admin to build inline previews. Overall tjoe enables a better editorial ux than you get with Wagtail. Wagtail has a react admin in the works, but it won't be released until at least August.

[yanniskadiri]

Thank you all for your comments. The topic is currently being discussed within the product team. Given our time and resources available, this issue will not be addressed before the second part of the year but we have it in mind.

[wesleyguirra]

Guys that need this, anyone want to pair with me to make it happen in a fork?

[Warxcell]

https://github.com/benderillo/strapi/pull/1/files ? This feature critical for us.

Use case is to have Layout category with components, for example 6x6, with left and right properties both Dynamic zone - so content editor could decide to put different components side-by-side. Or section component with Background (Media) and Components (Dynamic Zone) - so they can group together some components in same background.

So you could have

Collection/single type => (DynamicZone) Layout / 6x6 component => (Dynamic Zone) Section / Base Section component => (Dynamic Zone) Gallery Component or any other component

[benderillo]

@wesleyguirra @Warxcell you can look at the PR I made in the fork for Strapi v3 ages ago.
Although it was somewhat half-baked, not well tested and still required some tinkering in json before you could get UI in the dashboard working. But it can be a good reference to at least identify some places where the change needs to happen.

Unfortunately, I cannot lend a hand on this one as I have no capacity at the moment.

[derrickmehaffy]

Closing this in favor of: https://feedback.strapi.io/customization/p/dynamic-zone-in-components

We are considering this, if those who have commented are still interested in this can you please go log your vote on the feedback page (we are trying to clean up issues so we can fix bugs a little faster 😃 )