Responsive hiding columns of a Datagrid

[tacoWanneeJama]

Describe the bug I want to hide some columns of a DataGrid on mobile devices. For that I use:

<DataGridColumn TItem="DeviceVM"
             Field="@nameof(DeviceVM.Side)"
              Caption="Kant"
              Display="Display.None.OnMobile.TableCell.OnTablet">

This makes the content of the grid hide for small screens and show for larger screens. That's doing well. But the header of the grid is not hidden together with the content. I see that the content cell gets decorated with the class: "d-sm-table-cell", which does the trick, but the header is not decorated with this class. Since the DataGridColumn and the CaptionTemplate component do not allow to manually add a class I can't get a workaround very easy.

My request Can you make the component to also decorate the header with the appropriate class?

[stsrki]

For the header, there is a separate parameter, named HeaderDisplay. Can you try and see if it works for you?

[tacoWanneeJama]

Ah, that works

[tacoWanneeJama]

How do I make the filters join in with the same behavior? I do not see a FilterDisplay property. When I hide columns this way, the filter inputs are still shown and an error about filter is shown in the browser console....

[stsrki]

It seems we didn't assign Display to the filter row. We would have to fix it. Not we need to determine is it better to use Display or HeaderDisplay for the filters. Or introduce a new API FilterDisplay. I think the new API would make more sense as we already have a similar separation for other settings.

@David-Moreira any thoughts?

[tacoWanneeJama]

OK, thanks.

[David-Moreira]

It seems we didn't assign Display to the filter row. We would have to fix it. Not we need to determine is it better to use Display or HeaderDisplay for the filters. Or introduce a new API FilterDisplay. I think the new API would make more sense as we already have a similar separation for other settings.

@David-Moreira any thoughts?

I agree with keeping the same separation as we have by creating a new FilterDisplay, even if it's quite redudant for Display?. Most of the times the user will probably have to manage the 3 of them equally, but maybe there will be one or other user that can make use of the separation?

[tacoWanneeJama]

It seems we didn't assign Display to the filter row. We would have to fix it. Not we need to determine is it better to use Display or HeaderDisplay for the filters. Or introduce a new API FilterDisplay. I think the new API would make more sense as we already have a similar separation for other settings. @David-Moreira any thoughts?

I agree with keeping the same separation as we have by creating a new FilterDisplay, even if it's quite redudant for Display?. Most of the times the user will probably have to manage the 3 of them equally, but maybe there will be one or other user that can make use of the separation?

I agree, that it is redundant. I would prefer to have a shared property, that does it for all 3 (99% of the cases you want them the same behavior). When that setting can be overruled by a specified property for those 3 you have maximum freedom.

[stsrki]

Well, maybe we can make it implicit. If only Display is used then assign it to all. If any of the others is used then it will override it. But, is that breaking behavior? I think it is not 🤔

[David-Moreira]

I guess not. seems okay. We can update Display parameter doc to reflect that.

[knight1219]

Has the FilterDisplay property been added in any current releases? I'm using 1.1.1 and I don't see it.

[stsrki]

Has the FilterDisplay property been added in any current releases? I'm using 1.1.1 and I don't see it.

No, we didn't have much time to add FilterDisplay into 1.1. We can arrange it for 1.2, and release it in the preview soon.