But, someone is going to try to do it. Tables on a large screen are easy. The real test of how good a table library is is how it handles small screen sizes. Some libraries drop out columns. Others switch to a vertical format. Some just let scrollbars handle it. I can think of about 10 different ways this is commonly handled. I'd like to see how this library does it.
Yeah but I don’t think there is an instant where showing more than 4 columns on a mobile is readable. I think this lib still squeezes it into the viewport, gotta set minWidth manually. Pretty standard
And you cannot please every irrational user. There just no good way to show wide tables on a narrow screen. It’s like trying to transport a load which exceeds the dimensions of its truck. Sure you can in theory drive it if it doesn’t collapse right away but that doesn’t mean you should.
All apps should work well on mobile. If you have a use for a table at all, you must also consider how it works for a mobile user. Whether that means dropping columns, replacing it with a list, handling horizontal scrolling or whatever, you should be doing it. If you pull in this library and then have to do that yourself, why not just implement the table yourself, since getting the advanced features like paging to work in such a dual view setup (table on desktop, list on mobile) would likely be more work than just making a table yourself....
I as a frontend developer think that tables simply are not made for a portrait mobile phone. Needs a different UI concept, e.g. cards in a vertical list. That way it is possible to show all info at the same time, while only having to scroll one direction. Tables which exceed the window width and height are terrible to use.
Tables are naturally wide while phones are naturally narrow. Why try to make it fit? Reminds me of the kid which tries to cram a star shaped piece of wood through a round hole.
I’m not saying the table library must make it fit. But the table library must address the issue. Having the library convert the table into vertical cards is a perfectly acceptable solution. But the library must handle doing that.
I can see that this is not a common do which libraries do because the decision when to break it down into a new component and how that is structured still requires some human thought. There is no one-size-fits-all yet, sadly.
