You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, GridTable internally controls "which rows are selected", which is nice insofar as it provides out-of-the-box select/select-all/parent/child percolation/etc.
This works particularly well when the table rows are dumb POJOs that don't care about their selected-ness.
However, if there is other business logic that cares about "row selected-ness", having the GridTable solely / internally own selected-ness becomes cumbersome, i.e. when "selected-ness" would be better owned by something like a "form line item" model, b/c then the rest of the business logic could reactive to "form line model is selected" and be agnostic / unaware about the GridTable implementation detail.
For an example of a pain point, see this code in BP:
Currently, GridTable internally controls "which rows are selected", which is nice insofar as it provides out-of-the-box select/select-all/parent/child percolation/etc.
This works particularly well when the table rows are dumb POJOs that don't care about their selected-ness.
However, if there is other business logic that cares about "row selected-ness", having the GridTable solely / internally own selected-ness becomes cumbersome, i.e. when "selected-ness" would be better owned by something like a "form line item" model, b/c then the rest of the business logic could reactive to "form line model is selected" and be agnostic / unaware about the GridTable implementation detail.
For an example of a pain point, see this code in BP:
https://github.com/homebound-team/internal-frontend/blob/main/src/routes/projects/expenses/components/ExpensesTable.tsx#L212
That is basically writing glue code between
tableApi.getSelectedRows
andexpense.allocations
.It seems like ideally we could ask GridTable to just do this binding for us, i.e. something like:
Where instead of returning the full
SelectToggle
, we'd return just aFieldState<boolean>
, whichSelectToggle
would then internally use to:FieldState
value to initialGridTable
s internal selected stateGridTable
selection changes in sync with theFieldState
valueWe could probably pilot this w/o a
selectColumn
change by just adding afield=
prop toSelectToggle
and seeing if it could keep things in sync.The text was updated successfully, but these errors were encountered: