This is probably gonna be controversial, but anyway... Am I the only one who doesn't feel comfortabl...

# compose

[ste]

This is probably gonna be controversial, but anyway... Am I the only one who doesn't feel comfortable with navigation-compose? I feel like it clashes with "thinking in compose" mindset; are there third-party alternatives?

[Stylianos Gakis]

I found it natural since it’s basically the same thing as jetpack navigation not for compose. But in any way, this exists too, check it out https://github.com/arkivanov/Decompose

[Stylianos Gakis]

Oh and workflow https://developer.squareup.com/blog/jetpack-compose-support-in-workflow/ seems to have compose integration too

[ste]

I don't really like to involve Parcelable / Bundle (needed to pass any custom object) in order to call a function, it looks like a huge downgrade to me!

I'll take a look at decompose and workflow, thanks

[myanmarking]

it is not controversial at all. Many developers think that way, myself included. I disliked this library even without compose, and i’m not planning to use it when i migrate to compose

[darkmoon_uk]

You're not the only one. I've been advising new Compos adopters at work to look at navigation-compose as one option for Navigation and not to assume it's 'the' option for navigation - and pointing out the dissonance between the idea of an imperative nav stack and declarative UI.

[darkmoon_uk]

Also; as in this thread - I think sometimes folk jump for a navigation library before thinking smaller. For many sizes of App, a great navigation component is a when statement in a @Composable 😄. Throw in AnimatedContent and some notion of 'depth' to drive the left/right and you'd never know you weren't using a navigation stack.

[darkmoon_uk]

Data-reactive navigation is also really robust.

[ste]

I agree, I feel like when is more compose-friendly; you may end up having a lot more remember , but it follows the KISS principle, and that's enough for me

[ste]

I thought I was the weird one for not embracing the navigation component: it made more sense with the good (bad) old fragments

[Ian Lake]

Well, Navigation does follow all the same patterns as other Composables - hoisted state (the NavControlled is separate from the NavHost, ViewModel integration for hoisting state outside of composition entirely), events drive state changes which drive recomposition, and a strong emphasis on layering that avoids Navigation dependencies deep within your screens

[Ian Lake]

That being said, Navigation is purposefully built as just another library, using only public APIs of Compose. That means that there can and should be many opportunities for other libraries to fill that same need