Show HN: DataSheetGrid, an Airtable-like React component (react-datasheet-grid.netlify.app)
I've built and have been maintaining a React component that renders an Airtable / Notion-like component for a few years.
This can be seen as an <input/> where the value is an array of objects. You can then specify any number of columns that are each responsible for rendering an input for a specific key.
The component handles all accessibility features like keyboard navigation, adding / removing rows, context menu, virtualization...
If you ever need your users to input long lists of data, this might be a good way to render the form!
81 comments
[ 2.9 ms ] story [ 149 ms ] threadGood concept though, and I wish you the best of luck building a proper OSS competitor to the propriety components!
In an ideal world, people would start making npm packages for each big feature, but the project would need a lot more attention for that.
[0] https://react-datasheet-grid.netlify.app/docs/getting-starte...
[0] https://tanstack.com/table/
[1] https://mui.com/material-ui/react-table/
[2] https://mui.com/x/react-data-grid/
From MUI: "This feature is not stable yet, meaning that its APIs may suffer breaking changes. While in development, all props and methods related to cell selection must be prefixed with unstable".
This feature tends to be pro or unavailable across options I've seen so it is great that DataSheetGrid has rolled out a working implementation.
Edit: Changed 'its pro plan' to 'its premium plan'.
https://tanstack.com/blog/ag-grid-partnership
But it's a great middleware that can be wired between the data and some kind of tabular UI react component.
To answer your second question, I believe DSG has a better UI / UX than the competition and is simpler to use and extend.
Two things I ran into:
- Doesn't have column resizing built in (not a deal breaker for my use)
- I wanted to disable the "select row or column by clicking in header or gutter" functionality. Not sure it's a common enough need to incorporate into the library.
Column resizing has been a long debate, but it goes against the mindset of building a simple tool that is easy to use. I feel like the responsive column sizing offers a better compromise.
But your second idea is actually one I could implement easily!
Edit: and I’d be remiss if I didn’t mention that if you only give someone encouraging words and positive feedback , you are doing them a disservice by stunting their growth or sending them down a wrong path.
[1] https://www.infragistics.com/
Im feeling the classic saying coming out uncontrollably, but if 3 out of 4 react developers told you to also walk off a cliff?
They really don't, tho.
React took over the front-end world 8 years ago or so. It barely evolved since then. I read the doc a second time 4 years ago when they introduced React Hooks.
I’m trying to think of other frontend technologies that were truly dominant that went away. Maybe SCSS? But TBH if you’re still using SCSS with React today that’s not a bad stack. There’s no consensus on what the successor to SCSS is, Tailwind is a wild experiment. The styled components model is still being refined.
Things like Next, Radix, MUI, etc… these are probably all best skipped. They are highly experimental, and I’ve used all of them in production on major web apps and they’re half baked. I avoid them.
It’s easy to get sucked into the trends… I love Vite for example, but anyone who ahas stuck with Webpack made the right call… Vite is still working out key points of integration like Jest.
If you take JavaScript Twitter seriously, you’d think you HAVE to learn React Server Components. But it’s not even out of beta yet, and debates are raging about whether it’s even a good separation of concerns.
The key is: wait until things are _actually_ dominant before jumping ship. If you do that, you’ll be fine.
The new beta docs just recently changed again removing old best practices concerning dependency arrays in useEffect hooks in favor of a new potential hook called useEffectEvent (which is still experimental).
I love to work with react. However, it takes _a lot of time_ onboarding new engineers for tasks which are a bit more complicated in nature. Also, using hooks the wrong way can really mess up your product big times.
It would be nice to see react moving in a direction which is by design/architecture less error-prone.
I liked DataTables. Never had a problem with it.
Also HN: downvotes comments critical of non-declarative non-data bound UI tools famous for spaghetti
https://www.ag-grid.com/example/
Perhaps someone who has experience with these components can list some other ones they like that act like the one posted?
I have used ag-grid extensively, its an impressive product. Some pieces are a little awkward to use, particularly auto-sizing. But generally ag-grid has thought of most functionality and has a solution. The creator of ag-grid had a great interview on Javascript Jabber [1].
The other serious data table component that I have seen is FinOS Perspective [2]. This is extremely high performance, also more specialized and probably harder to customize. I think Perspective renders to a canvas element from Rust/C++ compiled to WASM (not 100% sure). It is also made for streaming updates.
AG-Grid supports streaming updates... but only in the commercial version.
Eventually the data model for these types of tables becomes tricky. I will be investigating parquet-wasm for my use case. Hit me up if you want to collaborate.
[1] https://blog.ag-grid.com/javascript-jabber-podcast/
[2] https://perspective.finos.org/
My Sciter supports built-in virtualization out of the box. But I shall admit that this is second approach to the problem.
Currently Sciter's behavior:virtual-list supports as fixed-height items (that's easy) as variable-height items like messages [1] in chats.
API is relatively simple [2]: single event "contentrequired" that virtual-list sends to JS. In response JS shall either append or prepend requested number of DOM elements to the container (a.k.a. sliding window scroller). Example, grid showing 20000 records: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/s...
And needless to say that this supports animated (a.k.a. kinetic) scroll.
[1] https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... [2] https://docs.sciter.com/docs/behaviors/behavior-virtual-list
Refer to this POC (read: uncompleted unuseful app) to understand what I mean (save for the variable height): https://csv.riiway.com/
I remember on a project over a decade ago we had to choose the right data grid component to use. Our customers wanted “excel like” functionality. The number of possible features that the different component vendors had to create was so so long. There were easily 200 “little” distinct features, and every customer wanted a different subset of them.
A lot of components are complex (date time pickers for example) but the expectations placed on a grid are on a completely different level.
No one can do it all. Very wise to let the community help.
Google doesn't do this.