Hi @David Herman I noticed that when assigning constants to the routeOverride of the @Page annotation the constant is not used and it reverts back to the default route config. I thought it will be better to reference route paths by variable so that they can be used around and help refactoring. OR better still is it possible that the generated routes are made available through a class so they can be referenced?

Try again in 0.14.1? (We just migrated to KSP, maybe it's smarter about that). But I think this is the sort of thing where the

@Page

annotation itself serves the role of the constant. You shouldn't be using routeOverride except in exceptional cases anyway.

Thanks for pointing out the default route config should be preferred, I'll work towards that. So I prefer using types and variables generally(easier to manage and autocomplete). To give you an idea of what I mean, 1. Something like the Nav args in Android Navigation graph 2. Something like the Ktor Location plugin for api routes.

Sure. And there are different libraries for routing out there that may allow for things to be more programmatic. I was inspired by how next.js organized their projects, and also I think it's useful to be a bit more rigid since publically visible URLs are involved. More thoughts on route override in the README section.

Thanks I'll check it out.

I'm realizing now that while Android apps have deep links, but for a web site, pretty much every page should be considered "deep link"able. I think this is why I'd push for something more like what Kobweb does than how, say, Jetpack Navigation works, where you have tighter control over what initial UI states are allowed. (But you can make a great experience with a programmatic, code driven Android Navigation approach as well, I'm sure)

Yeah true true, don't mind me bringing my android way of thinking to the web. Yeah web navigation and routes are already deep links out of the box.

You're all good! I enjoy the conversation, and I do have blind spots so it's good to chat.