Hacker News new | comments | show | ask | jobs | submit login
Show HN: A simple React table library using CSS Grid Layout (github.com)
57 points by rebeccapark 5 months ago | hide | past | web | favorite | 27 comments



Why wouldn't you use proper tables for tables?


+1 There are many problems with html tables (like inconsistent buggy implementations between browsers) but grids don't fix them and introduce other problems. You can't group cells in rows / columns html elements. You can't write a simple css selector for a particular cell. You can't easily refer to a whole row with a css selector. You can't do stuff like "highlight the whole row on hover" because you wouldn't have a parent element to select. Grids are for grid layouts, and with current feature set they can't replace tables.


Exactly! Recreating the visual layout of a table is only half of the problem. You also need to think about making it accessible (which this component does not appear to attempt). You could get the for free by just using the proper semantic element.


Ruby, Sass, React, yarn, Node... Its like a game of how many dependencies can we require to make a <table>.

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.


Bulk table rendering can have a performance impact on your app and a more minimal implementation may be desired


Then the fix is to only render the rows currently in the viewport, right? Seems weird to recreate tables using CSS for that reason.


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.


Interesting, does `table-layout: fixed` have any effect?


Grids are much easier to do if you want to have smart scaling (i.e. benefits of Flexbox over more traditional layouts).


tables are evil /s


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.


Or other CSS facilities if you have to support sucky browsers.

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.


Provide simpler/different layout by other means (not tables though, there haven't been a need to use tables for layout for the last 15 years). Fun fact: it was IE what brought grids to CSS. Alas, being the first they are at the disadvantage when spec changed.


React components that take configuration rather than allowing you to compose smaller components are generally a bad idea.


Please try to explain further why something is a good or bad idea. Share your experience. I'm sure your criticism could be useful for many.

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.


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 commented on your grandparent)

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.


Oof, s/you’re/your


because dogma


The SCSS requirement is weird, especially for something meant to be imported by other projects. Why not use styled-components or emotion instead?


What's the use case for this? You can pretty easily do this already with React + styled-components + CSS grid and still keep it pretty DRY.

Would help if you added more/different examples to show what else it can do beyond that first example.


What's the benefit of this over react-bootstrap Table which uses an actual <table> tags.


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, please don't also comment that you did."

https://news.ycombinator.com/newsguidelines.html


Thanks for the info. Will remove my comment.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: