JetBrains / compose-multiplatform

Compose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.
https://jetbrains.com/lp/compose-multiplatform
Apache License 2.0
16.37k stars 1.18k forks source link

Add support for compose navigation #85

Closed sureshg closed 8 months ago

sureshg commented 4 years ago

It seems the current milestone release doesn't support compose navigation, which is very useful for any non-trivial application - https://developer.android.com/jetpack/compose/navigation

olonho commented 4 years ago

See https://github.com/arkivanov/Decompose for some implementation.

arkivanov commented 4 years ago

Or maybe just contribute to Decompose and advocate its usage? :-)

sureshg commented 4 years ago

@olonho thanks for the reply. Isn't compose navigation (https://developer.android.com/jetpack/compose/navigation) the official one supported by Google and used by most of the compose developers? IMHO, using a third-party library will split the ecosystem more than using the official one. Are you folks have any plans to support https://developer.android.com/jetpack/compose/navigation in the future?

arkivanov commented 4 years ago

My five cents here.

Decompose is a bit more than just navigation. It also provides Lifecycle, state preservation, ability to retain instances over configuration changes, etc. Here is an article about it. Decompose components are like Fragments (or BLoCs).

My own opinion - we should use Compose for dumb simple UI, and navigation and business logic should be kept outside of UI. This has one very big benefit: we can plug any UI. Decompose already supports iOS and JS. We already can write shared business logic and navigation. And easily plug different UI: Compose for JVM and Android, SwiftUI for iOS, React for JS, etc. Checkout this sample.

lukasroberts commented 4 years ago

It would be great if the team could make a final decision on this, as from using this framework, navigation is a key part of the development experience. For example when a developer asks how should I show a modal or new screen to accomplish a task, they need a definitive answer with supporting documentation.

Decompose or Compose Navigation, someone needs to make a final decision and advocate usage through the documentation.

JavierSegoviaCordoba commented 3 years ago

@arkivanov is it possible to split decompose to use only the navigation part?

I think that if there is an oficial way to navigate, it should be isolated instead of getting an end to end framework.

ggoraa commented 3 years ago

I think adding Jetpack Compose Navigation to Compose for Desktop is not a bad idea at all. Someone would prefer Decompose, someone will prefer JCN(like me). It is better to give people choice, what tools they want to use :D

arkivanov commented 3 years ago

@JavierSegoviaCordoba You can build your navigation with Decompose so it will be like Jetpack Compose navigation. You can create your Navigator like in this gist: https://gist.github.com/arkivanov/c19fbc0dac4b5c296cc4a888426fa17e

Usage example:


@Composable
fun Root() {
    Navigator(
        initialConfiguration = { Configuration.Screen1 },
        configurationClass = Configuration::class
    ) { configuration ->
        when (configuration) {
            is Configuration.Screen1 -> Screen1(onNext = { push(Configuration.Screen2) })
            is Configuration.Screen2 -> Screen2(onBack = ::pop)
        }
    }
}

sealed class Configuration : Parcelable {
    object Screen1 : Configuration()
    object Screen2 : Configuration()
}

@Composable
fun Screen1(onNext: () -> Unit) {
    Button(onClick = onNext) {
        Text("Next")
    }
}

@Composable
fun Screen2(onBack: () -> Unit) {
    Button(onClick = onBack) {
        Text("Back")
    }
}
arkivanov commented 3 years ago

Perhaps I could add the Navigator to the Decompose library :-)

JavierSegoviaCordoba commented 3 years ago

@arkivanov yeah, and should be great it was an independent artifact so everyone could pick the Decompose pieces they want.

Do you think it has sense to have more independent pieces or only navigation?

arkivanov commented 3 years ago

@JavierSegoviaCordoba I have doubts it is possible with Decompose, since the Decompose routing functionality does not depend on Compose. It is multiplatform and supports other targets as well. So it is possible to build Compose routing based on Decompose, but not vise versa.

arkivanov commented 3 years ago

There are Decompose extension modules for JetBrains and Jetpack Compose. So I will try to put it there in such a way so it won't leak Decompose. Filed an issue: https://github.com/arkivanov/Decompose/issues/15

olonho commented 3 years ago

Our general attitude is not enforce people to use certain third-party library, shall it be Decompose or smth else. Neither we are, at the moment, able or willing to support all possible libraries ourselves. So if someone will implement Jetpack Compose Navigation - would be amazing to use it with Compose for Desktop. But practically speaking, Decompose is flexible and widely ported solution supporting Compose for Desktop now, so using it looks like a decent option.

arkivanov commented 3 years ago

My personal advice is to avoid using Compose for anything but UI. But if you really want, please read the following article: A comprehensive hundred-line navigation for Jetpack/Desktop Compose. It explains how to easily create a Composable Navigator.

lukasroberts commented 3 years ago

@olonho If that's the general attitude, cool, however make sure that's written down on the front page of the docs under a navigation section. That way when developers go to look at how to achieve navigation, they may find something helpful like the article from @arkivanov that allows them to at least achieve something. Otherwise they will have to trawl the internet and find this github issue explaining everything which isn't ideal.

Tlaster commented 3 years ago

I've just published a Jetbrains Compose library that brings similar functionality of Jetpack ViewModel, LiveData, and Navigation to Jetbrains Compose, the source code is here: https://github.com/Tlaster/PreCompose, hope it can help.

arkivanov commented 3 years ago

Btw, there is a tutorial available: https://github.com/JetBrains/compose-jb/tree/master/tutorials/Navigation

lwj1994 commented 3 years ago

@arkivanov It looks a little complicated, consider separating the navigation separately?

decompose-navigation decompose-state ...

arkivanov commented 3 years ago

@lwj1994 The main decompose module contains only navigation stuff, and depends only on things required for navigation. Please note that it is a multiplatform module supporting many targets, and there is no dependency on any UI framework.

ArTemmey commented 3 years ago

@lwj1994 For those who think that Decompose is too complex, check out this one: https://github.com/ArTemmey/compose-jb-routing . It provides all necessary functionality for navigation in a minimalistic design.

brianguertin commented 2 years ago

androidx navigation's primary purpose is to handle back stacks, but desktop apps do not typically have back stacks. I don't think it should be part of Compose Desktop. But, if Compose for iOS is ever a thing, it would make sense there.

MarcusWolschon commented 2 years ago

You forgot that Kotlin-Multplatform also includes the web browser.

dragossusi commented 2 years ago

@brianguertin I have ported my android app to desktop and have back buttons in my app, I do need a backstack for this

MarcusWolschon commented 2 years ago

Any UI element that can be touched/clicked to navigate someplace else requires navigation to decouple the nagivation-destination from it's actual implementation. Any composable function that uses a ViewModel requires navigation for the job of cleaning up ViewModels based on the back navigation stack. Any drill-down, multi-step wizard or settings area that requires UP (not just BACK) navigation requires navigation.

subashz commented 1 year ago

If you find decompose to be complex, then give this https://github.com/adrielcafe/voyager navigation library a try, its easier to use and it just works. It also support android+ios+desktop+web and also has inbuilt screenmodel (replacement of viewmodel from android). This is the best library to work with kmm and kinda reminds me of swiftui navigation, instead of body, it's a content() composable functions.


class HomeScreenModel : ScreenModel {
    // replacement of viewmodel
}

class HomeScreen : Screen {

    @Composable
    override fun Content() {
        val navigator = LocalNavigator.currentOrThrow
        val screenModel = rememberScreenModel<HomeScreenModel>()
        // ...
            Text("Click ME")).clickable {
                  navigator.push(PostDetailsScreen(post.id))
           }
    }
}

class SingleActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            Navigator(HomeScreen())
        }
    }
}
GazimSoliev commented 1 year ago

Or maybe just contribute to Decompose and advocate its usage? :-)

Sorry, but ur library is so hard for understanding, I spend 4 hours to understand how to implement ur navigation, but I was tired and decided to use different library

FunkyMuse commented 1 year ago

Is there a youtrack issue for this, is this planned since the label has been recently changed to commonization?

I also found this https://youtrack.jetbrains.com/issue/KT-62479/Compose-Navigation-and-routing

But the access is restricted, it would be nice to see the proposal or implementation since it says status fixed.

MatkovIvan commented 1 year ago

@FunkyMuse Currently Compose uses this GitHub as a public issue tracker. So, you can follow the status in this thread. YT issue that you mentioned was just about third-party alternatives note in the docs and not about implementation or so.

sonatard commented 1 year ago

In future, Compose Multiplatform intends to provide an out-of-the-box navigation library.

https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-navigation-routing.html

hoc081098 commented 9 months ago

https://github.com/hoc081098/solivagant

I have published a library named solivagant:

Pragmatic, type safety navigation for Compose Multiplatform. Based on Freeletics Khonshu Navigation. ♥️ ViewModel, SavedStateHandle, Lifecycle, Multi-Backstacks, Transitions, Back-press handling, and more...

Hope it can help anyone who just needs a simple solution for the navigation in Compose Multiplatform 😁

MatkovIvan commented 8 months ago

Fixed in https://github.com/JetBrains/compose-multiplatform-core/pull/1219 and available in the latest dev build.

Usage example: https://github.com/MatkovIvan/nav_cupcake

Official examples/docs will be added a bit later

FunkyMuse commented 8 months ago

Fixed in JetBrains/compose-multiplatform-core#1219 and available in the latest dev build.

Usage example: https://github.com/MatkovIvan/nav_cupcake

Official examples/docs will be added a bit later

Wow, awesome 😎

The Android team just released safe arguments based on Kotlinx serialization.

I bet that's coming later or?

MatkovIvan commented 8 months ago

Yep, It's in my todo list after stabilizing the current version a bit

eygraber commented 8 months ago

Is there a plan for handling deep links, or will KMP applications have to handle that outside of the library?

mdsadiqueinam commented 8 months ago

Hi @MatkovIvan :wave: will this navigation is gonna support browser router?

MatkovIvan commented 8 months ago

Is there a plan for handling deep links

Yes, but not in the first release

will this navigation is gonna support browser router?

It's in our plans too, but again, not for the initial release

eygraber commented 7 months ago

will this navigation is gonna support browser router?

It's in our plans too, but again, not for the initial release

Is there anything you can share about the planned implementation for this? I wrote my own solution, but I think long term I'd like to switch to compose navigation (because other developers are more familiar with it).

It was tricky to integrate with the browser History API opaquely, so I'm curious about what your plan is to address that.

MatkovIvan commented 7 months ago

Is there anything you can share about the planned implementation for this?

Nothing specific for now - I didn't dig deep into it yet

eygraber commented 7 months ago

Good luck 😅

Some weird edge cases because of the History API's ability to go backwards and forwards, as well as move to an arbitrary item in the history stack.

okushnikov commented 3 months ago

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.