How to simplify sub navigation

I have a project that has child navigation three or four levels deep – i.e. VMs with child routers that call other VMs with child routers, etc.

Typically, one defines a view like this:


          <a repeat.for="route of router.navigation" ...>${route.title}</a>


However, since the child route is displayed in the router-view, the <nav> does not disappear once a child route is selected. In my case, this is fine for the parent navigation, but over time, as the user digs deeper into the children, the menus start to clutter the screen and make things confusing.

What I really want is something like this.

  1. Parent displays navigation to Child A and Child B.
  2. When Child A is clicked, Parent nav remains visible and Child A view is displayed showing Child A Nav that includes two routes Child A-1 and Child A-2.
  3. When Child A-1 is clicked – the entire Child A view is replaced (including the nav links for Child A-1 and Child A-2) and Child A-1 view is displayed (along with a breadcrumb that enables the user to get back to Child A view. (IOW, Child A Nav is no longer visible)

I hope that makes sense – I’m just having trouble figuring out where to put additional nav bars without making things too confusing for the user.

1 Like

I don’t have time to cook up a full solution for you, but the routers do emit signals when they switch route. Maybe you can listen to these and show/hide your navs as appropriate.

1 Like

@roddharris did you ever find a solution to this issue? It sounds a lot like the same issue I’ve run into.

If you have a solution, I would love it if you could share it with me.

1 Like

Unfortunately, no. I never really took time to follow up on the suggestion by @khuongduybui . The “hack”, I suppose, is to define all routes at the app level and use additional settings on the routes to control what gets displayed where.

I wound up just going a different direction since there didn’t seem to be a clear solution.

1 Like

Unless I’m misunderstanding the use case, this should be fairly straight forward and not that hard to achieve with Aurelia 2.

1 Like

Isn’t Aurelia 2 still in pre-alpha? If so, I wouldn’t want to build an application for customers with it.

What would your solution be, if it is the way you understand it and had to use Aurelia 1?

1 Like

It is, but it might still be good enough to use depending on the requirements of the application. I would probably not use it for an application for a customer, but using it is not completely out of the question.

I’d probably not use the configured routes as base for nav(s). Instead I’d have a service that’s injected into the view models (or something similar) be responsible for deciding what the nav(s) should contain. router.navigation isn’t always the best tool for the task.

1 Like