Aurelia Routing with a Parameter

A post covering the same concepts but with updated versions of ASP.NET and Aurelia can be found here.

I have spent some time building out the client side of my contacts application using Aurelia. For a starting point with Aurelia check out my previous post on Aurelia with ASP.NET 5 and Web API and Start Aurelia from an ASP.NET 5 Controller. In this post I am going to cover passing a parameter via routing.

Keep in mind I am serving this application from ASP.NET 5 and all the Aurelia related files are in the wwwroot folder of my ASP.NET 5 project. App.html and app.js in wwwroot with the remaining Aurelia files in an Aurelia folder.

project

In app.js a new route was added for the detail view. Make special note that the new route expects an id parameter.

In list.html the contacts need to be rendered with an anchor that will lead to the proper detail view. To accomplish this Aurelia has a route-href custom attribute that can be used with an anchor.

With route-href route, set to detail above, defines the name of the route from the route config. Parms.bind creates an object with an id property which is bound to the id defined on the route. Any property on the object that does not have a in the route definition will be added to the query string.

When one of the routing links is clicked then on activation detail.js queries the Web API for the contact details based on the id in the parms.

No real new concepts in the above. On active the Web API is called and the resulting json is used to populate a contact property.

The detail view then uses the contact property to bind to the contact information.

The above results in the following view.

contactDetailView

10 thoughts on “Aurelia Routing with a Parameter”

  1. When I use a list similar to the canonical child-router.html from the skeleton, and I use the normal “nav: true” routes, the node highlights as having been “selected”. When I add some elements from a list like your example and select them, it works fine as does your example. However, the item does not “select” (add the “active” class” the same way because there is no hooks in place to set the “isActive” flag. Have you come up with a solution for that also?

          1. From what I am seeing the constructor for settings is only run once which is creating the routes set for Paul. If you look at the links for Profile in the setting nav for Charlie it will look like this: href="#/users/settings/Paul/dashboard2" and as you can see that is pointing to Paul instead of Charlie.

            In your settings.js file add this import: import {activationStrategy} from "aurelia-router";

            And then add this function:

            determineActivationStrategy() {
            return activationStrategy.replace;
            }

            With those two changes the issues I was seeing in your example seem to be fix. Please follow up and let me know if fixes the issues you are seeing.

          2. Thank you Eric, you are very generous with your time.

            This sounds promising,and i will try it shortly.

            The reference to activationStrategy brings up concepts for a future area of development: The application will have a “dock” that will hold “currently active transactions” that can be reactivated quickly. I need to to decide between two possible approaches: 1) that each “active” transaction, when de-activated, stores it’s state, then reloads its state when re-activated — OR 2) that each “active transaction” stays in memory and is simply re-shown from memory. (I’m answering my question as I’m writing it!) The best way to describe the behavior is that of a multiple-document interface – where multiple transactions can be started and minimized the way Windows minimizes them to the task bar. They are still in memory, no longer taking up space in the main part of the screen, and reactivate at the speed of RAM rather than from being retrieved from he server.

            I believe activationStrategy will be “app-wide”, is that correct? When the app re-opens a route, it will ALWAYS re-run constructor, configureRoute, and activate routines, is that correct?

            In any case, thank you kindly! Where are you located? I owed you a beer or a coffee!

            Paul

  2. It is great how just the act of talk/writing something out will trigger things in our own heads.

    I am not sure about the scope of activationStrategy, but I would think it would only change the behavior of the component it was added to. That is a good question on the constructor. I would have to rerun samples and watch the logs.

    I am in the Nashville, TN area. If you are in the area we should meet up!

  3. Hi Eric, the activationStrategy change has fixed this specific issue! Thank you. I will delve more deeply into understanding why and let you know any more insights I find while doing so. I wish this were my primary project as I think my progress would be faster. Paul

Leave a Reply

Your email address will not be published. Required fields are marked *