https://kotlinlang.org
Join Slack
I'm working on a brand new compose app & I was wondering what most people use for compose naviga...
# compose
a
I'm working on a brand new compose app & I was wondering what most people use for compose navigation these days : 1️⃣ Jetpack compose navigation + accompanist 2️⃣ Compose destinations 3️⃣ Appyx 4️⃣ Voyager 5️⃣ Decompose Please vote with your number; if you're using something else feel free to comment below 🧵
1️⃣ 24
4️⃣ 5
5️⃣ 1
2️⃣ 3
3️⃣ 2
p
https://voyager.adriel.cafe/ Is also pretty popular
j
Decompose can be added to that list too
and compose destinations
a
I took portions of code from Voyager for our in-house navigation library, Voyager does a lot of things right
🔥 1
k
One thing I always question myself in these situations is that, do I want 3rd party tool to be backbone of my application, for the UI that's making such a big leaps forward. Jetpack compose navigation might not be perfect, but I still think having a same maintainer on navigation and UI library is a big plus.
a
To be fair, as long as you keep your app structured in a pretty modular way, you should be able to swap out and navigation library in minutes and be up and running with a new solution
Plus, you should do your due diligence and evaluate a core component of your app before you commit to it anyway
Personally, I try and stick with the big names that I trust like Google and Block, otherwise use in-house if nothing meets our demands otherwise
k
I am worried the most about maintainers suddenly slow or stop maintaining the lib, and companies project gets in a place where it has some incompatibilities with versions as Google raises theirs. so project just gets stuck with on old versions. I suppose if your navigation is well decoupled, you should be able to migrate easily, not sure if this is the case in practice.
a
Yeah, I agree there, which is also why we maintain our own in-house version. Google's current navigation library is an adequate for our needs, we were inspired by another, and wanted it to more or less fit our needs
k
That's possibly a best path for teams that have resources to maintain in-house lib.
r
Just wanted to add that I don't use any compose navigation for apps in production. Set compose content in a fragment and do the old fragment transaction way. Faced way to many crashes. For a side project I used the compose navigation+ Accompanist libray
a
When I say we, I mean me, I'm doing the Android rewrite of our app solo, the rest of the team is stuck working with react native 😂😂😂
f
you should be able to swap out and navigation library in minutes
I guess this is hyperbole, any non-trivial app will have deeplinks and nested graphs and other stuff that you'd spend several days refactoring to a new navigation
z
If its outside of compose, you will technically never need to refactor it? think smart
a
@Francesc I actually have a good amount of deep linking, it's pretty manageable
We're also able to use the same navigation library on Wear OS as well, it's pretty nifty (with swipe back support!)
f
If its outside of compose, you will technically never need to refactor it?
that's not my point, several of these libraries use code generation, so the solutions are rather custom, so switching frameworks is not necessarily trivial and a matter of minutes
a
The work can definitely be done to get to that point
f
that's not the point I'm arguing, but never mind
a
But it's definitely opinionated and depends entirely on your project
f
I just think it's disingenuous to suggest you can, in any non trivial app, swap navigation frameworks "in minutes", that's all
a
Hell, navigation as a whole is opinionated, no sense in arguing, just sharing ideas and feasibility of solutions as a whole, it's an open forum
p
a
I just think it's disingenuous to suggest you can, in any non trivial app, swap navigation frameworks "in minutes", that's all
Sure maybe not minutes, maybe a half hour, but that wasn't the takeaway either. More so that if your project is structured a certain way, you can ease the burden of swapping out a navigation library and have everything still working well
As well as any core component of the project in general, networking, data persistence, etc
Navigation is a big architectural component as a whole, and the goal, as with any architectural component, should be to have a clean implementation, that's all I'm saying.
i
If you've structured your Navigation Compose code like we've said previously (https://kotlinlang.slack.com/archives/CJLTWPH7S/p1645595702068129?thread_ts=1645552485.247699&cid=CJLTWPH7S), then none of your screens know anything about any Navigation framework at all: they are state in, events out, preferably KMP code. That does mean swapping out your Navigation framework should be straightforward to do, changing at most a single file per module. If your Navigation system requires embedding custom Navigation code into every one of your composables, that's a very tightly coupled system and makes a lot of things that should be easy, like testing, potentially a lot more involved.
p
The approach of navigating from the view model and not from within the UI composable by proxing a navigation event through a singleton class works pretty well and allows decoupled and testable code.
👍 1
a
I love how this went from which to prefer, to prefer all by being agnostic to the implementation 😂😂😂
a
Lmao, I appreciate everyone's input. People have also voted 🔥 really this post was for developer experience research. I'll spend some time today and tomorrow playing with the top 3 preferences and try to keep an agnostic implementation; the goal for me is to go back to my team and present options
y
Well when I jumped in #compose chat and saw initial message - I was thinking people will suggest best of the best multi-platform solution(Win/Linux/OSX/Android/Web/etc), but sad for me everyone voted for the solution 
Jetpack compose navigation + accompanist
that is tied to the android platform. I also interested in best of the best navigation, but for multi-platform
I think JetBrains need to have such solution for their JetBrains Compose, maybe take Decompose under JetBrains roof including main developer of it😁
s
How to have multiple Navigation Graphs with Compose Navigation + Accompanist? Like having a Bottom Nav with 4 tabs then having separate nav graphs for each tab. Don't want to use a library for navigation for now as I am learning.
a
I have a navigation viewmodel that exposes state that each screen listens on and animates accordingly.
y
I ended up using 
Voyager
as it more similar to what we use for Android e.g. viewModel and simple
k
@Yevhen Tienkaiev How do you like it so far?
y
At current moment(I still in dev) 
Voyager
looks good: it's buys me by lightness and easy to use. My app not complex, it's one screen + screen with settings. And app is for Desktop(not mobile). Full stack is Koin, Ktor(server part for dropbox oauth), Voyager, JetBrains Compose. Target platform Desktop(Win, Linux, Mac OSX)
j
I'm late to the party, but a side note to voyager: It doesn't handle the Lifecycle correctly. I ran into problems with the CameraX integration and other Lifecycle depended stuff. It also seems to be not maintained atm which is a bit sad, since it looked very promising.
y
Agree, as I mention, I think this core functionality needs to be a part of JetBrains Compose. I like 
Voyager
that it simple to use and not a heavy framework
a
@Stefan Haacker
k
@jannis This is so important for us programmers. We need to be smart with 3rd party libraries people, they are such a risk.
49 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by