DataViews: stress testing `primaryField`, `mediaField`, and `view.fields`

[oandregal]

Description

I'd like to share some inconsistencies I've noticed with the primaryField and mediaField:

Step-by-step reproduction instructions

• If primaryField or mediaField are not provided, grid & list layouts look weird. The "slots" for them are rendered, but empty.
  • How to test: set defaultLayouts to defaultLayouts={ { table: {}, grid: {}, list: {} } } in storybook.
  • What to do about this?
    • Make them "required". For example, if they are not provided, do not render that specific layout.
    • Hide that slot if they are not provided. This makes the layout look weird as well (grid without image doesn't make much sense, list without image also looks weird but perhaps is more acceptable not to have media).
    • Leave as it is.

Layout	With primaryField and mediaField	Without primaryField and mediaField
Table
Grid
List

• If view.fields is provided but the mediaField is not listed, the mediaField still rendered. However, if view.fields is provided but the primaryField is not listed: the table layout doesn't render it, but grid & list layouts still does.
  • I feel 1) we should require both primary&media to be part of view.fields to be rendered or 2) always rendered them (regardless of whether they are part of the view.fields or not). The mix is confusing.
• What's the role of primaryField in table view?
  • I don't see any difference in storybook with/without it. In edit-site, it gets different styles (links without styles, it's bolder).
  • If we keep it, it should work like in any other layout (and like the media field): it's rendered whether or not is listed in the view.fields. In this case, I wonder if we should always rendered it in the 1st position or respect the view.fields position if there's any.
• The mediaField is not available in the view config while the primaryField is. I'd think the mediaField should be visible but not hidable.

[oandregal]

cc @youknowriad @jameskoster @jorgefilipecosta @ntsekouras for thoughts. This stems from this other conversation.

[oandregal]

Additionally, perhaps the "special slots" (primary/media) should be communicated in the property panel so users learn why they cannot be hidden.

This is something James touched upon here (ignore the combine fields logic for now, note the "Primary" in "Title"):

[youknowriad]

I'm in the camp of treating all these "fields" properties the same and layout specific. In other words: I think the current layout property in view is to be removed and we should flatten everything and layouts shouldn't necessary keep the fields when you change.

• Table, can have columns (or fields like today) and marking one field as mandatory is fine (bold and maybe have a special click to action later). Also table layout can have combined columns which doesn't really make sense for other layouts at the moment.
• List has a media, primary, badge fields, other fields. For instance the badge and other fields can be reordered separately in two separate sections.
• Grid has media, primary, column fields and row fields. Column and row fields can be reordered separately and not mixed.

I guess what I'm saying is that by trying to make all the layouts fit into the same model, we end up with a not ideal setup for any layout.

[oandregal]

I'm in the camp of treating all these "fields" properties the same and layout specific. In other words: I think the current layout property in view is to be removed and we should flatten everything and layouts shouldn't necessary keep the fields when you change.

I agree with the idea of having layout-specific logic.

However, I'm not sure what would be the actions steps after your comment (perhaps none?) 😅

I guess my question is: how do you judge the current situation? Specially the following items:

• Media field not visible in properties panel while primary is.
• Primary field is required as part of view.fields to be rendered in table layout, but not others. I guess your point here is that it's fine?
• Do we do something different when primary&media are not provided for grid/list or the current situation is ok?

[youknowriad]

Media field not visible in properties panel while primary is.

• Primary in "table" is different than "primary" in other layouts IMO.
• In Table, primary should be shown with the other fields to be able to move them around...
• In List and Grid, media and primary fields should be treated the same way: either we render them but in a separate place (you can't really move them) or we don't render them.

Primary field is required as part of view.fields to be rendered in table layout, but not others. I guess your point here is that it's fine?

I'm not sure I follow here. I can see table layout working without any primary field.

Do we do something different when primary&media are not provided for grid/list or the current situation is ok?

I don't have a strong opinion here. Making them mandatory (rendering nothing) would be fine for me for these layouts. Current state is not ideal but also not that bad :P. I mean the developer will quickly figure out that in order for these layouts to work well, they need to provide a primary and media field.

[ntsekouras]

For primaryField I think it makes sense to keep it as a concept but for every layout (so part of the view) and every layout should handle as it seems fit(styles, position or whatever). DataViews should have at least one field that cannot be hidden and convey some important info for users to identify the entity they are seeing.

For me mediaField could also be removed from layout config and be top level key at view object, but optional. Then each view could handle the rendering if provided in a different way, but it shouldn't be mandatory, at least in our current views. I don't get why a grid view or the list view would require a mediaField. They both have value without one too.

If a specific (new) layout would require something it could just not render anything if not provided.

[jameskoster]

Making them mandatory (rendering nothing) would be fine for me for these layouts.

Is it possible to provide a fallback for mediaField rather than rendering nothing? It would be good to avoid this awkward overlap in grid layout when there's no thumbnail/preview:

Similarly the placement and appearance of the actions menu looks very odd if primaryField is not rendered as noted in the OP. We should avoid that if possible. Perhaps we could fix by moving the actions button to the top right (similar to the checkbox):

---

Agree with Nik that it should not be possible for users to configure options so that they end up with an empty table. I don't have a strong opinion about whether we use primaryField for that, or add some logic in view options to disable the ability to hide the last visible field, or both.

Practically, if a primaryField is supplied, it probably makes sense to force it to be visible? Hiding titles in the pages table isn't something I can ever imagine a user wanting to do.

---

Like table layout, I don't think it should be possible to configure List layout so that no fields are visible. Perhaps the same logic can be applied in Table and List layouts?