Improve column toggling UX

[icflorescu]

I think there's some room for improvement in the column toggling UX.
In my opinion, the toggling menu should be on the header instead of the toggleable columns.

That way, the user would not experience "jumps" when toggling columns using the menu, and we'd have fewer components and DOM elements created, so the entire code would probably be more efficient.

What do you think, @gfazioli?

[icflorescu]

Hey, @gfazioli!
Related to the above, please have a look at this branch when you have a moment:
https://github.com/icflorescu/mantine-datatable/tree/fix/518-improve-column-toggling-ux

Basically, in this commit I've moved the column toggling popover on the table header.

You can test it locally in this page: http://localhost:3000/examples/column-dragging-and-toggling/#column-toggling

It looks to me like it's working perfectly, but since you're the author of the feature, I thought I should ask for your opinion, in case there are hidden issues I'm not aware of.

Thanks again for everything!

[gfazioli]

It looks to me like it's working perfectly, but since you're the author of the feature, I thought I should ask for your opinion, in case there are hidden issues I'm not aware of.

Hey, I just checked and it works like a charm for me too. I think this way is definitely better. Well done 👍

btw, I would like to discuss this enhancement as it could be useful for column management. wdyt?

[icflorescu]

I just published it in v7, but I'm not sure if/when I'll find the time to backport it to v6.

Yes, I am open to discuss a generic header enhancement.

I remember somebody else was asking for it a while ago, but it wasn't top priority for me (my personal use-cases were handled differently) and apparently so far no one else was motivated enough to come up with a valid PR.

I guess the most basic functionality would be to simply provide the users the ability to supply a custom header component, which would be rendered above the column headers but inside the table border.

I'd be reluctant, however, to do any kind of search logic inside the DataTable component itself because in real-life projects this is usually done on the server-side.

Regarding this:

Would you also like to highlight the searched data in the respective cell?

Actually this would be a really awesome feature. Maybe to keep it simple, does it make sense to provide a property on the table component like highlightText or similar, and it automatically highlights the text contents of a cell (if not provided with a custom renderer)

I'm afraid this would open a totally different can of worms. I'm not sure, but I think adding something like this would increase the complexity of the code a lot and I have a feeling it would make the component perform sluggish.
How would something like this work with row expansions, for instance?

There are always users keenly asking for features that would satisfy their particular use-cases, but without really taking into consideration how those features would impact other pre-existing features, or the overall performance of the library. Sorting through such feature requests and deciding which ones make sense to implement is something that should be done with extreme carry, in my experience.

There are also users that raise feature requests motivated by the idea that - and I quote - "Mantine React Table has it". Which, in my opinion, is not a good enough reason. Different packages have different - and often contradictory - feature sets and approaches, and users are free to choose between them. For instance, here were a few key points that were very important for me when I started this library:

• Lightweight (and we're still around 10k gzipped and compressed, I think)
• Great UX for scrolling - hence the shadow visual cues for both vertical and horizontal scrolling
• Gmail-style batch record selection with shift-click - something that tanstack tables don't do, AFAIK

I think I digressed a bit, but I wanted to clarify the above to you, @gfazioli, since you were one of the few users who actually took the time to come up with valuable PRs instead of just asking for features 🙏

[gfazioli]

I just published it in v7, but I'm not sure if/when I'll find the time to backport it to v6.

No problem, if I can, I'll try to add it to the v6 app as soon as possible. Good job!

I'd be reluctant, however, to do any kind of search logic inside the DataTable component itself because in real-life projects this is usually done on the server-side.

I agree. I think we need to carefully consider features like this. A good library should provide only the useful tools to easily implement any custom feature.
For example, in the case of the header, I believe it should generally be tailored specifically for each project, as there are truly numerous combinations of different needs.

If we try to imagine a possible implementation of a Header, since we now have column management (resetting the order, visibility, and size), we would have something like this.

+------------------------------+---------+
| {title}                      | {tools} |
+------------------------------+---------+

• We should plan to choose a title, show it, and support a string or React component
• The same for the tools, how to visualize them along with alignment, etc.

Any eventual filter would not have much meaning in my opinion, because it depends on many factors; what is being displayed, if pagination is active, etc.

Eventually, what could be done is a simple "slot" attribute to insert a custom component, for example.

<DataTable header={<MyHeader />} />

which in the end would be essentially the same as

<MyHeader />
<DataTable />

In short, at the moment I can't think of any ideas on how to generalize a header without overly complicating the code.
It would perhaps be more useful to show how to create a custom header, with some examples and/or external components.

Below, for example, I have implemented a custom header on the application side.