Unable to omit specific fields which share the same source

[Dreamsorcerer]

Is your feature request related to a problem? Please describe.
If there are multiple fields which use the same source (e.g. to render different views of the same data), then it's not possible to omit specific fields from DatagridConfigurable as the omit property works with sources only. Given that they can be individually toggled on/off in the columns selection, it seems reasonable that they should also be configurable individually in omit.

Describe the solution you'd like
Haven't thought of one yet.

[slax57]

Thank you for your suggestion.
This seems like a very specific use-case, I'm not sure it's that common.
I suggest we wait for more feedback from the community before taking actions.

[Dreamsorcerer]

Just to give an example, you could have a NumberField to display the value of a foreign key, a ReferenceField linking to the foreign record, and a field that displays a link to some external resource, all using the same source attribute. Another example could be a TextField showing a file name and a custom field that displays an audio player for that file. I suspect there are many examples of these around, they probably just haven't tried to omit one individually.

I think another issue is that you can't omit columns without a source. For example, putting an Edit button in the list view, it then can't be omitted by default, even though the user can hide it with the columns button.

[slax57]

Okay I get your point, thanks for providing additional examples.
I'll mark this as enhancement then, so anyone can open a PR implementing this feature (remember to target the next branch if your do).
Note that we probably won't work on this ourselves though, since we don't have that need on our own projects.

[Dreamsorcerer]

So, the Columns button appears to use the column index. I'm not sure that's going to be a reliable way to implement this feature. Could we maybe extend omit so it matches the label or the source?

[fzaninotto]

The columns preference is a mix of availableColumns (used to display the list of possible columns in SelectColumnsButtons) and columns (which stores the user's choice regarding the orer and visibility of the columns). The second setting is related to the first one.

You have to consider that the feature must still work after the developer changes the number of orer of Fields in the datagrid, given users have already saved preferences.

[Dreamsorcerer]

Right, so columns is actually the index listed in availableColumns. I'm not sure how that index is kept in sync with developer changes (presumably by checking for columns with the same source or label?).

But, availableColumns contains both source and label, which suggests to me that allowing omit to match the label would be a resonable approach?

[fzaninotto]

No news for some time, closing.

[Dreamsorcerer]

@fzaninotto I'm still waiting for confirmation that my proposed approach would be accepted...

[fzaninotto]

I can't tell you if your approach works if you don't provide an implementation ;)

I suggest you open a PR, so we can judge on the code.

[Dreamsorcerer]

Well, I don't want to spend hours creating an implementation if you're just going to say that approach is not acceptable...

It shouldn't be difficult to answer yes/no to whether it sounds reasonable that omit could match source or label. As mentioned above, I'm assuming this is what availableColumns is already doing.

[fzaninotto]

Could you illustrate your suggestion with examples?

[Dreamsorcerer]

A NumberField(source="foo", label="ID") and ReferenceField(source="foo", label="Apple") on the same view. omit="Apple" would then work to hide the reference field (current behaviour is that you'd only be able to use omit="foo" and it would hide both fields).

[fzaninotto]

I fail to see how that would work without breaking backwards compatibility. Because developers may define two fields, one with source X and the other with label X.

[Dreamsorcerer]

I wouldn't expect people to have labels named the same as a different source. Can also put it in v5, so the small break in backwards compatibility is not an issue.

[fzaninotto]

I wouldn't expect people to have labels named the same as a different source.

This is the type of situation react-admin has to deal all the time. So in my opinion, your proposed solution isn't robust enough.