Category Archives: Ember.js

Example of ember-form-for and mirage server side validation

At the time of writing, ember-form-for is the top Ember.js plugin for forms on Ember Observer. It provides a straightforward way to display form fields without having to write all the boilerplate HTML code around it.

What you do is you take:



    <label>First name: {{input value=model.firstname}}</label>
    {{#each model.errors.firstname as |error|}}
      <span class="errors">{{error.message}}</span>
    {{/each}}
  

and replace it with form-for-model helper:

{{#form-for model as |f|}}
  {{f.text-field "firstname"}}

  .. // other fields and submit button
{{/form-for}}

It will generate HTML code for you, as well as display validation errors.

Complete form becomes much more readable this way:

{{#form-for model as |f|}}
  {{f.text-field "firstname"}}
  {{f.text-field "lastname"}}

  {{f.select-field "gender" "unknown male female"}}
  {{f.checkbox-field "terms" label="I agree to the Terms of Service"}}

  {{f.submit "Submit"}}
{{/form-for}}

I’ve created a dedicated Github branch ember-form-for, that you can experiment with:
https://github.com/ember-examples/server-side-validation-mirage/tree/ember-form-for

Ember Server Side Form validation with Django

In previous post (Ember Server Side Form validation with Mirage), I’ve looked at just the Ember.js side. In this article, I’ll connect it with Django so that we have an actual backend that’s returning our errors. It builds on top of previous Ember.js code. There are also full Github repositories at the end.

Lets start with Django. We’ll be using Django Rest Framework to generate server side Django.

We have a basic models.py:

from __future__ import unicode_literals
from django.db import models

class Registration(models.Model):
    GENDER_CHOICES = (
        ('male', 'Male'),
        ('female', 'Female'),
        ('unspecified', 'Unspecified')
    )

    firstname = models.CharField(max_length=100)
    lastname = models.CharField(max_length=100)
    submitted = models.DateTimeField(auto_now_add=True)

and an API in views.py:

from rest_framework import viewsets
from rest_framework.response import Response
from rest_framework import status

from .models import Registration
from .serializers import RegistrationSerializer

class RegistrationViewSet(viewsets.ViewSet):
    def create(self, request):
        serializer = RegistrationSerializer(data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

One thing to note – we return 400 Error code, instead of 422 that we mocked with Mirage. That is because Ember Django Adapter wraps 400 error to make it compatible with JSON API specification.

All of our business logic of API validation happens in serializers.py:

from rest_framework import serializers

from . models import Registration

class RegistrationSerializer(serializers.ModelSerializer):
    class Meta:
        model = Registration
        fields = ('id', 'firstname', 'lastname')
   
    def validate_firstname(self, value):
    	if 'john' not in value.lower():
    		raise serializers.ValidationError('First name must be John')
    	return value

    def validate_lastname(self, value):

    	if 'smith' in value.lower():
    		raise serializers.ValidationError("Last name can't be Smith")
    	return value

    def validate(self, data):
    	if data['firstname'] == 'John' and data['lastname'] == 'Doe':
    		raise serializers.ValidationError("Please enter a more original name")

With server side in place, we can extend the previous example Ember.js app. We’ll be using Ember Django Adapter to make things easier.

First of, we need to turn of ember-cli-mirage in config/environment.js. We also set the development URL and API namespace at the same time.

  if (environment === 'development') {
    ENV.APP.API_HOST = 'http://localhost:8000';
    ENV.APP.API_NAMESPACE = 'api';

    ENV['ember-cli-mirage'] = {
      enabled: false
    };
  }

Another source of problems is that DS.RESTAdapter pluralises api endpoints. So instead of /api/registration/ it posts to /api/registrations/. To make it stop doing that we can define ‘registration’ as uncountable:
(ember generate drf-adapter application)

import DRFAdapter from './drf';
import Inflector from 'ember-inflector';

const inflector = Inflector.inflector;
inflector.uncountable('registration');

export default DRFAdapter.extend({});

Controller is still the same:

import Ember from 'ember';

export default Ember.Controller.extend({
  actions: {
    save() {
      var model = this.get('model');

      model.save().then((registration) => {
        // it's a mock, we don't do anything
      }).catch((adapterError) => {
        // we just need to catch error
      });
    }
  }
});

The main improvement is that template error handling now also displays non-field errors (via model.errors.base):

{{#each model.errors.base as |error|}}
  <span class="errors">{{error.message}}</span>
{{/each}}

<form>
  <p>
    <label>First name: {{input value=model.firstname}}</label>
    {{#each model.errors.firstname as |error|}}
      <span class="errors">{{error.message}}</span>
    {{/each}}
  </p>
  <p>
    <label>Last name:
      {{input value=model.lastname}}
    </label>
    {{#each model.errors.lastname as |error|}}
      <span class="errors">{{error.message}}</span>
    {{/each}}
  </p>
  <button {{action 'save'}}>Save</button>
</form>

With this in place, form validation errors now work correctly. If server side form validation passes, it also writes data into Data Store.

Ember.js code is in ‘django-api’ branch at https://github.com/ember-examples/server-side-validation-mirage/tree/django-api
Django code is at https://github.com/ember-examples/django-drf-serializer-validations

Ember Server Side Form validation with Mirage

In this Ember.js example, I’ll show how to get ember-cli-mirage to return correct JSON-API response, so that Ember Data correctly processes Error message and makes it accessible inside the template.

This code was tested on Ember 2.6.0.

We have the following registration model:

import Model from 'ember-data/model';
import attr from 'ember-data/attr';

export default Model.extend({
  firstname: attr('string'),
  lastname: attr('string'),
});

There are three main elements that make this work: Controller that saves the data, Template that renders form and errors, and Mirage that mocks the response.

Controller’s save action is very basic, it calls save on the model and catches any errors:

import Ember from 'ember';

export default Ember.Controller.extend({
  actions: {
    save() {
      this.get('model').save().then((registration) => {
        // it's a mock, we don't do anything
      }).catch((adapterError) => {
        // we just need to catch error
      });
    }
  }
});

Template displays form and any connected errors:

<form>
  <p>
    <label>First name: {{input value=model.firstname}}</label>
    {{#each model.errors.firstname as |error|}}
      <span class="errors">{{error.message}}</span>
    {{/each}}
  </p>
  <p>
    <label>Last name:
      {{input value=model.lastname}}
    </label>
    {{#each model.errors.lastname as |error|}}
      <span class="errors">{{error.message}}</span>
    {{/each}}
  </p>
  <button {{action 'save'}}>Save</button>
</form>

Now we only need to setup Ember Mirage. We emulate two different states. If firstname is ‘John’, we let request come through, and in all other cases we display error.

import Response from 'ember-cli-mirage/response';

export default function() {

  this.namespace = '/api';

  this.post('registrations', function(schema, request) {
   let attrs = JSON.parse(request.requestBody).data.attributes;

   if ( attrs.firstname === 'John') {
     return {
       'id': 1,
       'firstname': 'John',
       'lastname': attrs.lastname
     }
   } else {
     return new Response(422, {}, {
        "errors": [
          {
            "source": { "pointer": "/data/attributes/firstname"},
            "detail": "Please enter John as name"
          }
        ]}
     );
   }
  });
}

In the above example, it’s important that we return error code 422 (Unprocessable Entity), otherwise it will not be processed by JSONAPIAdapter as error.

Example repository

To make easier to see a complete and working example, I’ve also published a repository with complete code:
https://github.com/ember-examples/server-side-validation-mirage

What I learned building Open Education Week with Ember.js

I am lucky that at the Open Education Consortium, I can work with technology of my choosing. For Open Education Week site, I decided to experiment with Ember.js. It was my first production Ember app and I learned some valuable lessons.

Project background

Open Education Week site enables educators to submit their events and resources.  Visitors can then browse them. I used WordPress in previous years, and it worked fine to a point. It didn’t feel right when l I wanted to create more complex browsing interfaces.

Example of that would be: Show me all resources for colleges, that are in Spanish and have the following keywords in it. WordPress can do it, but it requires a lot of different taxonomies and custom queries.

I decided to build a thin Django API layer on top of existing data.

I tried using WP REST API, but it was hard to adopt. If I wanted to do more complex lookups, I still had to write complex WP_Query lookups. So that still wouldn’t help me on server side.

Good things about developing the site with Ember.js

Tooling is great

OEW is an Ember 2.3 application, written with ember-cli. This meant that I didn’t have to fight with grunt/gulp/etc. to get it to work. It just feels right, and it gives you things like real time reloading of CSS.

Components make things easy

It’s easy to make new components in Ember, that almost behave as Web Components. One example of that is my custom OEmbed component. I could reuse both in grid view and inside interactive map popup. (Demo)

Site feels fast

Once the page loads, the only requests you have to make are to the API. My other WordPress sites load fast, but requre refresh for every click. Single page app is fast.

Community

Community of people that hang out on Slack and IRC is incredible and helpful. I just wished that it would also extend to discussion forums. Real time nature of Slack and IRC just don’t make it easy to Google previous discussions on the same topic.

Not so good things

Site is slower to load

Current size is 400kb of gzipped JavaScript assets. Until it loads, you only get a blank screen. I didn’t find how to make it display some sort of initial loading indicator.

My final Javascript size is about 2x the size of vanilla Ember.js with Ember data. It would be good to have tools that would tell me which addon is taking the rest of the space.

Redirects and prerender.io

People rename website URLs all the time. This means that my API, has to keep history of all slug renames. The problem is then – how to communicate it to Google? Google parses JS apps, but doesn’t follow redirects.

I’m currently running preprender.io to solve some of these problems. It works, but it requires extra work via meta headers.

Outdated recipes

As far as I understand, ember-data assumes that I will want to query objects by their ID. If I want to retrieve them by slug, I have to make a query and then return first item of matching results. This works, but it means that records don’t get retrieved from cache.

That is just one approach, but others did’t seem much better. When I Googled: “Ember.js query by slug”, I got a lot of different threads and discussions with varying approaches. The problem is that a lot of them are from 2013. How do I know if this is still the right approach in 2016?

It’s still early in addon ecosystem

When `ember install [addon-name]` just works, it feels magical. The problem I had is that a lot addons at this point assume good knowledge of Ember. I wish they would bundle demo applications and have more documentation. It reminds me a lot about Django’s ecosystem about 6 years ago. Then we got Read the docs and more mature plugins and things go a lot easier.

Is this site ambitious enough?

Ember’s tagline is: “A framework for creating ambitious web applications”.  The ambitious part is often quoted, when people want to use Ember.js only in part. It’s rarely explained what ambitious means.

Conclusion

Fastboot will fix most of my problems, but it’s still a few months away. The rest of my problems should go away as the community grows.

Would I build this site again with Ember.js? I think I would, because it gives me a much better foundation than a WordPress theme.

How to approach learning new Framework and not get overwhelmed

It’s that time of year where everything old is new again. JavaScript is the hottest kid on the block and it is time to update my approach to writing complex Web Applications. Django and WordPress are fine, but they are safe choices that do most of the computation on the server. What I want to learn is, if it’s easier to make Single Page Applications.

After I realized last year that Angular 1, does not work for me – I decided to give Ember.js a try. Their web site resonated with me. It tells a story of community driven framework. It felt like Django, but with JavaScript. It’s also a huge framework that felt overwhelming the first I tried to follow their official tutorial. It also does not help that they are in a middle big transition to a major 2.x release.

After not making much progress in first two days, I have decided to change my approach. I opted for a complete submersion into Ember.js community.

There are several steps and mistakes I made along the way:

  • First mistake was trying to build a new app, while learning fundamentals. Too many new things and wrong assumptions on my part.
  • I stopped reading about fundamentals from tutorials on blogs. They’re just too short for someone without prior experience to understand what’s going on.
  • I bought a book – (Ember Cli 101) and forced myself to do all the examples in book. By typing them out – no copy/pasting. As Kathy Sierra tells us, we learn best when we write good examples of code.
  • Writing the code (and making mistakes) helped me learn ecosystem. It’s also a good practice in how to use build-in debugging tools, what do coding errors look like and how to fix them.
  • I started listening to podcasts with Core Team members. They provide a general overview of ideas that are usually skipped at technical talks.
  • I started listening to talks given at different (Ember) conferences in the last year. It helped me understand the terminology and the technical challenges that community is facing. They’re also great source of inspiration for the kind of apps, that people are building.
  • I started lurking on official IRC channel. It turns out, that if you read Q/A that goes in there, you’ll learn answers for problems you don’t have yet. That way it’s easier to identify later.
  • I’ve started to follow the discussion forums. It’s a good way to see longer discussions on common topics.
  • I’m starting to read different bug reports and RFC’s in Github.

All these activities are happening in parallel. After a week, I now know how to read the documentation and how to solve issues. I also understand what to watch out for and rough roadmap for the framework. I have yet to write my first app from scratch, but now I have example app that I can borrow code from.

To make it easier for other developers that are coming to Ember.js ecosystem, I’ve started documenting my journey as I Learn Ember.js.

So that was first 30 hours of deliberate practice with Ember.js. Several hundred to go.