We need to handle table state on different pages. Some pages do client side table handling while some other need to offload some work to the server. Two most critical pages that we migrate to server handling are the Feature Flags page and Project Overview page.
Table handling consists of 4 parts:
- API call and server side data handling
- persistent table state in URL and localStorage (handled by the usePerisistentTableState hook)
- column definitions and client side data handling (handled either by react-table or custom code)
- Material-UI rendering components
Data handling consists of:
- sorting (either server or client side)
- pagination (either server or client side)
- searching (either server or client side)
- filtering (either server or client side)
- column visibility (only client side)
- row selection (only client side)
For pages with no server data handling we need
react-table for client side data handling.
For pages with server data handling we considered two options that we implemented in a spike:
- not using
react-tableand writing minimal custom code for column visibility, data mapping and row selection. Not much else is required since server side is doing sorting/pagination/searching/filtering
react-tablewith the extra cost of the library magic and writing connectors from backend data to
The tradeoff is between simplicity of the pages that support server side data handling and the consistency between the definitions of the client side and server side powered tables.
We have decided to favor consistency over one-off simplicity.
react-table comes at a cost but allows to change between client and server side data handling with lesser effort. It allows to revert decisions to client side and makes the migration
to server side data handling easier.