https://kotlinlang.org logo
#compose
Title
# compose
s

ste

12/06/2021, 9:31 AM
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?
👍 1
😀 4
💯 5
s

Stylianos Gakis

12/06/2021, 10:06 AM
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
👀 1
Oh and workflow https://developer.squareup.com/blog/jetpack-compose-support-in-workflow/ seems to have compose integration too
🌟 1
s

ste

12/06/2021, 10:20 AM
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
m

myanmarking

12/06/2021, 10:55 AM
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
1
d

darkmoon_uk

12/06/2021, 11:30 AM
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.
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.
Data-reactive navigation is also really robust.
🙌 1
s

ste

12/06/2021, 11:52 AM
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
💯 1
I thought I was the weird one for not embracing the navigation component: it made more sense with the good (bad) old fragments
i

Ian Lake

12/06/2021, 2:08 PM
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
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
1