top | item 43937471 (no title) brylie | 9 months ago I would recommend pagination for a table of that size. discuss order hn newest tipiirai|9 months ago Agreed. No reason to show more than 100+ entries on a single table. Event sourcing isn't about UI patterns but rather one level beyond it: the "back of the frontend" [1]:[1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-b... CafeRacer|9 months ago AgGrid, for example, virtualises the dataset and easily render a 100k records: https://www.ag-grid.com/example/On our app we render large datasets (e.g. 40-50k records) and provide filtering/searching with rxjs.Search even uses a levenshtein distance and the entire collection is sorted based on the similarity score.Works like a charm.
tipiirai|9 months ago Agreed. No reason to show more than 100+ entries on a single table. Event sourcing isn't about UI patterns but rather one level beyond it: the "back of the frontend" [1]:[1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-b...
CafeRacer|9 months ago AgGrid, for example, virtualises the dataset and easily render a 100k records: https://www.ag-grid.com/example/On our app we render large datasets (e.g. 40-50k records) and provide filtering/searching with rxjs.Search even uses a levenshtein distance and the entire collection is sorted based on the similarity score.Works like a charm.
tipiirai|9 months ago
[1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-b...
CafeRacer|9 months ago
On our app we render large datasets (e.g. 40-50k records) and provide filtering/searching with rxjs.
Search even uses a levenshtein distance and the entire collection is sorted based on the similarity score.
Works like a charm.