vNext Router notes

[aurelia]

vNext Router notes

[Vheissu]

The ability to specify nested child routes the exact way Vue does it would be fantastic: https://router.vuejs.org/guide/essentials/nested-routes.html

The current approach of defining routes within child view-models is clunky and because they're not in a globally accessible place, you can't build menus that persist with all options without abstracting your routes out into a flat structure and hacking together your own functionality to do it.

I understand we can define routes flat now and create a childlike relationship, but it's not. If we had a child property we could do something in our views like this:

<template>
    <ul>
        <li repeat.for="row of router.navigation">
            <a href.bind="row.href">${row.title}</a>
            <ul if.bind="row.children">
                <li repeat.for="child of row.children">
                    <a href.bind="child.href">${child.title}</a>
                </li>
            </ul>
        </li>
    </ul>
</template>

I have seen many workarounds for creating this in the community and the approach I have used before is defined routes flat, for each child route create a descriptor of what it's parent is and then programmatically create a hierarchy for my menu structure.

I am definitely not a fan of the current approach where child view-models have a configureRouter method and define their own routes, because they only exist when the view-model is active, which means you cannot build up a menu ahead of time and have to resort to breaking out your routes into a flattened structure, then hacking away using settings to define the parent or a regular expression to parse what the parent route is.

[rluba]

ui-router for AngularJS is catastrophically bloated and has lots of problems (patternitis being one if them) but it does several fundamental things much better than Aurelia’s router. I have two big issues with vCurrent routing in Aurelia.

Child to child navigation

It’s impossible to navigate to a different child state by using its name and params. I have to manually build the target state’s URL and remember that for all future refactorings.

An example:
We have two states rootA and rootB who both have two child states;

• rootA
  • childA1
  • childA2
• rootB
  • childB1
  • childB2

While the app is in childA1, I can navigate to childA2 or rootA or rootB by using their names. But it’s impossible to navigate to childB1 or childB2 without hard-coding their URL parts and parameters and manually constructing an URL out of it.

AngularJS’s UI-Router solves this perfectly with both absolute and relative state names:

• rootB.childB1 works from any state
  *^.^.childB1 would navigate from childA1 to childB1

You can use the same navigation method (name + parameter object) for all state transitions instead of having to fall back to URLs for some transitions.

Side note: I think that the concept of navigating relative to the current state (like ui-router) is more elegant and intuitive than navigating relative to the current router (like vCurrent) when dealing with nested child states.

Typed parameters and automatic conversion

As hinted at in @davismj’s original post, it’s really useful to declare a parameter’s type. It allows the router to handle parsing (URL to param) and formatting (param to URL) and gets rid of lots of boilerplate code and error checking inside states (i.e., view models).

I was able to implement parameter parsing in vCurrent via a custom authorizeStep but there’s no way in vCurrent to influence how parameters are serialized when URL strings are assembled by the router (eg., when using navigateToRoute).

Being able to declare custom types via a set of simple functions (encode/decode/equals) is really useful as well.

[fkleuver]

@timfish We plan to significantly improve overall logging and error handling via the global reporter. The router is definitely something we'll have make good use of that :)

[timfish]

A minor gripe with the vCurrent router, but navigation failures should really bubble up the the global error handler rather than be caught. We had a bug that went unreported for weeks and it would have been fixed within hours if it had come through Sentry error reporting.

[EisenbergEffect]

Thanks for creating this! @davismj When you are freed up, let's use this issue to start defining the features, characteristics, apis, etc. that we want in vNext for router. No implementation, just imaging the developer experience and the runtime behavior.

[shahabganji]

@davismj , @EisenbergEffect

I like this new proposal, particularly the addition of beforeEnter which in conjunction with the AutorizeStep will make routing guards more flexible than ever. also as @Vheissu mentioned having child properties rather than view-models having configureRouter method not only will ease many menu building approaches but make codes far cleaner and maintainable.

I am just curious to know whether do we have these two features in Aurelia routing, and if not is there any plan to implemet them:

1. Lazy-loading routes: I mean that we can separate a group of routes in a way that their scripts and HTML components being fetched from the server and then loaded into memory when they are required NOT at the initial loading step by the route-engine something like the one in angular. I guess it forces loaders to make separate bundles and defers their loading.

2. Secondary Routes: I know we have view ports, but some times you need to have the url to support routing for more than one primary route, each of which may contain multiple componetns. maybe some mechanism like this

At the end, I should say well done, and keep up the good work 🤞 👍 .

[davismj]

@shahabganji Thanks for the kind words.

re lazy loading: I think that's what we have today. No routes are loaded until they are absolutely required. The view-models themselves have canActivate and other activation lifecycle methods that may prevent the route from loading, but the view-models need to be loaded to get these functions, and the view-models aren't loaded until one of these are required.

re secondary routes: Also think we have this today with view-ports. I'd love to get a better idea of what secondary routes can do that view-ports cannot.

[shahabganji]

@davismj

No routes are loaded until they are absolutely required.

AFAIK and as you said, no routes are loaded into the routing engine( route table ) until they are required, am I right? If yes then we have a misunderstanding. What I meant is that in one way or another being able to separate the routes of one module say announcements from the bundle of another say blogs and one of them being the primary which its related components( .js, .css, .html files ) are loaded at bootstrapping of the whole SPA app, later on, if anyone clicked the blog route then an HTTP request is made to load components ( .js, .css, .html files ) for that module and the process will continue. If we already have such behavior implemented in the framework please guide me through 🙏

☝️ The blog bundle is separated from the main bundle and it will be fetched( by Http requests ) when required and its subroutes will be added to the routing engine later on.

Also think we have this today with view-ports. I'd love to get a better idea of what secondary routes can do that view-ports cannot.

With view-ports we allow multiple components being on the same page for a given route. however, consider the following:

• http://localhost/announcements/2-aurelia-routing(chat:users/davismj)

---

• http://localhost/blogs/3-how-to-do-dynamic-routing(chat:users/davismj)

Needless to say that the route in parentheses is independent of that out of it. for instance, I could chat with another guy while still on the page related to /announcements/2-aurelia-routing and the url would be :
http://localhost/announcements/2-aurelia-routing(chat:users/eisenbergeffect)