but looks like we are also loosing the ambient values

The documentation on

compositionReference()

is pretty straightforward and seems to be exactly what I want, so i guess another way to ask that is, is

Recomposer

replacing

CompositionReference

at some point?

Just looked through the source for

Recomposer

and it looks like it's singularly responsible for scheduling and performing composition passes. There's nothing in there about ambients.

you probably want to use

subcomposeInto

specifying a

compositionRefernce

and

Recomposer.current()

oh actually subcomposeInto is only defined for componentnodes

we might want to have an equivalent API for views

or alternatively we could add compositionReference as a parameter to

setContent

some of these APIs are jkind of a mess right now as we refactor things to be multi-threaded

can you file a bug with this use case and assign it to me?

FWIW I got it working using a bunch of reflection to get around the current API limitations, and verified that ambients are indeed propagating, at least initially (changes don’t show up, but it’s progress).

without one, they shouldn’t get passed at all (it should go back to the default values)

the strange part is propagating changes. if you want invalidations to flow through correctly you really need to think of them as one composition. compositionReference allows you to do that. we are hoping to change some of these APIs to have a shape where compositionReference is no longer needed and this always just happens if you use one API, and doesn’t if you use another

Filed the API issue: https://issuetracker.google.com/issues/156527485 And the updates issue: https://issuetracker.google.com/issues/156527486 Thanks again for your help! This was fun.

I have been hacking a lot on this, trying to understand how subcomposition and especially ambient propagation work, and I'm am stuck at a point where I'm not sure if the behavior I'm seeing is a bug or my own mistake. I'm not sure if it's worth filing a bug yet, since this isn't even using public API. I'm using the reflection I posted on the issue, basically just a direct line-for-line copy/paste of the

ViewGroup.setContent

implementation with the additional

CompositionReference

parameter. It seems there are two keys to using subcomposition that aren't immediately obvious. The first one is that, for the subcomposition to recompose after changing some observed

State

, you have to call

setContent

explicitly. I tried only calling it once, when setting up the Android View, and it did the initial compose pass successfully, but mutating a

State

object observed in the child composition didn't trigger recomposition. I even tried having the child pass its

invalidate

function out and calling it directly, which didn't work. I didn't think this would be necessary because the normal

setContent

doesn't require constantly being re-invoked. However, I noticed that both

WithConstraints

and

AdapterList

call

subcomposeInto

multiple times so I guess that's expected. They also always call

nextFrame

after doing so, but I couldn't see any difference in behavior with or without calling that. Secondly, and this is where it seems like there's a bug, the above strategy of calling

setContent

multiple times works for keeping the content inside the composition fresh. However, on the next composition pass, the subcomposition suddenly loses any custom ambients provided from the parent (they all "reset" back to their default values). If I add a second Android view, sibling to the first one, with its own subcomposition, it also works on the first composition pass and then loses its ambients on the next one. There's a lot going on here so I apologise if my explanation is confusing. I can pull the code in question into a separate repository, but wanted to get a quick sanity check here first. Am I just too far in the weeds here, and I should stop wasting my time until the API to do this is actually public?

After another two days of investigating, I am basically as confused as before, although I think I’ve got it working. I haven’t had any luck reproducing this in an isolated codebase, but I can get two different exceptions in my main codebase – in one case a

LayoutNode

is complaining about not being measured, and in another an NPE because

DensityAmbient.current

seems to be returning null, which as far as I can tell shouldn’t even be possible. I think the issue has something to do with how Android views and LayoutNodes are initialized when they are nested recursively, alternating between the two (i.e. Subcomposition inside View inside Composition inside View). This seems to be more problematic if the “View inside Composition” is initialized inside a composable before passing it to

AndroidView

. If I use a custom view and add that to the composition before trying to initialize the child android view, it works. The only case I haven’t figured out so far is that I get the LayoutNode measure exception when forcing a recomposition of a “root” composition (no parent CompositionReference). It seems like compositions with a parent must be recomposed explicitly, but compositions without a parent must not be composed more than once. I have to handle those cases separately – if there’s a parent, I call

setContent

on every update, and if there’s no parent, I call

setContent

only once and use a

MutableState

to pass updates in. I have no idea why any of this works, or why ambients will sometimes disappear if things are done the wrong way, but at least all this weirdness can be hidden and when it works, it’s pretty magical.

At least one of the issues seemed to be that calling

setContent

multiple times crashes, but it should not. I’ve narrowed this down to probably having something to do with capturing lambdas, filed as https://issuetracker.google.com/issues/157430448.