is

ContextAmbient

always activity? I need to get at the activity to silently get a

ViewModel

behind the scenes using

ViewModelProvider

fun getModel(): MyViewModel {
        val context = ambient(ContextAmbient) as AppCompatActivity
        return ViewModelProvider(context).get(MyViewModel::class.java)
    }

If I still recall well, I think of the framework engineers at Google highlighted that is not a full activity context. It is only a lightweight context to allow accessing application resources such as strings, drawables, etc.

cool thanks @Klaas Kabini it is the activity right now but since its

Context

it could change to anything

You could just create your own ViewModelStoreAmbient.

Its a good idea but at the moment for my little

Router

API I don't require the user to provide anything to do with view models or the activity and wanted to sneakily grab it behind the scenes 😄 the function I call

startComposing()

is a

@Composable

function and there I do that activity cast from

ContextAmbient

Its not such a crime to require the user to provide the activity really though just prefer one less arg and + 1 more magic. Is a

ActivityAmbient

something we want to avoid? It could be useful in some scenarios but I understand it could also be misused 🤔

just prefer one less arg and + 1 more magic

often you want the reverse of this for scalability, understandability, composability, probably lots of other -abilities 🙃 it helps when each component declares its dependencies explicitly and callers know what's in play and can influence things

I guess so... though I think API developers break those rules quite often also as a trade off for convenience, Something like

val service = ambient(ServiceAmbient)

is already quite magical! 🙂 even so I do agree with your point completely since its just an extra argument for an object the caller has access to anyway

Every one of those we add is a debate 🙂

ah! 🙂 I guess its just critical stuff? is

ambient

at risk of being removed?

the

ambient()

function has already been removed, but it was replaced with a

val

extension on the ambient types,

.current

I think? It's sticking around as a concept.

yeh defo a trade-off, most things like that as long as they don't make testing things difficult its ok to add magic providing its not to obscure

it's double-edged, and there was definitely a surge in posts and conference talks for a while in the spirit of, "we finally removed all of our Contexts from our app!" in that community after folks got bitten by the pitfalls

ah nice thanks 👍 will check that out I never used those frameworks so this style is totally new to me 🙂

it should be telling that react's official page on context starts with a big, "before you use this, try all of these other things first" section 🙂 https://reactjs.org/docs/context.html

nice was just reading that

in particular, Compose leans very heavily on lexical scoping for things like this. You can

remember {}

something in a

val

in a composable but use it several layers down the UI tree without those layers in between having to understand it or pass it as parameters

Here is something I am doing in my screen

val router = ambient(AmbientRouterContext)

    val cardActions = CardActions(
        editCard = { card ->
            router.goto(MemsetDestination.CardDesigner(card.uuid))
        })

    HomeScreenContent(state, cardActions)

Using this router basically sets a model property above this composable

HomeScreen

causing it to show another

XyzScreen

Right. So can your screens accept a

Router

? Can they accept an

onEditCard: (Uuid) -> Unit

event callback, so that the caller that does have a reference to the router can pass a lambda that makes the actual

router.goto

call?

yeh actually its a bit more complicated like that I had to come up with two themes, I can do this

Button("Click Me", onClick = goto(MemsetDestination.HomeScreen))

and that goto function looks like this:

@Composable
fun goto(destination: Destination, context: GotoContext.() -> Unit = { go() }) = goto(destination.uri, context)

@Composable
fun goto(uri: String, context: GotoContext.() -> Unit = { go() }): () -> Unit {
    val model = ambient(AmbientRouterContext)
    return {
        context(GotoContext(model, uri))
    }
}

I am going a bit nuts with it but its fun 😆 seriously cool stuff

and even easier if you passed lambdas that receive info that can be used to construct a destination

by pulling up navigation to top compose? I have been favouring passing down lambdas such as that

val cardActions = CardActions(
        editCard = { card ->
            router.goto(MemsetDestination.CardDesigner(card.uuid))
        }

 HomeScreenContent(state, cardActions)

is that what you mean?

sure, that's one way. If you have an object full of those it starts looking like an interface real quick 😄

defo seems a good idea to make composable functions not rely on to many things and have callbacks into complex parts of the UI tree, I was passing down my model all the way before I decided to pass lambdas down instead 🙂

yeah, lambdas and interfaces make good black boxes for carrying logic down

do you prefer individual lambdas passed to a function or an interface full of lambdas? its hard to say specially with default args make it not so much of an issue with Kotlin... I did think about wether

CardActions

was a good idea over just individual lambda per action (only got two actions so far, edit and delete)

depends on how many required callbacks you need. If several semantically-related lambdas keep appearing in the same place and are never separated, that sounds like an interface.