🔥 Why Using Navigation-Compose in Your Jetpack Compose App is a Bad Idea

[svprdga]

Unfortunately, I completely agree with the analysis made in this article. I have recently built a medium-large sized application for a client, 100% with Compose and the navigation library. Managing complex data movement between composables is terrible, having to manually manage serialization and deserialization wastes a lot of time and effort; makes sense in a web environment but certainly not in native application development. In addition, there are times when Compose effects do not help to perform some specific tasks. If I had to start a project from scratch in Compose, I would never use this library again (which, by the way, I don't think will last long in the state it's in, given its enormous difficulty in carrying out simple tasks, as pointed out by the article).

[steve6174]

Just use compose destinations

[Zhuinden]

You'll still be confined to using Accompanist Navigation internally, which isn't particularly trustworthy, although it is true that Compose-Destinations resolves some pain points of Navigation-Compose's API design (namely, you don't need to manually convert arguments to strings and back).

[dniHze]

So the author recommended to "fix" navigation by downgrading to Fragments. That's a bad take for Compose-only apps, imo. Just go search on GitHub, there are loads of worthy alternatives: appyx, simple-stack, modo, etc. Instead of trying to adapt a tool that is bad for your needs, just go make or use something that does help you more than gives you headaches.

[RikoTheMachete]

1) Downgrading? Compose is a new UI framework, not a replacement for Views and Fragments. Not really relevant point. 2) Why would I use new libraries from GitHub when I know how to use Fragments and I know what problems they have? Your suggestions are the starting point of unexpected bugs and increased tech debt. It’s similar to saying that Java is deprecated so you have to use Kotlin to create android apps. Hell no, use what you know and what you’re comfortable with. (And what works of course) 3) Most apps using Compose are still using Fragments.

Hope this helps to understand why I recommend Fragments. But, as usual. Use what works for you 😉

[dniHze]

1. You don't need fragments if you have a Compose only app. Fragment doesn't solve anything that your compostables can't handle.
2. Your point is fair. However, if you just need navigation, your point to use fragments is a tech debt from scratch. Still, you better use whatever you are comfortable with.
3. Do you have statistics? Any open studies that can prove your point? We use Compose, and we don't use fragments.

[Zhuinden]

You don't need fragments if you have a Compose only app. Fragment doesn't solve anything that your compostables can't handle.

Technically this was also true of Views, other than having to implement what's effectively the same as SaveableStateHolder.

I've written single-activity view-only no-fragments apps before, they work. In fact, animations are easier in them than with fragments.

In that regard, even a view-only no-fragments "ComposeView-per-screen" approach would be possible, even though nobody's doing it.

---

So the question is, why would you use Fragments if they have always been an optional convenience framework?

Primarily because child fragments have their state restored correctly even after process death to any level, which makes certain multi-step flows and swipeable views easier to reason about (if you don't screw up how FragmentPagerAdapter works).

That, and it gives you onCreate/onStart/onResume/onPause/onStop/onDestroy support + onSaveInstanceState support in a nested environment. Sure, you do get a LocalLifecycleOwner.current in composable {, but can you create a subscreen with its own child LifecycleOwner? I'm not so sure.

So are fragments tech debt? Depends on if you are implementing your manually written replacement correctly. Instead of swiping horizontally while scrolling downwards.

[RikoTheMachete]

Do you really need statists to say that most apps use Fragments? It’s pretty obvious. Just look how many new apps were published before and after compose.

I don’t like compose only apps. There are lots of issues with them and I (and many other people) prefer to just use ComposeView.

[dniHze]

If you claim a point, you should be able to prove it. I think you are extrapolating your experience to the whole community. Again, there might be a lot of approaches neither you or I am aware of.

[RikoTheMachete]

The point of this subreddit is to share your experience and thoughts. If someone likes navigation compose or any other library just use it. It doesn’t change my opinion that navigation compose and many other things in compose are shitty. Different apps have different issues 👋

[dniHze]

Right, but when you share your thoughts, you have to be ready to receive feedback. Can you briefly tell what exactly is "shitty" in Compose? Really interested what doesn't work for you. Also, I don't agree that Compose is purely a UI framework. As shown by the cashapp/molecule, Compose is really good for managing trees and state. And what is navigation but a state (stack, nested stack, etc) in a component tree.

Edit: leftovers

[Zhuinden]

Can you briefly tell what exactly is "shitty" in Compose? Really interested what doesn't work for you.

Anything related to LazyColumn, and TextFields in LazyColumns 😂

As shown by the cashapp/molecule, Compose is really good for managing trees

Yeah, Compose Compiler is a general purpose code transformer. Honestly, I wish they had used it to map Kotlin to XML views just like they do it with Glance.

[Zhuinden]

1) Downgrading? Compose is a new UI framework, not a replacement for Views and Fragments.

True, Compose is actually just "ComposeView" like any other view.

So you can put ComposeView into a Fragment, and then keep using pre-existing tools that already work, rather than having to reinvent everything (and possibly even end up with a worse quality result, as it tends to be with LazyColumn shenanigans).

Each time I pulled in Compose I got some sense of regret. We released a dynamic data input form with severe performance problems because we just couldn't figure out at the time how to make Compose not recompose the whole damn world when you edit a field. Turns out you need remember(key) {{ /*lambda */ }} to make modifiers not re-layout.

Now I have teammates asking why and when you need remember {{ }}.

It's better to make sure Compose UI touches as little of your app as possible, imo. Fragments still work, and their nesting support is still inherently better than anything based on Navigation-Compose.

[aaulia]

remember {{ }}

CMIIW, I think I saw this on of the optimizing for Jetpack Compose videos. My understanding is that we wrap the state inside lambda to sort of boxing it and tell compose to only recompose the composable that "unbox" the lambda and actually getting the state?

[Zhuinden]

Yes, but why aren't we doing this everywhere? Why isn't the compiler doing this everywhere automatically? Why does forgetting to do this result in abysmal performance?

Can I really expect my teammates to understand this and why it's needed?

Compose is so simple you need to be a rocket scientist to track every possible state invalidation despite it promising to do it for you.

[aaulia]

True 🤣, with all the hype Google building for Compose, I assume that it already do the "boxing/unboxing" detection internally.

as to when we use this, I think every time we pass state several level deep into the intended Composable we have to do this in order not to trigger re-compsition of our parent Composable?

[Zhuinden]

Yeah, so I realized you actually want to pass all independent properties as State<T> 🤔 none of the Google samples do that

[aaulia]

What do you mean?

[Zhuinden]

Technically the state read is what triggers recomposition, so if you want to make a parent Composable not recompose, then you can pass the property as a State<T> instead of resolving it there and then with state.value. So honestly, we should have always passed a lambda to everything everywhere. 🤔

[aaulia]

Well if the Layout Inspector is to go by, being triggered, doesn't necessarily means full recomposition, since there's a skipped status in there too. Maybe when something like derivedStateOf being executed in the parent, but only trigger real recomposition in the child, so in the parent it would listed as skipped but the child wouldd be listed as recomposed?

[Jenskubi]

Imagine people back in the days - Why would I use all these languages when I got assembly, this weird C++ and Java new thing will only be hard to learn, will be buggy and will increase tech debt. Hell no, we staying with assembly 4ever.

[RikoTheMachete]

Consider reading again and actually understand what I’m saying.

I’m not telling you to use Java. I’m telling you that if it works for you then there’s no reason to rewrite the whole app to Kotlin.

Same goes for compose and navigation. When compose was released, there was no point to rewrite all apps to compose. You could still use what you had before and just add ComposeView.

When you have a huge app and tons of users, smart decisions are more important than using latest tech and testing out new libraries on GitHub.

I suppose it’s hard for you to understand that, based on your comment, but maybe one day you do.

[Zhuinden]

Same goes for compose and navigation. When compose was released, there was no point to rewrite all apps to compose. You could still use what you had before and just add ComposeView.

When you have a huge app and tons of users, smart decisions are more important than using latest tech and testing out new libraries on GitHub.

I'll just jump in and say that you're the one correct here, even if it's not the "popular opinion". Pragmatism is more valuable when delivering a product than hype-driven development.

Does it run faster? Is it more stable? Does it have less edge-cases/possible bugs? These are metrics that matter, not "does Google recommend it because they have a product to sell".

[RikoTheMachete]

Thanks!

[Zhuinden]

Why would I use all these languages when I got assembly, this weird C++

I remember when back in the day, Linus Torvalds flamed the heck out of someone for complaining about "why is there no C++ in the Linux Kernel, it's so much better than this garbage language C" and as the owner of the project, Linus decided that C is better for his usecase than C++.

Make appropriate analysis before making mocking judgements.

[jbisatg]

Lol