Closed MogensO closed 2 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 95.94%. Comparing base (
1919e3d
) to head (af090e2
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
It doesn't seem to be working as expected. I.e. in async data source I set rows as selected:
Yet the state doesn't get applied:
This is weird.
If I do the same, I get:
I also tried to modify the Dessert domain model entity as shown below to simulate selected coming from the DataSource:
With the result being:
Could you eventually check your version of async_paginated_data_table_2.dart?
It should contain:
My bad, I had some older version of code, now I can see the selected state being applied... Yet there's still an issue.
When selected via UI, there's a change in subhead showing the number of selected row:
Yet when selection "programatically" via setting the field in the data row this doesn't get displayed:
There's a conceptual issue that needs to be fixed, the state of selection is stored internally by the widget and it also can be a part of data row itself. There's no proper sync of the states
I haven't given this enough though yet it might be a good point to keep the selection state out of data source (i.e. always ignore there data source selected), I don't know. Any suggestions?
Well not at the moment, I'll have to dig deeper in the code.
I'll give it a thought over the Eastern.
Anyway it is somehow a crucial function for me, as the selected state of a row
very often is something we will persists in a database and thus must be present in the data source.
Conceptually the selection state looks like a transient one and shouldn't be part of entity persisted...
I don't really see why this should not be persisted. If you i.e. select an order for picking in a WMS system you would certainly need to persist that, i.e. because it signals that the order have been started and you or someone else would like to see that later on somewhere else or maybe stop it again be deselecting it. If that should be reflected somewhere else it would require a second column in the table which take up space and essentially is redundant. And on small handheld devices space is scarce.
In _fixSelectedState we need to check for an entry in _selectionRowKeys for the SelectionState.none
In _fetchData we also need to ensure that _selectionRowKeys are maintained for the rows retreived from getRows