Edit: Seems like it might break on-page find though, right?
Also, it makes a certain sense to over-engineer this kind of technology to give other elements of the stack some leeway. Lazy loading is great but so is pre-emptively loading data in case latency rises.
An example I can think is a web based interface for controlling a drone. This could be used on the page to store the timestamped output of various sensors.
It would allow for the data to be displayed while also maintaining a history of the data in the browser. Could add in filters and searches as well as a pause functionality to review the historical data.
Sort of like a dmesg for the web page. I'm thinking practical uses are sensor monitoring and server monitoring.
I recently had a scenario where I needed to have a table that could be scrolled, and needed to be able to display up to 15k rows.
At the time I went with SlickGrid[1], but this seems like a nice alternative.
https://www.reddit.com/r/django/comments/3hlhgq/best_way_to_... asking for a
I've used Facebook's FixedDataTable too, which is also performant and relatively minimal, and it was also moderately painful to achieve even quite simple things.
The basic premise was ala google maps, a view port div, a massive div (map) within the view port for the scrollbar support, the concept of a virtual buffer area around the viewport and then a collection of tiles (tables) that would have data rendered into them and then be appropriately positioned into the buffer area around the viewport as one scrolls. Works well, have tested up to 40mm rows and columns and works in ie8 up to 4mm rows. Also supports random column and row sizes littered throughout the sheet. This solution does also break native in browser search though as mentioned in other comments.
How well does this plugin handle that? I noticed you didnt use a table, so perhaps you dont really care about styling it like one either.
No jQuery needed, with eventing and keyboard navigation
I’m not a web guy but most sorting table implementations on the web I’ve seen do the opposite, instead treating the table contents as the data to be manipulated. While this works it’ll cause you trouble in the long run and if nothing else will negatively impact performance. With the cell reuse model, you instead perform your transformations on the original data (free of markup gunk) and ask the table view to update itself to match the data source. Under iOS, this is done through UITableView’s reloadData method. You never directly interact with the table view’s recycling functions.
