Posted on by & filed under Content - Highlights and Reviews, Programming & Development.

A guest post by Balint Erdi, an Ember.js consultant. The more he does Ember.js, the more he loves it. So much so that he even has a mailing list with a screencast series on how to build an Ember.js app step-by-step.

Ember.js is a client-side application framework. One of its core principles is that the URL should drive the design of the application. Consequently, the router and helpers related to routing have a very rich API.

In this post, I’m going to show how Ember creates markup for links that can be used to indicate whether or not they are active.

Moving Around

Let’s assume we have a small application with the following routes:

The link-to helper serves to transition to a new route in the application. In its most simple form, it just takes a route name parameter. The content of its block is going to be the content of the generated anchor tag:

Making Active Links Visibly So

It is often required to make links that point to the current route look differently. A classic example would be a navigation bar where the link to the current page would be grayed out.

Ember.js takes care of this by adding an active class to the link if the route it points to is equal to one of the currently active routes. Both the Bootstrap and the Zurb Foundation frameworks modify the look of active links, and so app developers coming to Ember.js working with one of those frameworks have a magic moment. Their current links are marked visually without them having had to do anything.

If we define a link-to to the bands route and the current URL is /bands, that link is going to have an active class.

Context Matters

Let’s suppose that we display a list of bands in the application where each band has a link to the band’s details page:

The each loop iterates through all of the bands (set as the model for the controller) and creates a link for each of them, with the band (this) as the context for that route.

To decide about which band link is active (if any), it is necessary, but not sufficient, to just check if the band.details route is currently active or not.

Since the band.details route has a dynamic segment (see :slug in the route definition above) that is different for each band.details URL, the link-to is only going to be active if the current context (the band indicated in the URL) matches the context specified in the link-to (as this).

If the current URL is /band/3, only the link that has the band with id=3 as its context is going to be marked as active.

Taking Control with currentWhen

What we have seen so far is provided by Ember.js, and it just works. The default behavior described above, however, is not sufficiently flexible for all cases.

Let’s say we have a list of band links as before and we have two sub-pages. One to display the band details (band.details) and one to show their songs (band.songs). We want to show these two pages as tabs in the same content panel, so either the details or the songs are shown, but not both at the same time. Furthermore, we want the band link to load the details tab, but be highlighted as active, even if the user then clicks the songs tab.

The solution shown in the previous section would correctly highlight the band link when the details tab is active, but the highlight would be removed on the songs tab, since there would be no route match.

Ember.js offers a solution for this scenario in the form of the currentWhen parameter. If that parameter is used in the link-to call, Ember compares the currently active route names, not to the link-to’s route name argument, but to its currentWhen parameter. If there is a match based upon the rules described above, the link is considered active.

To satisfy the UI specification in the above example, the link-to would have to look like the following:

Because the band route is active, both for band.details and for band.songs, our links would be highlighted correctly.

“Just works” in Most Cases, Easy to Make it Work in Others

Adding markup for links that shows when they are active works “out-of-the-box” in 80% of the cases in Ember.js. For the remaining 20%, Ember.js provides a way that is easy to work with. This 80-20 rule is a hallmark of great frameworks and Ember.js is truly one.

Be sure to look at the Ember.js resources that you can find in Safari Books Online.

Not a subscriber? Sign up for a free trial.

Safari Books Online has the content you need

Developing an Ember.js Edge will take the reader from a casual interest in Ember.js through to building a complete application. Along the way we’ll cover the current state of client-side web development, the history and evolution of Ember, and the projects and challenges that have informed its design. Then we’ll dig deep into each of Ember’s constituent component libraries, demonstrating how each operates on its own and how they work together harmoniously as a framework.
Instant Ember.js Application Development How-to is a practical guide that provides you with clear step-by-step examples. The in-depth examples take into account the key concepts and give you a solid foundation to expand your knowledge and your skills. That will help you use the power of Ember.JS in your applications.
The Twitter Flight Edge walks through developing a simple sample application – an RSS reader – using Twitter Flight and supporting libraries. Everything from basic components like tabs to remote data fetching is covered, highlighting the benefits Flight offers for event-driven applications.

About the author

balinterdi Balint Erdi, an Ember.js consultant. The more he does Ember.js, the more he loves it. So much so that he even has a mailing list with a screencast series on how to build an Ember.js app step-by-step.

Tags: active links, currentWhen, Ember.js, link-to helper, Marking Links, routes, URL,

Comments are closed.