Web Browser routing support

[Nikola-Milovic]

Raising an issue as per the conversation over at MVIKotlin Slack channel

As discussed, what do others think about having the support for routing in web browsers (eg having paths in the URL, yourwebsite/users/profile and etc...).

There are two main options for the URL paths:

1. Hashed paths
   eg. example.com/#users/profile

Consider one page website, or website built fully on AJAX, without any page reloads.

#hash helps such applications to push state of the application to the client, this helps the application itself to be aware of the state and the client (and browser) to be aware of the state. This will also help the user to bookmark the application in its' current state and use back and forward buttons (browser history).

Which basically is Client Side way of telling where we are, it's easy to implement but a bit uncommon and not what the people are used to. As it doesn't require page refreshes

2. Normal paths
   eg. example.com/users/profile

More common, the paths we are accustomed to seeing. A bit more difficult to implement.

Issues that are currently present while developing for web that can be solved with this:

1. Refreshing the page returns you to the root and not just the "page" you were on
2. Nicer looking URL's, since currently all pages live in the /
3. Support for History (going backward and forwards in the browser). Most notably on Desktop, you are sometimes stuck between Parent and a Child on Desktop as there is no back option unless you manually add a button.

Implementation

As for the concrete implementation, I am not sure. But here are some of my notes

1. Changing the path should change the configuration, alongside pushing a new configuration should update the path. So the entity responsible for the path should be aware of the possible configurations
2. How would it integrate with the current way navigation is handled (talking about the implementation), of pushing configuration onto a router that is being observed in your UI solution (Compose, React...). As the navigation is currently platform-independent.
3. Can it be made in a way that doesn't affect the existing code for other platforms? Maybe even keep the existing code for the web alongside some additional setup at the beginning to map all of the routes.
4. Parameters, dynamic URLs. Currently, with configurations, you can pass pretty much anything to the children, but for the URL's this wouldn't be the case. So if we push a complex configuration via the existing code that may not be possible to map to a path with parameters. This would mean that a possible limitation could be to not allow manually altering the path from point 1. Considering that this works in other solutions like NextJs and React with Navigation libraries, this shouldn't be an issue.

Please correct me if I am wrong on anything, and do add some more input.

This is primarily based on similar solutions existing for Compose on Web

[arkivanov]

Thanks for such a detailed explanation. I will start thinking about it and will provide updates here.

[arkivanov]

Moved to arkivanov/Decompose#1