I am having a hard time understanding the rationale behind using Accompanist for Compose Navigation...

# compose

[Mehdi Haghgoo]

I am having a hard time understanding the rationale behind using Accompanist for Compose Navigation animation. As I understand from @Ian Lake’s article on Medium, navigation animation APIs are not yet stable in Compose, so we cannot use them directly, because they will break out code. On the other hand, when we use Accompanist navigation animations, they are also annotated with ExperimentalAnimationApi. So, kind of confused, we are using experimental animations anyway, why bother using them through another library like Accompanist?

[Mehdi Haghgoo]

Does this mean the code that uses Accompanist will not be broken any time soon with new updates to animation or navigation APIs?

[Ian Lake]

In fact, Accompanist Navigation is also broken right now if you are using the latest Compose 1.1.0 releases precisely because it uses Experimental APIs that changed out from underneath Accompanist: https://github.com/google/accompanist/issues/773

[Ian Lake]

But as per that issue, Accompanist will just upgrade to depend on Compose 1.1, thereby fixing the issue

[Ian Lake]

That isn't the case for Navigation 2.4, which will never break with any new version of Compose because it only uses stable APIs

[Ian Lake]

But there's no stable alternative for what Accompanist Navigation uses - either you get nothing or you live on the edge. That's why you get a choice between Navigation 2.4 and Accompanist Navigation

[Mehdi Haghgoo]

Can we say Accompanist itself depends on Navigation 2.4 and Compose to provide a richer (animated) Navigation?

[Ian Lake]

It uses experimental APIs in Compose to provide more control over animations than is possible with stable Compose APIs alone. It is still the same Navigation 2.4 base