Currently replaces the issue and redeem tables on the vault control panel with stats calls.
Note that previously we had a generic component for all tables, which would take as parameters a data loading function and a mapping from API data to rows and columns, and handle loading and displaying data. However, currently, the dashboard tables seem to be structured with a separate non-generic component for every individual table, which handles arranging the data but also has a lot of non-data-specific code regarding state management (e.g. the loading spinner), displaying the actual row and column components, etc. For example, the difference between the IssueRequestsTable and the RedeemRequestsTable is mostly just the columns field that defines the table headers and content, and the API call inside useEffect().
Given that this change was made, I continued in the same pattern in creating VaultIssueRequestTable and VaultRedeemRequestTable. However, @anton-karlovskiy, is there a good reason to keep completely separate components with mostly duplicated code? What do you think about creating a generic "dashboard table" component, and simply wrapping it by passing custom data and a custom columns definition, but avoiding reusing all the state logic and InterlayTable construction etc.?
Currently replaces the issue and redeem tables on the vault control panel with stats calls.
Note that previously we had a generic component for all tables, which would take as parameters a data loading function and a mapping from API data to rows and columns, and handle loading and displaying data. However, currently, the dashboard tables seem to be structured with a separate non-generic component for every individual table, which handles arranging the data but also has a lot of non-data-specific code regarding state management (e.g. the loading spinner), displaying the actual row and column components, etc. For example, the difference between the
IssueRequestsTableand theRedeemRequestsTableis mostly just thecolumnsfield that defines the table headers and content, and the API call insideuseEffect().Given that this change was made, I continued in the same pattern in creating
VaultIssueRequestTableandVaultRedeemRequestTable. However, @anton-karlovskiy, is there a good reason to keep completely separate components with mostly duplicated code? What do you think about creating a generic "dashboard table" component, and simply wrapping it by passing custom data and a customcolumnsdefinition, but avoiding reusing all the state logic andInterlayTableconstruction etc.?