I have used Reactable (https://github.com/glittershark/reactable) in a recent project and was extremely happy with it. The design was very customizable and the sorting / search functionality I needed was available.
You've got to click settings and display all the columns. "dog" is a substring of the company name. Here's the filtering code; it's just a JavaScript `indexOf`:
In our case, we needed to filter on hidden columns (as we still cared about the data behind the scenes), but I'm thinking that this is something that should be optional.
1. Change settings to 100 rows per page,
2. scroll down to see "Next" button
3. press it twice (until it disappears)
4. Page is scrolled down - unexpected behavior.
Are there any react infinite scrolling examples that support arbitrary row-heights?
Like if you need to inline images which might be variable sizes.
I think it's probably possible, with some clever caching of row heights and recalculation of some sort, in order to maintain a correctly sized spacer element at the top/bottom. Not seen any examples of it.
Unless I've misunderstood, and it may be semantics, but I don't see this as infinite scroll. If I had 10,000,000 rows the browser would still struggle with this grid as it needs to keep the React JS objects in memory. I would like to see server side paging integrated with the scrolling.
Its not proper infinite scroll, they aren't removing DOM nodes as you scroll down. But it's rare that any infinite grid can really handle 10m items because they tend to use `top` or an overall height, so the browser would probably choke.
Yeah, not rendering nodes out of view came up a little early on in the current implementation of infinite scrolling as something I was looking to do. The only way I could think of not rendering previous rows was to lock a specific row height, which was not something I was excited about (and it breaks down even further on nested tables, which have a state independent of its parent grid).
It's definitely something Ryan and I (or anyone else that might want to contribute) will be revisiting in the near future, potentially as a config option.
Is it just me or the "visible" parameter doesn't work at all?
My use case: I have columns A and B and instead of displaying both I want column A with data from B in it. So I thought I'd set B to "visible: false" and then use rowData.b in the custom component of A.
This is what makes me scared of React. Everyone says it's so simple but still you need all these specialized plugins for things that are easy to do without React.
React is a component based UI framework, so I find it natural that common components that might exist in some other framework need to be re-created for React.
IMO, the fact that React components can be easily shared with an interface that follows a common pattern is a major strength of React, rather than a weakness.
With Griddle, we were trying to mostly stick with React so it could be used without other libraries (we do currently have a dependency on underscore but we're hoping to remove that at some point in the future as well).
I recently had a problem where I had to render tables that could have around 750 columns and 40 rows. I tried it with angular and it would cause everything to stop for around 90 seconds (that was the initial version with some poorly written directives inside of it, afterwards I tried making another angular one and it still took around 10~ seconds if I recall correctly).
I rewrote it in React and got the render time down to around 600ms~ Not GREAT, but far more acceptable than a couple seconds. It's worth noting that the react version doesn't do anything fancy, it just has to display the table with some tooltips. (There's a lot of room for improvement, for example, I could only render whatever amount of rows are in view and defer rendering the rest.)
I tried Griddle and, if I'm remembering properly, it took around five seconds to render a 750x40 table. The overhead of all the features they provide made it a suboptimal solution for us :(.
Unfortunately, I don't think you can optimize horizontal scrolling as easily as you can optimize vertical scrolling. I looked around as well and was unable to find a suitable library.
One of the library authors here -- That sounds like quite the table! I wouldn't doubt that Griddle would have a bit more overhead than the solution you mentioned. I wonder if the performance would be better in this version -- not saying it would necessarily but it may :) We stripped out one of the more complicated parts (the piece that let people specify a callback to obtain external data) to its own component.
Horizontal scrolling definitely sounds like an interesting idea. Seems like it would be feasible to add -- I'll have to think about that a bit more. Also, if the solution you came up with is online anywhere I'd love to see it!
I was thinking more like 200M rows and 16M columns (sparse - stored as compressed rows), or perhaps a grid cell for every geohash address. The only solution I know of is part of custom GUI toolkit rendered with LWJGL in a desktop app that handled the former case (crashed the first time - worked fine a week later). Obviously far fewer elements would actually be resident in the client at any given time.
More common is that I just don't know how many columns there will be (or the datatype, optimal width, etc) until the user performs a series of actions and renders a particular view. I've shoehorned a solution into extjs that works (not scrolling, just dynamically defined), but I'm always looking for options.
I was thinking more like 200M rows and 16M columns
I don't think a user would be able to meaningfully navigate a table like that by scrolling it. How would they cognitively track where they are or how to return to interesting parts of the data? IMHO, you should rethink how to display and navigate this data. The user would need sophisticated search/filtering support.
It's the same as zooming in and out in a google map - if you zoom out, the server is providing e.g. averaged data. Thinking about trackpad navigation around a map of tiles (sections of a spreadsheet) is probably more relevant than scrolling per se.
A side window let's you navigate at a high level (low res) and zoom in to data-dense areas. Low level / high res navigation in the grid might be used for exploring data from individual sensors, in context with interpolated values.
You can keep the scrollbars from becoming irrelevant by scaling to the size of a logical grid 'neighborhood' of adjacent tiles at the current zoom level.
I've been working on a virtual table (not for React, but KnockoutJS) that's designed around needed to virtual scroll over a large number of columns (as well as rows). Really in-progress code at the moment, but getting there...
You can edit that on JsBin and easily increase the columns to 5-10,000. You may want to look at [editableCell](https://github.com/gnab/editableCell) for some of the keyboard shortcuts.
Not bad but when you get deep into it (as any other grid) it lacks a lot of functionality. For example, it looks like the external data interface only supports a single sort column...
<too lazy to read the code right now, sorry> why the rows (tr) of the first table are replaced instead of changing their content (I thought that was the strong point of react)? (attributes added to tr tags disappear when you click next, and comparison of the nodes before/after confirm they're different).
React's rendering works differently than traditional JS apps. He's not re-inventing the wheel, he's adapting it to a new vehicle.
Also, hell, if you want to make a good demo project then re-writing something is a great place to start. A demo project that got me hired was just a designer and I's answer to Adobe Kuler.
Using all of ExtJS just for a grid seems like a bit much. It's no surprise that when a new framework comes about there's a landrush to reinvent all of the common components.
I build a bunch of big reports with ExtJS.
Its grid-component is just superb.
Infinite scrolling just blows up the browser after a while, but not with the ExtJS grid.
