2 ms·

Sometimes it is better to take advantage of web browser builtin search function (Ctrl+F). Unfortunately some overly-eager implementations break it when supplant

Sometimes it is better to take advantage of web browser builtin search function (Ctrl+F). Unfortunately some overly-eager implementations break it when supplanting with their own...

bvrmn 7y ago
Most real data is too big to fetch in one piece by a client. Internal admin interfaces come to mind. On each job every time support people ask to include monstrous sorting behavior over multiple columns to be able to find group in question. However simple search would be enough.
- omgtehlion 7y ago
  Yeah. There are different sizes of data, that's why there is no good control for everyone. Size of data can be: 1. Small, so you can display it all at once and the user will have luxury to ctrl+f what he/she wants; 2. Big to display, but small enough to push to client: then you will need to create pagination or virtualized view. Ctrl+F will not work (at least without some tricks), but you can easily filter/search it yourself in JS; 3. Too big to transfer: the only way to search/filter is on the server and separate controls (of course Ctrl+F won't work).
  - TeMPOraL 7y ago
    I'm worried at what size 1 becomes 2. I've seen web tables that choke on 100 rows. I feel that if a table can't handle 10-100x that without destroying site's performance, it's done wrong. I also wonder whether we shouldn't have new <table> tag, meant specifically for data tables. Say, <datatable>. It would have all sorts of sorting and filtering and pivot tables built-in, and it could exploit native code to ensure high performance. Case 3 could be handled by a well-defined API that translates table operations to JS calls, in case a full dataset can't be sent to the browser.
    - omgtehlion 7y ago
      It will be a heck of API to agree on. And then to implement correctly. As another poster linked ag-grid this is how API surface should look like: https://www.ag-grid.com/javascript-grid-server-side-model/ https://www.ag-grid.com/javascript-grid-server-side-model/

Sometimes it is better to take advantage of web browser builtin search function (Ctrl+F). Unfortunately some overly-eager implementations break it when supplanting with their own...

bvrmn 7y ago

Most real data is too big to fetch in one piece by a client. Internal admin interfaces come to mind. On each job every time support people ask to include monstrous sorting behavior over multiple columns to be able to find group in question. However simple search would be enough.

omgtehlion 7y ago
Yeah. There are different sizes of data, that's why there is no good control for everyone. Size of data can be: 1. Small, so you can display it all at once and the user will have luxury to ctrl+f what he/she wants; 2. Big to display, but small enough to push to client: then you will need to create pagination or virtualized view. Ctrl+F will not work (at least without some tricks), but you can easily filter/search it yourself in JS; 3. Too big to transfer: the only way to search/filter is on the server and separate controls (of course Ctrl+F won't work).
- TeMPOraL 7y ago
  I'm worried at what size 1 becomes 2. I've seen web tables that choke on 100 rows. I feel that if a table can't handle 10-100x that without destroying site's performance, it's done wrong. I also wonder whether we shouldn't have new <table> tag, meant specifically for data tables. Say, <datatable>. It would have all sorts of sorting and filtering and pivot tables built-in, and it could exploit native code to ensure high performance. Case 3 could be handled by a well-defined API that translates table operations to JS calls, in case a full dataset can't be sent to the browser.
  - omgtehlion 7y ago
    It will be a heck of API to agree on. And then to implement correctly. As another poster linked ag-grid this is how API surface should look like: https://www.ag-grid.com/javascript-grid-server-side-model/ https://www.ag-grid.com/javascript-grid-server-side-model/