Hey, I am curious if there's a way to subscribe to recompose of composition instance. Essentially something similar to

addChangesAppliedObserver

in composer on dev-14, but actually open for external listeners 🙂 The use case is that whenever changes are getting applied, they can result in multiple small updates. I wanted to batch them, so I could dispatch events more efficiently.

I would like to understand your use case better. What updates do you want batch and what inefficiencies are you seeing?

addChangesAppliedObserver

is current unused even internally and I was planning on removing it.

Sure, inefficiency that I have is veery specific for the use case of my custom composer, so I honestly do not expect you to support it 🙂 Essentially, I am working on a pet project to have compose as a server-side render. I have tree of nodes on server which can dispatch a couple of add/remove actions and then those actions are sent to client which updates its representation of tree accordingly Obviously, network is much slower than direct memory access, so I would prefer to batch those updates to optimise for speed and better synchronisation between client-server tree representations :)

Interesting. Implementing a custom recomposer might be the best avenue here. The Recomposer’s job is to schedule recompositions based on invalidations. You can check out a few of adam powel’s latest CLs to see some changes happening in this area right now as we move the recomposer to be coroutine-based. We’ve even considered maybe making a Recomposer map to a custom Dispatcher

Does coroutine based recomposer means that you are going to support composition on background threads on Android?

Does coroutine based recomposer means that you are going to support composition on background threads on Android?

That’s the idea 😉

I believe @Leland Richardson [G] suggestion of a custom recomposer is the right one but, unfortunately, this is under tremendous flux right now so anything you write now will just have to be rewritten later. Changes observed by the

FrameManager

(also in flux) notify the recomposer of the change whenever the an

apply()

of a snapshot occurs. The recomposer then schedules a recomposition to be take place. For the UI, this is on the pace of the

Choreographer

at ~16ms intervals. However, the recomposer is in charge of when and how often this occurs. If you have your own recomposer it would control the pace. We are making this much easier to work with as we are using

suspend

functions and the goal is that the recomposer is just a

suspend

function that calls

recompose

in a loop. The UI call

waitFrameMillis()

once it detects a change. In your case you would just call something else to pace the changes instead of

waitFrameMillis()

.

The interesting part here is that pace is not the problem, as I don't have frame sync in server environment. The problem is to capture full response of composition towards some event that happened and make sure we deliver it in as few objects as possible. Here, i want to avoid partially updated values delivered to the client, because it will render UI in partially completed state until the next piece of updates arrive (which depends on network speed). For example, if I have the whole page changing theme from dark to white, partial update means that user will see only some values rendered correctly. Seems like reimplementing recomposer (at least partially, to hook into correct place) is the way to go for now 🙂