Hey, I am curious if there's a way to subscribe to...

# compose

[shikasd]

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.

[Chuck Jazdzewski [G]]

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.

[shikasd]

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 :)

[shikasd]

I have also played with commitObserver api, but, as I understood, it is only triggered when write is detected, and before applying changes

[Leland Richardson [G]]

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

[Leland Richardson [G]]

i might not be the best person to help you but i’d be happy to spend a few minutes on a call to understand your use case more directly. i think the kind of stuff you’re working on is super interesting and would like to understand if there are ways we could make the core of compose more general to support those use cases

[shikasd]

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

[shikasd]

I'll definitely check it out, thanks! 🙂

[Leland Richardson [G]]

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

That’s the idea 😉

[Chuck Jazdzewski [G]]

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().

[shikasd]

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 🙂