I've been working with persistent data structures for my font editor, which has been interesting. I ...

# compose-desktop

[adte]

I've been working with persistent data structures for my font editor, which has been interesting. I have an object model like in the image.

I am tracking the selected points with a PersistentSet - however, this makes it hard to update the selection: when I move the points for example, it creates new instances and so I need to update the selection set to remove the old and add the new ones, which is cumbersome.
Does anyone have an idea how to track selection for immutable classes more easily?

[Zach Klippenstein (he/him) [MOD]]

Is it cumbersome because these are nested immutable values? If so you could use lenses (eg from the arrow library) or maybe explore something with compose’s snapshot system

[adte]

Is it cumbersome because these are nested immutable values?

That's part of it yeah - the data classes are immutable and contain persistent collections, the nested functions that mutate the data need to update and return back all the state from each of them.
Also, every time I mutate the points list I need to do "if (oldPoint.isSelected()) selectionBuilder.add(newPoint)" to have the new selection. If I'm not mutating some points, I still need to carry over their selection state in the new path.
I'll take a look at what you mentioned. For e.g. a mouse move operation, I was thinking to store the indices of the selected points and use that to compute the new selection since the structure remains the same.
Another option is to store isSelected state within the points directly, even though that is transient data.

[Zach Klippenstein (he/him) [MOD]]

If you need to do that while the structure changes, just using a global monotonically increasing counter to assign IDs to points could be handy

[Zach Klippenstein (he/him) [MOD]]

May I ask what your reasons for choosing to store this information in persistent/immutable data structures is?

[adte]

May I ask what your reasons for choosing to store this information in persistent/immutable data structures is?

@Zach Klippenstein (he/him) [MOD] For sure! People in this thread told me Compose works better when the data is immutable (to track changes), and also I wanted to work with persistent data structures as they make it easy to implement undo (just storing each new instance). Do you think I should/could use mutable data structures for my data?

[adte]

Integer ids sound gound, thanks for the tip!

[dewildte]

Can the ViewModel hold onto a map of selected ids?

[dewildte]

Trying to avoid UI concerns bleeding into your domain objects is important for maintainability.

[dewildte]

Generally that’s the soul purpose the UI layer uses different objects than the domain layer.

[Zach Klippenstein (he/him) [MOD]]

Immutable data structures stored in a single mutable state holder are just one strategy. If you’ve got really complex nested structures it may be simpler to make your objects mutable with the state holders inside

[adte]

If you’ve got really complex nested structures it may be simpler to make your objects mutable with the state holders inside

Are you saying to expose MutableState<T> from my data classes? Is that a common pattern in Compose/is there overhead to having a lot of State instances?