Phil Gengler

Introducing ember-property-computed

Today I released ember-property-computed, a small ember-cli addon to allow specifying computed properties by giving the function first and then the dependent keys.

Basically, in Ember there are two ways of specifying computed properties:

aliasPropertyName: function() {
  // do something
}.property('dependentKey')

and

aliasPropertyName: Ember.computed('dependentKey', function() {
 // do something
}

Notice that the two styles have the ordering of the two parts (the function and the list of dependent keys) switched; with .property() the function appears first, followed by the keys, while with Ember.computed the dependent keys are specified first.

What ember-property-computed does is provide a compromise between the two; it isn't a prototype extension so it's safe to use in addons*, but it preserves the function-then-keys ordering.

To use it, install the ember-property-computed addon in your project by running ember install ember-property-computed. Then, in any file where you want to define computed properties, import the function:

import cp from 'ember-property-computed';

You can replace cp with whatever name you want to use for the function; I chose cp because it's short and stands for "computed property".

Then, when you want to define a computed property, use the function like this:

//...
computedPropertyName: cp(function() {
  /* do whatever here */
}, 'dependentKeyName'),
//...

• The use of .property() requires the use of Ember's prototype extensions, which can be disabled. Because of that, addons can't rely on .property() being available.

Configuring nginx for an Ember frontend and a Rails backend

One of the projects I'm working on at the moment is a todo list app, with an Ember.js frontend and a Rails API backend. Since it's something that only I'm going to be using (at least for the moment) I decided to keep things simple and just use basic HTTP authentication. With two pieces, I thought the easiest thing to do would be to host both parts on the same subdomain, so that I wouldn't have to deal with CORS and trying to forward the authentication.

I configured the routes for the Rails part to all start with api/v1, so that makes it easy to distinguish requests for the API from requests for the frontend. While I was at it, I also wanted to leave "real" URLs for the various routes in the Ember app, instead of using hashbang URLs.

upstream todo-api {
        server unix:/tmp/todo-api.unicorn.sock fail_timeout=0;
}

server {
        listen 80;
        server_name example.com; # replace with the actual server name

        root /srv/sites/todolist/www;
        access_log /srv/sites/todolist/logs/access.log;
        error_log /srv/sites/todolist/logs/error.log;

        auth_basic "Todolist";
        auth_basic_user_file "/srv/sites/todolist/htpasswd";

        location /api {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_redirect off;
                proxy_pass http://todo-api;
        }

        location / {
                try_files $uri $uri/ /index.html?/$request_uri;
        }
}