Comment by brylie 7 days ago I would recommend pagination for a table of that size. 2 comments brylie Reply tipiirai 7 days 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 7 days 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 7 days 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 7 days 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.
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...
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.