21–29 of 29 posts
edit: removed
The best course of action is to email the mods via the Contact link in the footer. The guidelines are clear on this as well: > "Please don't impute astroturfing or shillage. It degrades discussion and is usually mistaken. If you're worried about it, email us and we'll look at the data." > "Please don't complain that a submission is inappropriate. If a story is spam or off-topic, flag it. ... If you flag something, pl…
Why wouldn't you use proper tables for tables?
Seriously though, are we running off the rails here? Are we going back to the bad old days of perl "page generators", just replacing a dozen CPAN commands with a bunch or yarn's, gems, and npm's instead? I'm starting to wonder.
Earlier quoted context omitted.
Bulk table rendering can have a performance impact on your app and a more minimal implementation may be desired
Dunno why you’re downvoted. Noticed this too, if you have a table with slow loading content then the whole thing doesn’t render until all of it can render.
Earlier quoted context omitted.
Why?
Speaking from experience outside of react, but I imagine it carries over nicely having done a little react myself: The configuration either doesn’t encapsulate you’re specific use case because it is kept simple, and you are stuck forking the component; or the configuration expands to be its own little akwards DSL with very surprising edge cases.
I get (and strongly encourage) using grids instead of tables for layout. But why use grids instead of tables for tables?
This is off-topic, but since you strongly encourage using grids for layout. How do you deal with browser support issues? I found even IE11 is still very buggy in supporting CSS grid properly.
React components that take configuration rather than allowing you to compose smaller components are generally a bad idea.
In my experience with React, this kind of approach produces much more readable and elegant code. And also less code. And as long as the configuration objects are simple and readable like these, the problems with it are not serious.
It's true though that when your needs get more specific and complex you will surely find you need something not included in the component's configuration options. In those cases some components will let you specify custom things, which may or may not be enough[1].
Then it's trivial to reuse that configuration and iterate over them creating the table yourself.
Most tables I've done could easily be written with this component. Most of the time I actually do something very close to its configuration objects, and then iterate over them with a `map` to create the `td` and `tr`. This allows me to separate concerns more clearly.
(I don't know about using css-grid instead of the old tables. Really, I don't know css-grid well enough.)
[1] The OP's let's you specify a custom renderer for particular columns. That won't solve everything, but will do for many cases.
Earlier quoted context omitted.
Why?
Speaking from experience outside of react, but I imagine it carries over nicely having done a little react myself: The configuration either doesn’t encapsulate you’re specific use case because it is kept simple, and you are stuck forking the component; or the configuration expands to be its own little akwards DSL with very surprising edge cases.
I agree that these are the main issues with using this kind of component. However, most of the time there is no need to fork the component and, if you actually need things that the component doesn't allow, then it's the time to do it yourself. Because that doesn't always happen, if the component is easy to use it often is worth to go with it and only do the additional work if you need it.
> or the configuration expands to be its own little akwards DSL with very surprising edge cases.
This is the crux of the matter. However with this particular library, the configuration is extremely reasonable, simple and readable. It would be no problem to refactor the code to use the very same configuration to create your own table.
I get (and strongly encourage) using grids instead of tables for layout. But why use grids instead of tables for tables?
This is off-topic, but since you strongly encourage using grids for layout. How do you deal with browser support issues? I found even IE11 is still very buggy in supporting CSS grid properly.
I spent the first five years of my career advocating for replacing table layouts with CSS, and finding ways to do just that.
My point is simply that we seem to have gone overboard.
Part of that movement was towards what we called "semantic" markup. Wrapping your content in HTML tags that describes what the content is for (a heading, a list, etc) instead of how it should look (bold, larger font).
One of the reasons that tables were terrible for layout was that with tables you had to use markup that meant different things than what you were trying to accomplish. Among other things, this badly screwed with screenreaders and other software parsers (crawlers, including those of the major search engines; and scrapers).
But for actual tabular data, HTML tables are the semantically correct markup. They work well and can be parsed correctly. The point of the semantic markup movement was never to completely remove tables from our vocabulary. It was to return them to their proper use case.
While we did manage to come up with CSS alternatives for nearly all the table based layout features, CSS Grid is the first option that gives you the full power that tables offered (and more) for the grid-based layouts that have been a staple of graphic design since the creation of the first coffee table book.
But this package reminds me of the straw man argument that some old school developers used to bring up when we encouraged them to learn CSS for layout: "if we get rid of tables, we'll have to come up with insane workarounds for displaying tabular data".
Well, someone just did.