Enhancements for column order

[reiv]

With defaultColumns we have a nice way to define which columns to display initially. However:

1. The columns can be modified anytime at which point the user preferences take precedence. To be exact, these prefs are actually written at the very moment we navigate to that collection in the admin panel, not just when toggling columns. This is kind of annoying when adding new defaultColumns in development (I currently reset my prefs manually when changing defaultColumns), but might also make users unaware of columns that were added to the collection after the fact.

2. When adding columns in the view, these are always added to the left of the table. This puts a very specific requirement on all custom cell components, which is to include a link to the doc, or it won't be viewable/editable as long as that column is in first place (there's probably a good reason I'm missing here, but why not make the whole row clickable instead of just the first cell?). It is possible to reorder the columns by removing them and then clicking on the column buttons in the desired order in reverse (!), but this is does not feel intuitive to me. I think this would be better served with some kind of drag and drop UI.

An alternative to manual column order, which I would propose here, is to give each column a predetermined index based on its position in defaultColumns, falling back to its position in the collection's fields if it is not a default column. It might also make sense to prioritize the field specified in useAsTitle, if given. This would be a breaking change, but it would give the developer more control over the presentation of the table.

I'd also suggest changing the format of the preferences to explicitly include all available columns and using a boolean to indicate whether to show it or not: e.g. { "foo": true, "bar": false, "baz": true} (not sure if object keys have a stable order in mongo, otherwise it would be an array of objects or something to that effect). This would mean that we could also take into account any (default) columns that were added after the preferences were set, and display those until hidden explicitly.

I look forward to hearing your thoughts on this!

[cbrualdi]

I share many of your thoughts and I agree that to improve this feature probably we should:

• Save user preferences only when the preference is actually expressed, otherwise use the configuration values
• Add new columns starting from the right
• Provide a way to block or limit customization to some columns (sometimes we make custom fields or UI fields that don't make sense to be proposed in the list view)

To avoid breaking changes, how if we add a property like allowColumnConfig or similar, which can be true, false or an {}.
If an object, give the option to either explicitly include or explicitly exclude certain columns.

Just to visualize:

admin: {
  defaultColumns: [
    "foo",
    "bar",
    "baz",
  ],
  allowColumnConfig: true // Default
}

This would be the default and does not change the current behavior.

admin: {
  defaultColumns: [
    "foo",
    "bar",
    "baz",
  ],
  allowColumnConfig: false
}

This would completely hide the Columns button giving us the ability to offer an immutable view.

admin: {
  defaultColumns: [
    "foo",
    "bar",
  ],
  allowColumnConfig: {
    include: [
      "foo",
      "bar",
      "baz",
    ]
  }
}

This would limit the possible columns to a defined subset of columns that makes sense to us.

admin: {
  defaultColumns: [
    "foo",
    "bar",
  ],
  allowColumnConfig: {
    exclude: [
      "baz",
    ]
  }
}

And this would allow us to explicitly exclude columns that aren't supported or that wouldn't make sense.

In this way we would keep the concept of default ordering, but have also a config object to further extend in future.

It would have been nice to have both defaultColumns and allowColumnConfig under one columns property, but this is perhaps not possible without introducing a breaking change.

What do you think? Would it cover all the main use cases you mentioned?

[reiv]

That sounds reasonable as well, although if we're talking about fields that should generally not appear in a column then I think it would make more sense to define this in the field level config (for potential reuse).

[jacobsfletch]

Related: #1413

[jacobsfletch]

but why not make the whole row clickable instead of just the first cell?

This is because you may render custom cell components and this would be conflicting.

I think this would be better served with some kind of drag and drop UI.

This is a great idea and something @phillipmalboeuf is taking on in PR #1865