Closed sureshg closed 8 months ago
See https://github.com/arkivanov/Decompose for some implementation.
Or maybe just contribute to Decompose and advocate its usage? :-)
@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?
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.
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.
@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.
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
@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")
}
}
Perhaps I could add the Navigator to the Decompose library :-)
@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?
@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.
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
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.
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.
@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.
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.
Btw, there is a tutorial available: https://github.com/JetBrains/compose-jb/tree/master/tutorials/Navigation
@arkivanov It looks a little complicated, consider separating the navigation separately?
decompose-navigation decompose-state ...
@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.
@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.
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.
You forgot that Kotlin-Multplatform also includes the web browser.
@brianguertin I have ported my android app to desktop and have back buttons in my app, I do need a backstack for this
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.
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())
}
}
}
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
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.
@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.
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
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 😁
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
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?
Yep, It's in my todo list after stabilizing the current version a bit
Is there a plan for handling deep links, or will KMP applications have to handle that outside of the library?
Hi @MatkovIvan :wave: will this navigation is gonna support browser router?
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
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.
Is there anything you can share about the planned implementation for this?
Nothing specific for now - I didn't dig deep into it yet
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.
Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.
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