Aurelia Router: Events + long running "load"

Hi,

since today is Saturday and the weather is bad, I thought I’d test Aurelia 2 a bit. First, congratulations for the documentation and the product itself!

However, a few questions came up while testing:

There is no information about the event aggregator in the documentation yet. Is this content simply missing yet or is there another reason?

I did not find any information in the documentation if and which events the router publishes via the event aggregator. Is this information still missing, did I overlook it or are there no events at all?

The documentation says that data should be loaded from the web server in “canLoad” or “load”. However, if this process takes a bit longer (e.g. 500ms), then the application seems sluggish, as it looks to the user as if nothing is happening. How exactly would you handle this topic? In our current app, we display a marquee bar instead of the route content when the loading process takes longer than 200ms. Once the data is loaded, the marquee bar is removed and the actual content is displayed. However, since the route is not yet visible during " canLoad" and “load”, this can no longer be done this way. The first hook that would be possible for this is “attaching”, however the children do not wait until the attaching promise is complete.

Thanks!

Hi @stefan! Glad you liked Au2. For the long running load checkout the promise.bind here: Built-in template features - The Aurelia Docs.

That’s built keeping exactly this use case in mind. The idea is that you can bind a promise in the template and the elements will only be rendered once the promise is settled. Optionally you can also show some another element, such as waiting message, during the time the promise is pending.

Hi Stefan, I am going to make some updates to the documentation in the next day or so for you. The event aggregator is on my list for documentation, just towards the bottom, but it’s an easy one for me to cover.

Further to your point, thank you for bringing the lack of events in the router docs to my attention. I used to use events extensively for routing in v1, but haven’t in v2, so they’ve gone under the radar.

As things currently stand, the router emits the following events via the event aggregator you can subscribe to. These might change when some router changes are made shortly (but, I’ll do my best to keep them the same).

  • au:router:location-change
  • au:router:navigation-start
  • au:router:navigation-end
  • au:router:navigation-cancel
  • au:router:navigation-error

Hopefully, this ties you over until I document these.

1 Like

Perfect! Thanks for the clarification.

Hi @Sayan751,

I think this new template feature is great, but it’s not 100% what I was looking for.

My intention was something that would allow me to globally make delayed loading of views visually visible without having to implement this in every single view. Besides that, this is exactly what I was looking for.

The “load” hook would be a good approach for this. But after the router waits with further processing until the returned promise is done, it seems like the application is sluggish (as said before). @dwaynecharrington so I’m a bit doubtful if it’s good to write in the documentation that URL dependent loading of data in “canLoad” and “load” is really a good idea.

@dwaynecharrington another question about the router’s documentation: are you planning to document the router’s “stateful” feature in the near future? So far I have not managed to properly enable and test this feature or find any accurate information on it.

This is a knock-out criteria whether we can work with the built-in router or have to create our own router again (as in Aurelia v1) (see Routing with preserving previous view/viewModel).

Thanks!

1 Like

Hi @stefan are you looking for a router hook instead? Route hooks - The Aurelia Docs - this allows you to delay loading of views on a global basis based on common criteria.

Hi @dwaynecharrington no, unfortunately that doesn’t solve my problem either. I will create an example to illustrate the topic.

I would suggest going for a singleton ‘state’-service where you can register a ‘load’-promise and use that in the root-view/template. Then you can show some wait message whenever there is a pending ‘load’-promise.