I'm looking for advice on building navigation for ...

# kilua

[neworldlt]

I'm looking for advice on building navigation for the admin panel, which includes many pages organized into a multilevel navigation tree. My goal is to avoid writing related code in multiple places. Ideally, it should be possible to reconstruct routes and the nav bar from the injected`ListPage`However, I am also okay with the route file.

At first glance, the real-world example could work fine at a single level, as I could automate filling both routes and the nav bar. However, I have no idea what to do with the second level, as this example contains code in both places (#1 and #2). What I dislike is that the code in both places must match precisely.

Maybe I could use compose navigator assuming it will work with kilua and I could set multilevel router.

Just an idea, but if I could get a navigation tree model from `kilua-routing`and when I could reconstruct the nav bar from it.

[Robert Jaros]

A navigation tree model would be also useful to implement https://github.com/rjaros/kilua/issues/38. I'll investigate this idea.

[neworldlt]

@Robert Jaros, if you need any assistance, please don't hesitate to let me know. I am pretty new to web development, so for now I can not have many ideas.

[Robert Jaros]

After playing a bit with the code I don't think this idea can be implemented. Currently there is no navigation tree model we could start with. The routing configuration is just a kotlin code declaring a composition. The functions used at deeper levels are not even executed until navigating to the matching locations. And finally the routing in Kilua can be (and often is) dynamic so there is nothing you could use to create a nav bar.

[Robert Jaros]

I'm trying now with an opposite approach. Create a tree model first and then use it to automatically declare routing.

[neworldlt]

I'm trying now with an opposite approach. Create a tree model first and then use it to automatically declare routing.

This approach is what I am trying to implement (providing routes via injection), but I haven't had time recently. Thanks for trying to solve it.

[Robert Jaros]

I've come up with a totally new DSL for routing definition, which is wrapping the original routing API, so it should behave exactly the same at runtime. The new API is probably a little bit more verbose, but offers some important features:
• It builds a typical tree model, which can be easily accessed at runtime (e.g. to build a navigation UI)
• It allows to get all declared static routes for automatic SSR export or sitemap generation
• It allows to declare metadata for SSR generated (or exported) pages (fixes #38)
• It automatically declares routings for all cases (for correct SSR implementation), so no more missing empty noMatchAction {}
I'm playing a bit with the code and migrating some large applications to test this new API in practice, but so far it seems to be working fine.

[Robert Jaros]

Also no more need for two SSR routers. Async calls will be automatically used when declared.

[neworldlt]

Great news! Can't wait to try