[RelationshipList] A field for a relation-many that display a table

[Nikodermus]

Why

The idea behind this, is for some fields with large relations to many, text chips are insufficient and hard to consume. That field display can grow out of control and doesn't provide detail if needed.

How

This would display a customizable table, with special support for links and booleans. For a more in depth explanation of the customization see packages/fields/src/types/RelationshipList/README.md

What it looks like

Before merge

• Pray you guys will think this is a good idea
• Revert auth changes in demo/blog
• Run changeset

[changeset-bot]

💥 No Changeset

Latest commit: ce3db18

Merging this PR will not cause any packages to be released. If these changes should not cause updates to packages in this repo, this is fine 🙂

If these changes should be published to npm, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[MadeByMike]

This idea is great, but I think rather than making a new field it would be better to have options on the relationship field type to choose different presentations.

What do you think about that?

[Nikodermus]

Sure sounds great, if the option inner field is present it should automatically take the table presentation

I'll be working on this 😁

[JedWatson]

I like this.

I'd recommend specifying an explicit option for our relationship fields, i.e

{ type: Relationship, ref: 'User', displayMode: 'table', columns: ['name', 'email'] }

That new option would default to select for the current behaviour; setting table would use the new component & graphql query logic; and it leaves us with room to implement other display modes in the future as well.

I'd also like to call the option that specifies the data to display columns because that is consistent with the list view.

We'll also need to pull the column views for the fields specified by columns from the list that's on the other side of the relationship as per how the List view works, rather than hard-coding assumptions on how to render different field types in the table (e.g how there is currently a special case for "boolean")

@Nikodermus tbh this isn't going to be a small amount of work or particularly simple (I'm sure there will be more things to do as you get closer) but I'm really happy you're taking it on & will keep advising as you go if you're up for it!

[gautamsi]

It may also be helpful to have it expand to table (configurable isExpanded) and minimize to regular select. Thoughts?

[Nikodermus]

I think changing from the regular select to the table would be too agressive for the user, I think we should keep one look so we can handle in the list only

[Nikodermus]

Moved to #2885