User Research: Relations in Strapi

[sam-pires]

Hello Strapi community

I am Sam, I work in the product team at Strapi and I need you

With @Raff, we are launching some research on the use of relations in Strapi. The goal is to better understand how you use them, what are your use cases, the recurring pain points you encounter, and how we could improve the creation and use of relations in general.

Here the term relation refers to any relation created between two collection-types and their types (unidirectional, many-to-many, etc.).

We want to put ourselves in your shoes.

Feel free to share anything here, it can be about something that annoys you every day, a fun story about that time you tried to create a Strapi project for a fun use case and ended up creating weird relations, anything
It’s open to developers, project managers, content writers… everyone.

We are also planning some interviews to get more detailed feedback. If you are interested in participating let me know here or by DM.

Cheers

[gustavpursche]

Hi Sam,
the main thing about relations, which are frustrating in day-to-day work are the following:

• relations can only be displayed in the side column. We have a content type called actions, which have a location (input text field), but can be also connected to a group, which is active in a certain city. In this case it would be nice to group the relatoinial input field and the text field for the city visually together.

• another problem, which was already mentioned often in gh issues is, that a relation to something, that doesn’t have a title, is hard, because it’s only possible to show the IDs in the admin dropdown. In our case the have: Country → hasMany → Federal Countries → hasMany Cities → hasOne → Group. The groups don’t have distinct names, but relate to cities. Another content type, actions, can be organized bu groups, but currently it’s impossible to show the name of the parent city of a group in there.

• at the beginning it wasn’t clear to me how relations are sorted by default, but I think the way it works currently is very nice

• it would be very to be able to create UI element for relations easily, when, for example, you want to add a relation to something within the WYSIWYG field.

Thanks for asking!

[lovekaizen]

Relations are great, and the UI makes it really easy to see what’s happening.

Also agree with UI issues mentioned by @gustavpursche - Having them squeezed into the sidebar is a bit difficult, and you cal only see the ID so it’s not always easy to check the related content/record without opening it in a new tab. Some of this will probably be tackled in v4 but definitely would be an improvement to fix this and related content searchable and provide access to more fields, or maybe a “quick view” panel for the content.

Also got ambitious and built a raffle style game site called giveawayking.ng where people can log in and claim various giveaways. Every giveaway has many “claims”, claims also belong to users. But noticed some lag when fetching records. I think this is related to Knee error, but when fetching thousands of user claims for example, the server really struggles, working around this using a claim field and pushing all user IDs to an array as a temporary fix. But it would be nice to use relations for this all the way.

[TasosBak]

You can change the field that is shown for each relation. For example, I have a slug field for my headers and footers and I use this field to select the correct header/footer instance. To change the field:

1. Go to Configure the view
   

2. Select the field whose shown field you want to change

3. Change the Entry title

   

[VMonsch]

Hey @sam-pires, thanks for the thread. Relations are key in most content models and deserve the attention.

On the tech side I don’t have a lot to say, everything works as expected.
The one thing I’d really like to see is being able to exclude related entries when querying the APIs and being able to specify a depth level (i.e. 2 relations away), capped by a global setting for example to optimize performance by default (and warn of the risks when editing).

On the admin side these are the things I’d love to see :

• Relations getting copied when creating a new localized entry (i18n)
• Being able to filter relations more than by the displayed field (we could keep the way it works now, and add a filter button which would open a small popin to help pick and choose the entry we want to link with more options)
• Being able to sort relations (this is really important as well in some content models)

Also being able to force contributors to add a relation would be nice, like “posts need to have a category to be created”, don’t think this exists for now.

I have two projects which rely heavily on relations, including one for which I have a small entity relationship chart. I’d be happy to walk you through them or answer more questions if needed.

[pravodev]

Hey @sam-pires.
i’m new in strapi. i want to ask you.

i have category collection with field name and type,and in other collection i want to add field relation to category with condition the type is promo. how can i do this in strapi ?

thanks in advance.

[flow]

I’ve been working with Enterprise CMS for the past 7 years - Sitecore, Adobe, Magnolia, Contentstack… And I’m really enjoying Strapi for personal projects and pocs - even thinking about recommending it for some clients.

The things I tried to do and can’t:

• As mentioned before the side column display limitation plus not being able to easily make it required makes it hard for contributors since it is easy to forget to add something important, like a Category or Author for an Article.

• I use components paired with content type relations a lot to take advantage of dynamic zones + content reuse. But I miss the ability to point it to single-types. For example, I have a Newsletter single-type. It would be great to have a component named also named Newsletter ponting to it and be able to reuse that content across dynamic zones. Or maybe the ability to add a single-type to a dynamic zone.

• The last bit is probably something against SQL principles, but is something that I miss greatly from other CMS experiences - it would be great to have a “hasOne” relation to more than one content type. Use case: I could create a component named “internal link” having a field “page” with a relation to anything, so I can use it to link to my homepage, a blog post, a contact page, a product page. The only way to do something like this right now is having a collection of “pages” with types. But it can get messy in a complex project.