Relation field in repeatable component results in numeric accordion title

[devmlx]

Bug report

Describe the bug

When you create a repeatable component with only a relation field inside the labels on the accordion on the edit page show as IDs:

I would expect it would show the title of the selected element of the first select box.

Steps to reproduce the behavior

1. create a new collection type
2. Add a repeatable component
3. create a new component and only add a relation field to another component
4. Create a new item on the collection type created under Improvement/readme #1. Add a few elements in the repeatable section
5. Edit the item.

Expected behavior

I would expect the accordion header to have a textual title - in this case the first element of the select box. Similar to what happens when there is a text element in the component as per below

System

• Strapi version: v4
• Database: postgres
• Operating system: linux

Additional context

You may believe that if there is only a relation field inside the repeatable component I should not use a repeatable component for it in the first place. The reason we are doing it this way is because it turns it's not intuitive for the user to have the relation fields to the right and the regular fields on the left. It confuses them. That's why we are doing it this way.

[derrickmehaffy]

This isn't something we will work on if there is no textual field in the component, it's far too complex to nest down the relation and with many relation types you would end up with multiple components with the same title name. We use the component ID when there is no valid textual string in the component.

[strapi-bot]

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

https://forum.strapi.io/t/strapi-core-enhancement/15768/1

[cwray-tech]

Hey there, can I ask what this is for? (Components with only one related item) Are you trying to display only a set amount of related items?

[devmlx]

@cwray-tech Basically the main thing we are trying to achieve is to have a logical user flow. First we had the relation fields on the right as they are displayed natively but our users did not find it intuitive enough and got confused. In most of our data entry scenario's there is a logical order of fields. This means you enter a text field on the left - then you go to the right to add one relation - you go back to the left again to add some more items - and then on the right you have to edit another relation field. To smoothen this UX we've just moved all the fields to the left - and with relation fields to make that possible we had to wrap them in components.

[cwray-tech]

@devmlx I see.
In that case I wouldn't recommend that approach. It will end up making the project harder to maintain in the future.

I think a better way of solving this would be to update the layout itself, versus putting relationships in another component. I'm not sure if that is possible though at this time.

[devmlx]

@cwray-tech tnx - I've considered that as well. Actually as a solution it would be OK for me. It could be integrated into the current page designer where you can drag and drop fields. I have the feeling though it would have a much bigger impact on the strapi system and hence would take much more work to implement. I had the feeling this would have been an easy fix because the HTML element that is needed for the title is in the DOM and only few pixels away... but guess I've underestimated that :-).

[cwray-tech]

I'm not saying that your idea is not easy to implement in general.. The issue is that I think going forward you will regret doing it that way for maintainability reasons. I would push back on the client. Really, I think the right sidebar is quite intuitive and over time they will get used to it. "Unfortunately, the cms doesn't allow customization in this manner, but we can offer training to help you get started editing content." Is something I would say to my client.

You could also make the relationship required so that if they don't select items it will give them an error when they try to save/publish.

[devmlx]

@cwray-tech tnx I was no suggesting that but referring to the first response in this thread from a strapi engineer that highlighted this is something too complex to consider. Naturally I've tried the pushing back strategy - as I also consider the sidebar to be OK. This worked initially - and we even did a pilot with the sidebar set-up. Unfortunately it turns out to be a real annoyance and that keeps coming back in user feedback hence my attempt to find a solution (other than migrating to another headless CMS).

Can you explain to me your concerns regarding maintainability? My thinking is that if we can solve it by adapting some limited code in Strapi core and contributing that - or alternatively by developing it as plugin - maintainbility does not have to suffer that much? If it requires a lot of custom code changes that would not be accepted as core contribution and are not possible to develop as plugin I would likely abandon the idea because of maintainability reasons indeed.