yep

# compose

[Vladimir Ivanov]

yep

[Andrey Kulikov]

you will be able to. it is implemented in a way to have a proper multitreading reads and writes. but I am not sure you can easily do it at the moment as it requires some manual additional work right now. you will need to create a Frame object for every thread, I guess we will implement it to work automatically later

[George Mount]

You can do it as long as you have a frame started for the current thread. The UI thread always has a frame, so you can always modify on the UI thread. If, for some reason your lambda is executed off the UI thread, you can see if you have a frame with inFrame, start one with open() and commit it with commit() (all in Frames.kt)

Something like this should work:
if (!inFrame) {
open()
// modify state
commit()
} else {
// modify state
// let whoever is managing the frame handle the commit
}

[romainguy]

We should rename frames to transactions or something :)

[efemoney]

Yeah Frames just confused the heck out of me. What exactly is a frame?

[George Mount]

Yep, naming of the API is bad and it should feel bad.

Frame = transaction, like Romain said. Essentially, you want all of your changes to happen atomically, so when you commit(), all of the changes that you made to the models are considered as changed together.

[Chuck Jazdzewski [G]]

Frames are in memory observable non-durable transactions which will be called transactions in the future, dropping the name frame entirely.

[Vladimir Ivanov]

Did you folks considered batch updates to the tree? For example, when two or three coroutines update the tree almost simultaneously?

[Leland Richardson [G]]

yes - and batching is currently the default

[Chuck Jazdzewski [G]]

@Vladimir Ivanov Are you referring to the tree the composer is managing or a tree data-structure using @Model objects as nodes?