What role do Fragments (and to a lesser extent, the Navigation Component) play in a

@Compose

world?

As much of one as you would like, especially depending on whether you're introducing compose into an existing codebase or writing more green field code

I’m looking in the context of a fresh app (no legacy code) and looking for general best practices

yeah our intention is to provide a compose Navigator for the navigation arch component. It was designed to not be fragment-specific. There's a lot of tooling work that we'd like to have around it in android studio to call it a product on par with the current experience, so it's probably going to be a post-compose 1.0 thing, but nothing should stop you from writing your own in the meantime if you don't need that tooling integration yet.

oh gotcha. So usage of

NavigationComponent

would not change all to much then?

TBD. Probably something along the lines of

@Composable (???) -> Unit

function objects as part of the destinations rather than fragment names or factories

Ah gotcha, I would be curious how observing a `ViewModel`’s

Flow<State>

would play into that without a

Fragment

so as you construct the destinations in the graph you'd be doing things like

ComposableDestination(???, ::MyScreenComposable)

like technically I don’t think we care about

Fragment

- just the

LifecycleOwner

of it’s view

right. You may or may not strictly need it; composables have their own commit/dispose lifecycle that is easy enough to get at, but that doesn't give you the visibility implied in start/stop.

what’s an

ambient

😆