Playing a little with Ember.js

Today I’ve been playing with the Ember.js framework . This framework allows you to perform browser actions simplifying the need of querying the server for changes/updates (something that you can achieve with jQuery AJAX, but made simpler), and provides you an -state of the art- MVC architecture to help you modularize you app (client side) in order to make maintenance and ramp up easier. In addition, it give you template capabilities in order to reuse repetitive HTML and JS stuff you can use during your web project. In addition it help you to get rid off the necessary code for refreshing HTML controls using jQuery when a value associated to them changes (the frameworks does it for you if appropriates bindings are set).

After reading all the basic stuff and features it provides, I’ve created a simple HTML and JS files to get to know it better. The sample demonstrate how to organize your browser side code by taking advantage of the MVC pattern and how to create an interactive UI with automatic data refreshing through bindings. It also shows you how to define actions in HTML pointing to view’s methods and how to (through the controller) updates the server data.

The features shown by the example are:

The HTML page contains basically three sections:

• Show the list of people stored in the server (simulated using a global variable)
• Edit a person within the people’s list (showing direct binding and action updating)
• Refresh and Update the edited person to the server

Server stuff (mocks)

To simulate the server stuff the app.js file contains a global variable called peopleServer (this is supposed to be the repository for the people’s list on the server).

Mock server data

There are also 2 functions that “retrieve/send” data from the browser to the server (these functions simulates server calls by getting or setting thepeopleServer variable), but in the middle converts Ember.js objects to plain JSON and vice versa.

Mock server calls

MVC stuff

I’ve started by extending the object class in order to represent our Person model and creating a controller in the app.js file called peopleController. This controller basically exposes the people list (model) and defines the operations to retrieve and update the data to the server.

Person model

People controller

And after having an usable controller I’ve created some views (mainly a query view and an edit view). The HTML page rendering the created views looks like the following:

Figure 1
If you go through the code starting with the HTML file you can follow the chain of responsibilities from there to the views, and finally to the controller.

Bindings

The first view used in the HTML page (peopleListView) has just a one way binding to the people’s property of the peopleController, enforcing that the exposed people property is read-only (Ember.Binding.oneWay).

The second view used (peopleEditView) has a two way binding (Ember.js default) to the people’s property of the peopleController. Changes on the instances of the people property are reflected directly on the controller’s property.

This type of binding (two way) is set by declaring:

Edit people view

And finally we’re using an extension of the Ember.js framework -out of the box- views to edit an object’s property providing binding behavior (data is refreshed automatically by the framework):

HTML input to edit person’s name extension (js)

And usage (html)

In the example shown above the view’s value is bound to the property selectedPersonName of the block view that is wrapping that HTML code (peopleEditView). This property is defined as a computed property in the view definition and contains a getter and setter as you can see in the corresponding box above in the Figure 1. Changes on this input goes directly to the setter of this property where the firstName and lastName of the related object are updated and, as other controls has bindings over these values (indirectly by the dependencies of the fullName property), the change is reflected on other controls in the UI.

Because how the edition is updating the value and how the other view’s binding are defined live update happens while changing value

In the next edit box the bound property is read-only so updates on the instance kept by the controller must be done manually, that’s what the call to the action changeSelectedPersonName (Change[0] link) does:

Action to change person’s name manually

How all the controls are automatically refreshed? Because the properties bound to these control are defined to have a dependency on any of thefullName properties for the people list on the view, so if any of the instances of that list change it fullName property (see definition of fullName and dependencies to firstName and lastName on code) then Ember.js triggers the values updating.

Observers

We’ve defined an observer over the first item on people’s list (the one that we’re editing). The observer is defined in the following block of code like this:

Observer over the first instance of people’s list

As it’s defined to observe over the fullName property of the instance, when a change happens with the property’s value Ember.js will trigger the function declared there and the observer text will be updated on the browser.

Observer text updated while typing…

In the second edit, where you explicitly need to set the change, the observer text will be changed after the action completes.

Observer text updated after the user clicked ‘Change[0]’ and the action completes

Summary

Ember.js provides the foundation for creating browser interactive applications with code modularization by using a well-known pattern (MVC), code reuse through templates and the possibility to write your own custom HTML helpers (handlebars) to achieve all this. The example shown here is a basic idea of how you can use the MVC pattern implemented by Ember.js and take advantage of the binding capabilities. I recommend you to browse the Ember.js page for better understanding and get 100% of it.

Tags: EmberJs, Javascript, MVC