Services

Tuning

We love rock bands and we love to go to their concerts so it'd be great if we could check out if they have upcoming shows close to us. Also, we'll put up a user settings page so that users can see concert dates in the format they are most used to.

These are the main feature we'll implement in this chapter with another Ember.js building block, services. Services serve the purpose of storing state and implementing cross-cutting concerns that are not specific to any individual page or component. We have already been using a great number of them, like the store (from Ember Data), the router (from Ember proper) or the session (provided by Ember Simple Auth).

As usual, we'll modify our app in other ways to accommodate the new feature.

New styles

 /* app/styles/app.css */
 +.w-15 {
 +   width: 15%;
 +}
 +.striped--near-white:nth-child(even) > td {
 +   color: var(--near-white);
 +}
 +
 +.striped--near-white:nth-child(odd) > td {
+   color: var(--mid-grey);
+}
+
+.rr-link-button {
+   background-color: transparent;
+   color: var(--near-white);
+   border: 0;
+   border-bottom: 1px solid var(--near-white);
+   padding: 0;
+   cursor: pointer;
+}

Moving the editing of bands to a dedicated route

The first thing which is not strictly needed to implement the features but is nevertheless nice to have is assigning the editing of a band its own route. Currently, the band details page serves that purpose but it's a bit of a mix of displaying and editing band data so it'd make sense to have a dedicated edit page to clear things up.

Let's start by creating the route:

$ ember g route bands/band/edit

Instead of flipping between "show" and "edit" modes on the band's details page, we'll just link to the newly created edit page. The template thus becomes quite simple (not showing the diff because it'd be far more confusing):

 {{!-- app/templates/bands/band/details.hbs --}}
 <section class="rr-panel b--solid br1 bw1">
   <div class="flex w-100 justify-between">
     <h3>Description</h3>
     {{#link-to 'bands.band.edit' class="underline" data-test-rr="edit-band-link"}}Edit{{/link-to}}
   </div>
   <h3>Description</h3>
   <p class="lh-copy" data-test-rr="band-description">
     {{model.description}}
  </p>
  <h3>Members</h3>
  {{!-- (...) --}}
</section>

We can now turn our attention to the new page, bands.band.edit which is completely empty for the moment. We could try putting all the logic in the controller and the template but just as we ended up putting it in a musician-form component in the previous chapter, we can "proactively" do the same here, and use a band-form UI component, as it's a more convenient way to work with forms:

$ ember g component band-form

The form should allow editing the band's name and description, save or discard changes and display error messages as appropriate.

Here is the template in its entirety:

 {{!-- app/templates/components/band-form.hbs --}}
 <form onsubmit={{perform saveBand}}>
   <div class="rr-form-row mb3">
     {{#if showErrors.name}}
       <div class="rr-form-field-error" data-test-rr="name-error">{{v-get @band "name" "message"}}</div>
     {{/if}}
     <div class="mb2">
       <label for="name">Name</label>
     </div>
    <div class="mb2">
      {{input
        type="text"
        class="rr-input ml-auto w-100"
        data-test-rr="band-name-field"
        id="name"
        value=@band.name
        focus-out=(action (mut showErrors.name) true)
      }}
    </div>
  </div>
  <div class="rr-form-row mb3">
    {{#if showErrors.description}}
      <div class="rr-form-field-error" data-test-rr="description-error">{{v-get @band "description" "message"}}</div>
    {{/if}}
    <div class="mb2">
      <label for="name">Description</label>
    </div>
    <div class="mb2">
      {{textarea
        class="rr-textarea"
        data-test-rr="band-description-field"
        value=@band.description
        focus-out=(action (mut showErrors.description) true)
      }}
    </div>
  </div>
  <div class="rr-form-footer">
    <div class="rr-button-panel">
      <button
        type="button"
        class="rr-secondary-button mr3"
        data-test-rr="cancel-button"
        onclick={{perform discardChanges}}
      >
        Cancel
      </button>
      <button
        type="submit"
        class="rr-action-button"
        data-test-rr="update-button"
        disabled={{isButtonDisabled}}
      >
        Update
      </button>
    </div>
  </div>
</form>

We can see that in order to make this work, we'll need to

1. Pass in band to the component from the route template
2. Add a name validation to the band model
3. Set up showErrors and isButtonDisabled
4. Define the saveBand and discardChanges tasks

Let's go from top to bottom and invoke the component from the bands.band.edit template:

{{!-- app/templates/bands/band/edit.hbs --}}
-{{outlet}}
+<h3 data-test-rr="form-header">Edit {{model.name}}</h3>
+{{band-form band=model}}

That was a piece of cake as the model is already correctly set since it's inherited from the parent route, bands.band.

Next, the year-of-formation validator is already added to the Band model, we only need to add a presence validator for the name:

 // app/models/band.js
 // (...)
 const Validations = buildValidations({
 +  name: [
 +    validator('presence', {
 +      presence: true,
 +      ignoreBlank: true,
 +      message: "Name can't be empty"
 +    }),
+  ],
  description: [
    validator('length', {
      min: 12,
      message: "The description needs to be at least 12 characters"
    }),
    validator('year-of-formation')
  ]
});

We can now move on to setting up the showErrors object to indicate which errors (if present) need to be shown. We can do this in the contstructor of the component, the init method:

 // app/components/band-form.js
 export default Component.extend({
 +  tagName: '',
 +  band: null,
 +  saveBand: null,
 +  
 +  init() {
 +    this._super(...arguments);
 +    this.set('showErrors', {
+      name: false,
+      description: false
+    });
+  },
});

The isButtonDisabled follows the usual pattern of our form components: it's either disabled if some validations are failing or if the submit action is running:

// app/components/band-form.js
+import { or } from '@ember/object/computed';

export default Component.extend({
  // (...)
+  isButtonDisabled: or('band.validations.isInvalid', 'saveBand.isRunning'),
});

One of the advantages that using a component for a form gives us is that transient state (like whether to show error message or not) is aligned with the component's lifecycle. As components are destroyed when they are no longer rendered on the screen, state attributes die with them and so state doesn't need to be explicitly managed as it'd be the case if we defined it on the controller.

With these in place, when you delete the name of a band, you should see the validation error:

Let's move on to adding the save and cancel actions, which we'll implement as EC tasks:

 // app/components/band-form.js
 +import { inject as service } from '@ember/service';
 +import { task } from 'ember-concurrency';
 
 export default Component.extend({
 +  router: service(),
 +
   //  (...)
 +  saveBand: task(function* (event) {
+    event.preventDefault();
+    yield this.band.save();
+    yield this.router.transitionTo('bands.band.details', this.band.id);
+  }),
+
+  discardChanges: task(function* () {
+    this.band.rollbackAttributes();
+    yield this.router.transitionTo('bands.band.details', this.band.id);
+  }),
});

There is nothing new here and with these in place, our form is now complete and we can update a band's details on a separate page.

We also have some clean-up to do in the details route. As we're not editing anything here any more, the resetController hook and the willTransition action can be removed:

 // app/routes/bands/band/details.js
 export default Route.extend({
    // (...)
 -  resetController(controller) {
 -    controller.set('isEditing', false);
 -  },
 -
 -  actions: {
 -    willTransition(transition) {
-      let bandNotSaved = this.controller.model.hasDirtyAttributes;
-      if (bandNotSaved) {
-        let leave = window.confirm("You might lose your changes you've made to the band's details. Are you sure?");
-        if (!leave) {
-          transition.abort();
-        }
-      }
-    }
-  }
});

Showing concerts for a band

We can now start working on the main feature for this chapter, showing nearby concerts for the logged in user. We'll use a couple of services to achieve that and create one of our own.

First things first, let's again create a route for the new page, Concerts:

$ ember g route bands/band/concerts

Add the new page as a navigation tab in the bands.band template:

 {{!-- app/templates/bands/band.hbs --}}
  <nav class="rr-navbar" role="navigation">
    <ul class="rr-nav">
      <li class="rr-navbar-item" data-test-rr="details-nav-item">{{link-to "Details" "bands.band.details"}}</li>
      <li class="rr-navbar-item" data-test-rr="songs-nav-item">{{link-to "Songs" "bands.band.songs"}}</li>
 +     <li class="rr-navbar-item" data-test-rr="concerts-nav-item">{{link-to "Concerts" "bands.band.concerts"}}</li>
    </ul>
  </nav>
 {{outlet}}

The new page is empty and we have to fetch a list of concerts to fill it up.

The concert data is provided by Songkick (thank you, Songkick!), so we'll have to query their API. In order to do that, an artist ID needs to be known for each band. I made sure that this is supplied by the back-end, so all we have to do is to add this attribute to the band model:

 // app/models/band.js
 export default Model.extend(Validations, {
   name:         attr('string'),
   description:  attr('string'),
 +  songkickArtistId: attr(),
   songs:        hasMany(),
   members:      hasMany('musicians', { async: false }),
   // (...)
 });

The artist id allows us to compose the URL to query the Songkick API. So far, we have mostly used Ember Data's high-level store methods to send requests to external APIs (our own back-end) but in this case we don't need full-fledged ED records for the concerts with all the extras it provides (identity map, relationship management, easy creation/update, etc.), so we'll use a simple fetch and display the returned data.

Let's start by installing the ember-fetch add-on:

$ ember install ember-fetch

Let's now write the model hook that fetches the relevant concert data:

 // app/routes/bands/band/concerts.js
 import Route from '@ember/routing/route';
 +import fetch from 'fetch';
 +import { inject as service } from '@ember/service';
 +import ENV from 'rarwe/config/environment';
 
 export default Route.extend({
 +  session: service(),
 +
+  async model() {
+    let band = this.modelFor('bands.band');
+    let { token } = this.get('session.data.authenticated');
+    let concertsURL = `/bands/${band.id}/concerts`;
+    if (ENV.apiHost) {
+      concertsURL = `${ENV.apiHost}/${concertsURL}`;
+    }
+    let response = await fetch(concertsURL, {
+      headers: {
+        'Authorization': `Bearer ${token}`
+      }
+    });
+    return await response.json();
+  }
});

This is similar to how we sent a request manually in authenticators/credentials.js. We set the authorization token in the Authorization header and send the request on its way to the back-end URL which is available at /bands/:band-slug/concerts.

Next up is rendering those shows in the template. model contains the list of shows so the template can just cycle through them:

 {{!-- app/templates/bands/band/concerts.hbs --}}
 <h3>Concerts</h3>
 {{#if model.length}}
   <table class="collapse ba br2 pv2 ph3 w-100">
     <thead>
       <th class="pv2 ph3 tl f6 fw6 ttu">Date</th>
       <th class="tc f6 ttu fw6 pv2 ph3">City</th>
       <th class="tc f6 ttu fw6 pv2 ph3">Location</th>
       <th class="tc f6 ttu fw6 pv2 ph3">Event page</th>
    </thead>
    <tbody>
      {{#each model as |concert|}}
        <tr class="striped--near-white" data-test-rr="concert-row">
          <td class="pv2 ph3">{{concert.start.date}}</td>
          <td class="pv2 ph3">{{concert.location.city}}</td>
          <td class="pv2 ph3">{{concert.venue.displayName}}</td>
          <td class="pv2 ph3">
            <a href={{concert.uri}}>Visit {{fa-icon "external-link"}}</a>
          </td>
        </tr>
      {{/each}}
    </tbody>
  </table>
  <div class="mt2 flex items-end">
    <a class="ml-auto w-15" href="https://songkick.com">
      <img src="/images/book-chapters/powered-by-songkick-white.svg" alt="Powered by Songkick">
    </a>
  </div>
{{else}}
  <p class="tc">There are no upcoming concerts.</p>
{{/if}}

(If you build the app yourself locally, please download the "Powered by Songkick" logo from https://s3-eu-west-1.amazonaws.com/rarwe-book/powered-by-songkick-white.svg and place it in the app's public/images folder so that it's displayed correctly.)

At this point, you should see all the upcoming concerts listed for the band:

How to see concerts for my bands?

To see the concerts for a band, its songkickArtistId needs to be set to the correct value. The backend takes care of that for a handful of bands so if you're building the app along the book, pick one of them to see concert data. They are

• Pearl Jam
• Led Zeppelin
• Foo Fighters
• Radiohead
• Red Hot Chili Peppers
• Royal Blood
• Caspian
• Long Distance Calling
• Them Crooked Vultures
• Alice in Chains
• God is an Astronaut
• If These Trees Could Talk
• Moonlit Sailor
• Mogwai

If you'd like a band to be added, just let me know and I'll add it.

Showing nearby concerts (Stage 1)

So far so good, but we'd like to enable users to only see concerts that are close to them and so have a chance of attending.

In order to do that, we'll need to know where the user is, so we need to ask for her permission to retrieve her location. Fortunately, there is an add-on (also) for this that makes this process quite simple. It's called ember-cli-geo so let's install it:

$ ember install ember-cli-geo

The main entry point to using geolocation with the add-on is its geolocation service (you see, another service), on which we can call getLocation. That prompts the user to grant permission and returns their location if the permission is granted.

Let's wire this up now.

 {{!-- app/templates/bands/band/concerts.hbs --}}
 -<h3>Concerts</h3>
 +<div class="flex w-100 justify-between mb3">
 +   <h3 class="ma0">
 +     Concerts
 +   </h3>
 +   <button class="rr-link-button" onclick={{perform filterConcerts}}>
 +     Only show nearby
 +   </button>
+</div>
{{#if model.length}}
  (...)
{{/if}}

The important bit is the addition of the "Only show nearby" toggle which should call the filterConcerts task. That task, in turn, should ask for the user's location if it's not yet known and then filter the list down to nearby concerts.

That task has to live on the controller so it has to be created first:

$ ember g controller bands/band/concerts

We can then add the task:

 // app/controllers/bands/band/concerts.js
 import Controller from '@ember/controller';
 +import { inject as service } from '@ember/service';
 +import { readOnly } from '@ember/object/computed'; 
 +import { task } from 'ember-concurrency';
 
 export default Controller.extend({
 +  showConcerts: 'all',
 +
+  geolocation: service(),
+  userLocation: readOnly('geolocation.currentLocation'),
+
+  filterConcerts: task(function* () {
+    if (!this.userLocation) {
+      yield this.get('geolocation').getLocation();
+    }
+    this.set('showConcerts', 'nearby');
+  })
});

If the user's geolocation (stored in the currentLocation property of the service) is unknown, we query for it via the geolocation service and then switch the page to only show nearby concerts. showConcerts defines whether all or only nearby concerts should be displayed.

When the button is clicked, the browser asks the user if they want to allow the app to know their location.

That works but nothing changes on the page, as there's no difference between showing all and only nearby concerts on the page.

Let's code up a "quick and dirty" (or rather, "quick and incorrect") solution to switch between showing all and nearby concerts and later make it right.

Let's pretend that nearby concerts are all of the concerts except the last one:

 // app/controllers/bands/band/concerts.js
 +import { computed } from '@ember/object';
 
 export default Controller.extend({
   // (...)
 +  concerts: computed('showConcerts', 'model.[]', function() {
 +    if (this.showConcerts === 'all') {
 +      return this.model;
 +    }
+    return this.model.slice(0, -1);
+  }),
  // (...)
});

We should take care to switch to going through concerts (and not model) in the template:

 {{!-- app/templates/bands/band/concerts.hbs --}}
 {{!-- ... --}}
 -{{#if model.length}}
 +{{#if concerts.length}}
   {{!-- ... --}}
     <tbody>
 -      {{#each model as |concert|}}
 +      {{#each concerts as |concert|}}
         {{!-- ... --}}
      {{/each}}
    </tbody>
{{/if}}

Great, this part works now, but we should also show the correct label on the button and actually switch between showing all or only nearby concerts in the filterConcerts task. Let's make these changes.

 // app/controllers/bands/band/concerts.js
 -import { readOnly } from '@ember/object/computed';
 +import { readOnly, equal } from '@ember/object/computed';
 
 export default Controller.extend({
   // (...)
 +  showingAll: equal('showConcerts', 'all'),
 +  showingNearby: equal('showConcerts', 'nearby'),
 
-  concerts: computed('showConcerts', 'model.[]', function() {
+concerts: computed('showingAll', 'model.[]', function() {
-    if (this.showConcerts === 'all') {
+    if (this.showingAll) {
      return this.model;
    }
    return this.model.slice(0, -1);
  }),

  filterConcerts: task(function* () {
    if (!this.userLocation) {
      yield this.get('geolocation').getLocation();
    }
-    this.set('showConcerts', 'nearby');
+    this.set('showConcerts', this.showingAll ? 'nearby' : 'all');
  })
});

Now, for the changes in the template:

 {{!-- app/templates/bands/band/concerts.hbs --}}
 <div class="flex w-100 justify-between mb3">
   <h3 class="ma0">
 -   Concerts
 +   {{#if showingAll}}
 +     Concerts
 +   {{else}}
 +     Nearby concerts
 +   {{/if}}
  </h3>
  {{!-- (...) --}}
  <button class="rr-link-button" onclick={{perform filterConcerts}}>
-    Only show nearby
+    {{#if showingAll}}
+      Only show nearby
+    {{else}}
+      Show all
+    {{/if}}
  </button>
  {{!-- (...) --}}
</div>

As a nice UI touch, we should let the user know that we're getting their location as it can take a little bit of time during which the app gives no indication of what's happening. Piece of cake with EC tasks:

 {{!-- app/templates/bands/band/concerts.hbs --}}
   {{!-- (...) --}}
 -  <button class="rr-link-button" onclick={{perform filterConcerts}}>
 -    {{#if showingAll}}
 -      Only show nearby
 -    {{else}}
 -      Show all
 -    {{/if}}
 -  </button>
+{{#if filterConcerts.isRunning}}
+   <div>Getting location...</div>
+{{else}}
+   <button class="rr-link-button" onclick={{perform filterConcerts}}>
+     {{#if showingAll}}
+       Only show nearby
+     {{else}}
+       Show all
+     {{/if}}
+   </button>
+{{/if}}
  {{!-- (...) --}}

And we're done with the fake solution, we can now start implementing the real thing.

Showing nearby concerts (Stage 2)

As the next step, we'd like to calculate the distance between each concert and the user's location and, when showing nearby concerts, filter the list of concerts down to those which are closer than a given, fixed distance.

In order to not write code for calculating geographical distances, we'll use the geolib npm package. To be able to use a npm package just like that, we'll need to add the ember-auto-import add-on, so let's install that one first:

$ ember install ember-auto-import

We can now install the geolib package:

$ npm install --save-dev geolib

(or yarn add --dev geolib)

Armed with geo-distance calculating abilities, we can now modify the concerts CP to only return nearby concerts:

 // app/controllers/bands/band/concerts.js
 +import geolib from 'geolib';
 
 +const nearbyDistance = 500 * 1000; // 500km
 
 export default Controller.extend({
   // (...)
 -  concerts: computed('showingAll', 'model.[]', function() {
 +  concerts: computed('showingAll', 'model.[]', 'userLocation', function() {
    if (this.showingAll) {
      return this.model;
    }
-    return this.model.slice(0, -1);
+    let [userLat, userLng] = this.userLocation;
+    return this.model.filter((concert) => {
+      let { lat, lng } = concert.location;
+      let distanceToConcert = geolib.getDistance(
+        { lat: userLat, lng: userLng },
+        { lat, lng }
+      );
+      return distanceToConcert < nearbyDistance;
+    });
  }),
  // (...)
});

For each concert, location.lat and location.lng contains the coordinates, while userLocation stores these in an array. The actual calculation is done by geolib.getDistance, which returns the result in meters.

Living in Central Europe, I needed to switch to "Long Distance Calling" (an excellent German hard rock band) to verify that getting nearby concerts works – and it does:

Before we move on to another feature, let's allow the user to set how far they are willing to travel for a concert – the radius within which concerts are considered nearby.

In "nearby concerts" mode, instead of a fixed distance, we'll have a dropdown with a couple of options. When the user picks one of them, the list should refresh with the concerts that are that close or closer.

Let's make the changes in the controller first:

 // app/controllers/bands/band/concerts.js
 -const nearbyDistance = 500 * 1000; // 500km
 
 export default Controller.extend({
    // (...)
 +  selectedDistance: 500,
 +
 +  init() {
 +    this._super(...arguments);
+    this.set('nearbyDistances', [200, 500, 1000, 2000]);
+  },
-  concerts: computed('showingAll', 'model.[]', 'userLocation', function() {
+  concerts: computed('showingAll', 'model.[]', 'userLocation', 'selectedDistance', function() {
    // (...)
    return this.model.filter((concert) => {
      let { lat, lng } = concert.location;
      let distanceToConcert = geolib.getDistance(
        { lat: userLat, lng: userLng },
        { lat, lng }
      );
-      return distanceToConcert < nearbyDistance;
+     return distanceToConcert < (this.selectedDistance * 1000);
    });
  },
}),
});

That wasn't too bad. The template needs to change to accommodate the distance selector and also to make sure it's only shown when nearby concerts are shown.

 {{!-- app/templates/bands/band/concerts.hbs --}}
 -<div class="flex w-100 justify-between mb3">
 +<div class="flex w-100 justify-start mb3"
   {{!-- (...) --}}
   {{#if filterConcerts.isRunning}}
 -    <div>Getting location...</div>
 +    <div class="ml-auto">Getting location...</div>
   {{else}}
 -   <button class="rr-link-button" onclick={{perform filterConcerts}}>
-     {{#if showingAll}}
-       Only show nearby
-     {{else}}
-       Show all
-     {{/if}}
-   </button>
+   <div class="ml-auto flex items-center">
+     {{#if showingNearby}}
+       within
+       <div class="ml2 w4">
+          {{#power-select
+            class="ml2"
+            options=nearbyDistances
+            selected=selectedDistance
+            placeholder="..."
+            searchEnabled=false
+            data-test-rr="distance-selector"
+            onchange=(action (mut selectedDistance))
+          as |distance|}}
+            {{distance}}
+          {{/power-select}}
+       </div>
+       <span class="ml2 mr2">
+         kms or
+       </span>
+     {{/if}}
+     <button class="rr-link-button" onclick={{perform filterConcerts}}>
+       {{#if showingAll}}
+         Show nearby
+       {{else}}
+         Show all
+       {{/if}}
+     </button>
+   </div>
</div>

That's quite a bit so let me elaborate. The new UI item is the nearby distance selector which should only be there when nearby concerts are selected (if showingNearby is true). Then we have the selector itself whose options are provided by nearbyDistances (the property we've just defined in the controller) and the selected one is selectedDistances (500 by default). So that they are nicely aligned, they are wrapped in a flex container, hence the new div on line 16.

With these changes, users who are willing to travel further can set a bigger distance.

Turns out I have a lot more options for a Long Distance Calling concert withing 1000 kilometers:

Adding user settings

To start, let's sketch out the feature we're going to build.

1. We'd like to have a user settings page where two options can be set. The unit preference (metric or imperial) and the preferred date format.
2. We'll then extract the fetching of the current user into its service so that it can easily be accessed from anywhere.
3. The concerts page should then take into account whether the user prefers distances in kilometers or miles.
4. The concerts page should then show dates according to user preference.

That's the list we'll go down on, so let's start with the first item, adding the user settings page.

First, two properties needs to be added to the user model that store the above preferences:

// app/models/user.js
export default Model.extend(Validations, {
  email: attr('string'),
  password: attr('string'),
+  unitPreference: attr(),
+  dateFormat: attr(),
});

Next, the new page needs to be created:

$ ember g route settings

Let's link to that page from the email address of the logged in user, in the top navbar:

 {{!-- app/templates/application.hbs --}}
 <div class="rr-container">
   {{!-- ... --}}
     {{#if session.isAuthenticated}}
       <div class="rr-user-panel">
 -        <span data-test-rr="user-email">
 -          {{session.data.authenticated.userEmail}}
 -        </span>
 +        {{#link-to "settings"}}
+          <span data-test-rr="user-email">
+            {{session.data.authenticated.userEmail}}
+          </span>
+        {{/link-to}}
        |
        <span>{{link-to 'Logout' 'logout' data-test-rr="logout"}}</span>
      </div>
    {{/if}}
</div>

If we click on the email address, the resulting page comes up empty, so our next step should be fetching the current user and allowing the user preferences to be set on the page.

The current user can be fetched from the /users/me endpoint on the backend, so we'll again drop down a level from Ember Data's store abstractions and write out the request and pushing the returned user to the store ourselves. Let's see how.

 // app/routes/settings.js
 import Route from '@ember/routing/route';
 +import { inject as service } from '@ember/service';
 +import fetch from 'fetch';
 
 export default Route.extend({
 +  session: service(),
 +
 +  async model() {
+    let { token } = this.session.data.authenticated;
+    let currentUserURL = '/users/me';
+    if (ENV.apiHost) {
+      currentUserURL = `${ENV.apiHost}/${currentUserURL}`;
+    }
+    let response = await fetch(currentUserURL, {
+      headers: {
+        "Authorization": `Bearer ${token}`
+      }
+    });
+    let payload = await response.json();
+    let store = this.store;
+    let User = store.modelFor('user');
+    let serializer = store.serializerFor('user');
+
+    let jsonApiPayload = serializer.normalizeResponse(store, User, payload, null, 'query');
+    return this.store.push(jsonApiPayload);
+  }
});

The fetch needs no further explanation (we saw it when we fetched the list of concerts) but handling the returned payload does. The payload needs to be serialized to conform to ED's internal format and that's what the last four lines do (pushPayload did something similar but it is now deprecated).

At the end of this, we have pushed the logged in user record to the store and have set it as the model of the controller. We can now implement the UI functionality.

Just as before, we'll already create a form for the user, so let's get this out of the way:

$ ember g component user-form

Having done that, the settings template can be kept dead simple:

{{!-- app/templates/settings.hbs --}}
<div class="rr-form-container-wider">
  <h3 data-test-rr="form-header">User settings</h3>
  {{user-form user=model}}
</div>

The component JS file and the related template doesn't contain anything we hadn't seen so I'm just going to copy them here in their entirety:

 // app/components/user-form.js
 import Component from '@ember/component';
 import { inject as service } from '@ember/service';
 import { task } from 'ember-concurrency';
 
 export default Component.extend({
   router: service(),
 
   init() {
    this._super(...arguments);
    let dateFormats = [
      { value: 'YYYY-MM-DD', example: '2018-07-31' },
      { value: 'DD-MM-YYYY', example: '31-07-2018' },
      { value: 'MM-DD-YYYY', example: '07-31-2018' },
    ];
    this.set('dateFormats', dateFormats);
    this.set('units', ['metric', 'imperial']);
    let usersDateFormat = dateFormats.find((format) => {
      return format.value === this.user.dateFormat;
    });
    this.set('selectedFormat', usersDateFormat);
  },

  saveUser: task(function* (event) {
    event.preventDefault();
    yield this.user.save();
    yield this.router.transitionTo('index');
  }),

  discardChanges: task(function* () {
    this.user.rollbackAttributes();
    yield this.router.transitionTo('index');
  }),

  actions: {
    updateSelectedFormat(format) {
      this.set('selectedFormat', format);
      this.user.set('dateFormat', format.value);
    }
  }
});

Updating the preferred date format is a tad more complicated because the options are POJOs (Plain Old Javascript Objects) as we need both the value to save (for example, 'YYYY-MM-DD') and an example to show to the user (2018-07-31).

Here is the template:

 {{!-- app/templates/components/user-form.hbs --}}
 <form onsubmit={{perform saveUser}}>
   <div class="rr-form-row mb3">
     <div class="mb2">
       <label for="date-format">Preferred date format</label>
     </div>
     <div class="mb2">
       {{#power-select
         options=dateFormats
        selected=selectedFormat
        searchEnabled=false
        data-test-rr="date-format-selector"
        onchange=(action "updateSelectedFormat")
      as |format|}}
        {{format.example}}
      {{/power-select}}
    </div>
  </div>
  <div class="rr-form-row">
    <div class="mb2">
      <label for="units">Units</label>
    </div>
    <div class="mb2">
      {{#power-select
        options=units
        selected=@user.unitPreference
        searchEnabled=false
        data-test-rr="unit-selector"
        onchange=(action (mut @user.unitPreference))
      as |unit|}}
        {{capitalize unit}}
      {{/power-select}}
    </div>
  </div>
  <div class="rr-form-footer">
    <div class="rr-button-panel">
      <button
        type="button"
        class="rr-secondary-button mr3"
        data-test-rr="cancel-button"
        onclick={{perform discardChanges}}
      >
        Cancel
      </button>
      <button
        type="submit"
        class="rr-action-button"
        data-test-rr="save-button"
      >
        Save
      </button>
  </div>
</form>

The finished settings page should look something like this:

Before we forget, let's protect the settings page so that it cannot be accessed by unauthorized users:

// app/routes/settings.js
+import AuthenticatedRouteMixin from 'ember-simple-auth/mixins/authenticated-route-mixin';

-export default Route.extend({
+export default Route.extend(AuthenticatedRouteMixin, {
  // (...)
});

Defining a current-user service

Since we'll want to get hold of the current user from different parts of the application (for example, the concerts page to see how dates should be displayed), it would make sense to extract the management of the current user into a service. The service would load (and unload) the current user and also give access to its properties. Let's start by creating the service itself:

$ ember g service current-user

Its load method would fetch the current user from the back-end, while unload would unset it. We've already implemented the mechanics in the settings route, it just needs to be moved:

 // app/services/current-user.js
 import Service from '@ember/service';
 +import { inject as service } from '@ember/service';
 +import fetch from 'fetch';
 
 export default Service.extend({
 +  user: null,
 +
 +  session: service(),
+  store: service(),
+
+  async load() {
+    if (!this.session.isAuthenticated) {
+      return;
+    }
+    let { token } = this.session.data.authenticated;
+    let currentUserURL = '/users/me';
+    if (ENV.apiHost) {
+      currentUserURL = `${ENV.apiHost}/${currentUserURL}`;
+    }
+    let response = await fetch(currentUserURL, {
+      headers: {
+        "Authorization": `Bearer ${token}`
+      }
+    });
+    let payload = await response.json();
+    let store = this.store;
+    let User = store.modelFor('user');
+    let serializer = store.serializerFor('user');
+
+    let jsonApiPayload = serializer.normalizeResponse(store, User, payload, null, 'query');
+    let user = this.store.push(jsonApiPayload);
+    this.set('user', user);
+  },
+
+  unload() {
+    this.set('user', null);
+  }
});

The only difference is that instead of returning the pushed user record, the service sets it as its user property.

The settings route can now be trimmed down to load the current user and then return it:

 // app/routes/settings.js
 -import fetch from 'fetch';
 
 export default Route.extend(AuthenticatedRouteMixin, {
 -  session: service(),
 +  currentUser: service(),
 
   async model() {
 -    let { token } = this.session.data.authenticated;
-    let currentUserURL = '/users/me';
-    if (ENV.apiHost) {
-      currentUserURL = `${ENV.apiHost}/${currentUserURL}`;
-    }
-    let response = await fetch(currentUserURL, {
-      headers: {
-        "Authorization": `Bearer ${token}`
-      }
-    });
-    let payload = await response.json();
-    let store = this.store;
-    let User = store.modelFor('user');
-    let serializer = store.serializerFor('user');
-
-    let jsonApiPayload = serializer.normalizeResponse(store, User, payload, null, 'query');
-    return this.store.push(jsonApiPayload);
+    await this.currentUser.load();
+    return this.currentUser.user;
  }
);

So far so good, when we reload the settings page, it keeps working as before.

However, if we count on using the current user via the service from the Concerts page, too (and later, from other pages), we have to make sure that we call the load method on the service whenever the session changes its state.

This happens when a user logs in, logs out and when a session is restored (from a stored token). Let's cover the first two cases first.

Ember Simple Auth provides callbacks on the session service whenever authentication succeeds or when the session is invalidated. These are respectively the authenticationSucceeded and invalidationSucceeded events.

The best place to react to these events is an instance initializer, so let's set one up.

$ ember g instance-initializer current-user

 -export function initialize(/* appInstance */) {
 +export function initialize(appInstance) {
 +  let session = appInstance.lookup('service:session');
 +  let currentUser = appInstance.lookup('service:current-user');
 +  session.on('authenticationSucceeded', function() {
 +    currentUser.load();
 +  });
 +  session.on('invalidationSucceeded', function() {
 +    currentUser.unload();
+  });
}

export default {
  initialize
};

Unfortunately, that doesn't cover the third case, restoring a previous session as authenticationSucceeded is not called in that scenario. If only there was a hook that always gets called upon booting up the app...

The beforeModel hook of the application route is such a place. No matter which route is initially transitioned to, the application route is always on the active route path, so its hooks get run.

We haven't needed to put extra logic on the application route yet, so we first have to create it:

$ ember g route application

(we should say a definite "no" to whether our application template should be overridden.)

Ok, we can now add the short code snippet to load the current user:

 // app/routes/application.js
 import Route from '@ember/routing/route';
 +import { inject as service } from '@ember/service';
 
 export default Route.extend({
 +  currentUser: service(),
 
 +  beforeModel() {
 +    return this.currentUser.load();
+  }
});

All our bases are now covered, the current user will always be correct in the service. That also means we can delete its explicit loading in the settings route and focus on customizing the concerts page according to user prerence.

 // app/routes/settings.js
 export default Route.extend(AuthenticatedRouteMixin, {
   currentUser: service(),
 
   async model() {
 -    await this.currentUser.load();
     return this.currentUser.user;
   }
 });

Customizing the concerts page

The two customizations we want to make on the Concerts page is choosing the preferred unit of distance (kms or miles) and the date format to use for concert dates. We need the current-user service for both of these.

Let's first open the controller since calculating distances happens there, and add a little bit of code:

 // app/controllers/bands/band/concerts.js
 +const milesToKilometers = 1.61;
 
 export default Controller.extend({
   // (...)
 +  currentUser: service(),
 +  useMiles: readOnly('currentUser.user.prefersImperial'),
 
 -  concerts: computed('showingAll', 'model.[]', 'userLocation', 'selectedDistance', function() {
+  concerts: computed('showingAll', 'model.[]', 'userLocation', 'maxDistance', function() {
    // (...)
    return this.model.filter((concert) => {
      let { lat, lng } = concert.location;
      let distanceToConcert = geolib.getDistance(
        { lat: userLat, lng: userLng },
        { lat, lng }
      );
-     return distanceToConcert < (this.selectedDistance * 1000);
+     return distanceToConcert < this.maxDistance;
  }),

+  maxDistance: computed('selectedDistance', 'useMiles', function() {
+    return this.selectedDistance * 1000 * (this.useMiles ? milesToKilometers : 1);
+  }),
});

To keep it simple, we treat the set of distances in the dropdown as miles if the user prefers it. Consequently, our (mostly American, I assume) users will see concerts in a somewhat (1.6x) bigger radius from their location, but that's okay here.

We access a prefersImperial property on the User model above, but we haven't yet defined it:

// app/models/user.js
+import { equal, not } from '@ember/object/computed';

export default Model.extend(Validations, {
  // (...)
+  prefersImperial: equal('unitPreference', 'imperial'),
+  prefersMetric: not('prefersImperial'),
});

Our work in the rendering context done, we can now pull up the template to make the tiny change of showing the right distance unit:

 {{!-- app/templates/bands/band/concerts.hbs --}}
 <div class="flex w-100 justify-start mb3">
   {{!-- (...) --}}
   {{#if filterConcerts.isRunning}}
     <div class="ml-auto">Getting location...</div>
   {{else}}
     <div class="ml-auto flex items-center">
       {{#if showingNearby}}
         {{!-- (...) --}}
        <span class="ml2 mr2">
-          kms or
+          {{if useMiles "miles" "kms"}} or
        </span>
      {{/if}}
  {{!-- (...) --}}
</div>

And that's it, the user's preferred unit of distance gets used (and displayed):

Regarding displaying concert dates, we'll use ember-moment to do the heavy lifting for us, so let's install the add-on:

$ ember install ember-moment

ember-moment provides a helper called moment-format that displays a date in the given format, which we can use in our template:

 {{!-- app/templates/bands/band/concerts.hbs --}}
 {{!-- (...) --}}
 {{#if concerts.length}}
   <table class="collapse ba br2 pv2 ph3 w-100">
     {{!-- (...) --}}
     <tbody>
       {{#each concerts as |concert|}}
         <tr class="striped--near-white" data-test-rr="concert-row">
           <td class="pv2 ph3">
-            {{concert.start.date}}
+            {{#let concert.start.date currentUser.user.dateFormat as |date format|}}
+              {{#if format}}
+                {{moment-format date format}}
+              {{else}}
+                {{moment-format date}}
+              {{/if}}
+            {{/let}}
          </td>
  {{!-- (...) --}}
{{/if}}

let is a great built-in helper that defines variables for its block. The first argument becomes the first argument yielded to the block, the second argument becomes the second, and so on. In our case, the date variable inside the block is concert.start.date, while format is equal to currentUser.user.dateFormat.

moment-format checks the number of arguments so we can't just use {{moment-format date format}} in case the user hasn't yet set a preferred format and rely on having a missing argument treated the same way as a falsy one. That's why explicitly checking if format is set is needed.

In the default case, when moment-format is only called with one argument, it outputs dates in a default format, which must be set explicitly in the configuration, so let's add it:

 // config/environment.js
 module.exports = function(environment) {
   let ENV = {
     modulePrefix: 'rarwe',
     // (...)
 +    moment: {
 +      outputFormat: 'YYYY-MM-DD'
 +    }
 };

Concert dates are now displayed according to user preference (and fall back to "YYYY-MM-DD" when it's unknown):

Summary

We've come a long way in this chapter so let's do a quick summary. We started by extracting the band's form onto its own page. Then we created a new page to show upcoming concerts for bands, connecting to an external API, Songkick, to retrieve data. We made it possible for users to constrain the list of concerts to those close to them by getting their location and allowing them to choose what "close" means.

We have then introduced the concept of the current user and implemented it in the current-user service. The new settings page leveraged this service and allowed setting user preferences about how distances and dates should be displayed. Finally, we've used these user preferences on the Concerts page.

The roadie says

There are a few files lying around that serve no purpose. The controller belonging to the bands.band.details route and the bands.band.edit route:

$ rm app/controllers/bands/band/details.js
$ rm app/routes/bands/band/edit.js

Next song

In this chapter we've added valuable features – our app now sings and dances (at least I'm sure about the singing part). However, it doesn't degrade very well. If network connection is missing, for example, it doesn't even load. And if we don't want to build a native app for all mobile operating systems (and we don't), we should bring it closer to the native mobile app feel.

It's turning our app to a progressive web app we're after.

Related hits

• ember-cli-geo
• ember-auto-import
• That's so fetch by Jake Archibald
• Ember RFC for deprecating store.pushPayload