I am just experimenting with Compose navigation an...

# compose-web

[Michael Paus]

I am just experimenting with Compose navigation and the new

window.bindToNavigation(navController)

for wasmJs in 1.8.0-alpha01. The binding part seems to work. The back-button of the browser now works in a similar way to the back-button on Android with one exception. Calls to popUpTo seem to be ignored. I am using the following function to navigate

fun navigate(route: Any) {
    navController.navigate(route) {
        if (route == Favorites || route == Info || route == Map || route == Schedule) { // Primary screens
            popUpTo(navController.graph.id) { inclusive = true }
        }
    }
}

which should clear the back stack when I navigate to any primary screen. This seems to work in Android but in the browser the stack does not seem to be touched. Does anybody know what is going on here?

[Konstantin Tskhovrebov]

No. It doesn't work as android's back button.

It works as browser navigation: back and forward

[eygraber]

@Michael Paus you can check out my implementation of this which should support what you're looking for. It's part of a larger system that I've been meaning to extract, I just haven't had much time to work on it lately.

[eygraber]

The syncWithHistory function is the part you might be interested in

[Michael Paus]

@Konstantin Tskhovrebov From a programmers point of view I find this behaviour highly confusing. The navigation API is already complicated enough and if it now also starts to be dependent on the platform which actual effect each API call has, then I am totally confused, especially as this does not seem to be documented anywhere.
From a user point of view I am actually not sure which behaviour is actually desirable. Isn’t behavioural consistency over platforms more important than to mimic traditional browser behaviour at all costs? Especially as wasmJs is probably not used that much for traditional web pages but instead is used more for desktop-like web-apps.
@eygraber Thanks for the example code. I still try to understand it 😉. What was your motivation to implement that behaviour?

[Konstantin Tskhovrebov]

It will be documented together with the stable release.
It confuses android devs only. For web devs it does matter to have standard back and forward navigation
We discussed internally and decided that a disabled forward button is worse by default.

[Michael Paus]

I am not an Android developer and I guess there are many more Android developers using Compose for Web than there are web-developers using the same 😉. Will there be an option to disable the forward navigation?

[Konstantin Tskhovrebov]

at the moment we don't have a plan to add it.
you could try to implement your own behaviour of the browser nav buttons though

[Konstantin Tskhovrebov]

BTW, there are other things you have to support then. e.g. if app loads an url on the same page then navigation will behave different

[Konstantin Tskhovrebov]

browser history API is not just callbacks on button's clicks