[IMPLEMENTED] Possible to embed one content type inside another?

Is it possible to embed a content type inside of another content type?

For example I have a schema of “page-header” and want to use it on some other schemas like “homepage”, “about-us”, etc.

I’d like to be able to embed the page-header content directly inside the homepage/about-us content rather than referencing free-standing content. Basically, I’d like to be able to re-use the schema in other parent schemas but don’t want the content itself to clutter up the library since in this case the content isn’t meant to be re-usable.

It’s kind of similar to this request ([IMPLEMENTED] Button to create & add content to an array), but the content is embedded rather than a reference. Btw I don’t see the new button that would allow this feature. Is it available on the latest docker image?

Thanks for all your work!

Makes sense, but is not implemented yet. The button is in the references dialog.

Ah ok. I see it on the docker image tagged dev. Do you know when you expect to include it in latest?

Very soon, I just want to keep the RC running a little bit to get rid of all bugs and then will release. Perhaps on friday.

Would be a very useful feature. Please consider also allow embedding schemas in arrays. Similar to components in Strapi or Storyblok.

I am still not 100% sure how this would look like, because for me it only seems to be a usability feature. Either you link a content or you have the fields in your content.

For me, it also about how to query this content. With components, it is similar to how Squidex arrays work but with dynamic schema per item.
If you trying to emulate components with linked content you may end up with bad performance since you need to load the content item then load all references, references of reference, etc.

If you have a reference you can define which content items are allowed. These references can be resolved with GraphQL. In GraphQL it means one extra call to the database, for all references in your result set together (per level). So I don’t see a performance issue here.

It works if you know the structure of the content graph in advance but may be a pain when this structure can be highly dynamic. What if you have a set from 100+ components, some of them can be nested in each other, and basically any of these components can be referenced from the root entity? What if the nesting level is also dynamic?

And also editor experience may be much better. Let’s say you have a schema for a checkbox. You don’t want to have a list of all checkboxes on your website, you just want to embed a checkbox into a higher-level component, let’s say form. When you no longer need a form on a page you want to delete it along with the checkbox and any other inner components because they don’t really have any meaning outside of the form.

I would really love to see something similar to the Storyblok experience. Don’t get me wrong, I don’t want to push, I understand that you have a lot of other features in your backlog and I have no idea how complex this one could be. But in my opinion, the components feature will bring the overall Suidex experience to the next level.

Makes sense. But I have to think more about this. Somehow you can implement this with field rules already.

I had a look to strapi components and I understand the concept well now, but how would you deal with localization?

What issues with localization do you foresee?

Sorry, for the late response. What I mean: How should it behave when you have a localize field that embeds a schema with localize fields? It could become very complicated.

I finally work on this feature now. The goal is to implement single item components within the next weeks and then array of components. One challenge I am facing is the graphql mutations. Not sure if I can support multiple component types here.

I’m not sure if it makes it any easier but I think embedding schema in the localized field could be just banned since we can localize fields in the embedded schema itself.

The plan is not to allow localized fields in components. It makes it soo complicated, also the json structure becomes a nightmare then.

Just wanna share the current progress:

When you create a new schema, you can select whether the schema should be a component. Components are not visible in the UI. I am not sure whether I am going to block API calls as well, as it is a lot of work without that much benefit. It just adds a lot of extra checks everywhere.

When you add a component field to a schema you can choose the target schemas: Any schema can be selected, even schemas that are not components.

In contrast to references you have to define the schemas explicitly. Not sure if I am going to change this.

In the content editor you have to select the schema. If only one ID is configured, this schema is selected by default.

In this case we have a component with a single number field (required) and an array

I have a working Beta now. Will do a little bit more testing and then merge it in master today. Then it can be tested.

A beta is available with dev-5946

This topic was automatically closed after 2 days. New replies are no longer allowed.