What do you guys think about this pattern? The ide...

# compose

[Skaldebane]

What do you guys think about this pattern?
The idea here is to handle selections in a way that is resilient even if I don't have all the data (e.g. because of paging)
So I can allow users to do "Select All" on a list of items that I don't even fully have, and do operations on that (e.g. modify, delete, etc...)
And new items can come in (e.g. from loading new pages) and display the correct state right away.

[Skaldebane]

The way this is meant to be used is that you'd use NoteSelection.All when the user does "Select All", but then I start removing items from the set behind it once the user starts deselecting a few items (hence the name Except, the user selects all except some of them), and vice versa if they start selecting items individually.

This also makes inverting the selection trivial, and again all of this works well even if I don't have the full data set.
e.g. once the user deletes notes with an Except selection, I can send a query to the data layer to delete all items except those deselected.

If you're thinking "this is overkill" you're 200% right, no wonder I struggle to ship xD

[Kyant]

You can use value classes for Some and Except for performance.

[Skaldebane]

Good idea, thanks!

[Skaldebane]

Alright, tried implementing and using this for my app, a few things to note:
1. After adding a few more helper functions and operators, this is actually quite nice to work with.
2. To use value classes I had to switch to a sealed interface. Nothing wrong with that, just pointing it out.
3. Some operations like getting the selection count, or checking whether it's empty, require knowing the full size of the original data (for the Except case). That's not a big deal, but it makes the APIs a little less elegant (see picture).