An introduction to Ember CLI

JavaScript as a language has come a long way from providing simple dynamic validations, to building complex single page web application. With this evolution, the problems you encounter while building a complex web application also surface in the JavaScript world. These include some of the following:

  • Managing deployments
  • Linting
  • API stubbing for development
  • Accessing APIs via proxy
  • Running tests
  • Continuous integration
  • Managing the dependencies of your application

Until now, developers working on ambitious web applications have been trying to solve these issues using different independent sets of tools. Integrating your framework with these tools can take some time and effort. What if there was a tool that could manage all of these and more, irrespective of the server or language you are integrating your single page web applications with?

Ember CLI aims to be one such Ember.js command line utility that you can use to build, develop, and ship ambitious single page web applications.

Ember CLI was based on the Ember App Kit project, which is now deprecated.

Asset pipeline

Ember CLI includes the fast asset pipeline broccoli (can be found at https://github.com/broccolijs/broccoli). Broccoli draws heavy inspiration from the Rails asset pipeline. It runs on node.js and is independent of the backend platform you are working with.

One of the most common ways to handle asset compilation and minifying is to use the Grunt task runner, or a similar tool. Let's say you are working on an application that involves the compilation of CoffeeScript, Sass, and other similar assets. Now to make these assets available to our application, you will have to write a Grunt task that does the compilation.

When you start the active development of your application, you will realize that running the Grunt task after making any changes to your CoffeeScript or Sass files is cumbersome and time-consuming. So, you start using grunt watch in your application to rebuild your entire application whenever you make any changes anywhere in your application. But very soon, when your application grows in size and complexity, you will realize that grunt watch is taking too much time as you are rebuilding your entire application, even if only one of the Sass files has been changed.

Broccoli, on the other hand, figures out which files have changed and only rebuilds those that were modified. This means that rebuilding is now a constant time with the number of files in your application, as you generally only rebuild one file.

This is just one example of what broccoli is capable of. It has many more useful optimizations to make your development and build process simple and fast.

Some of the assets that are supported by Broccoli include:

  • Handlebars
  • Emblem
  • LESS
  • Sass
  • Compass
  • Stylus
  • CoffeeScript
  • EmberScript
  • Minified JS and CSS

Every Ember CLI project will contain a file called Brocfile.js present at the root of the project. This is the definition file and contains build-specific instructions for your project.

Modules

Before Ember CLI or the Ember App kit, Ember applications used to define their component in the global namespace. The name of these components was very important, as the Ember resolver used to find these components in the global namespace using their name.

Using global namespaces for your application is manageable for smaller applications, but it is definitely not a recommended way of developing your application, as it exposes all the components of the application, and allows you to manually start including components in other components that should not be accessible there.

Ember CLI tries to address these concerns by including the ES6 module transpiler (can be found at https://github.com/esnext/es6-module-transpiler). The ES6 module transpiler lets you write a subset of ES6 or the EcmaScript6 module syntax, and then compiles it to the AMD (asynchronous module definition) that is supported by RequireJS (http://requirejs.org/).

Using modules will enable you to define and export your class definitions, and lets you import them wherever required. It does not expose all of the app components to the rest of the application and hence, is more modular and abstraction friendly.

Ember CLI also comes with its own resolver that understands the application structure, and uses the file names as the convention to make the required modules available to other dependent modules. For example, your route in routes/product.js will know to use the controller in controllers/product.js, and the template in templates/product.hbs.

Prior to Ember CLI, the default resolver used to work by resolving the names from the global namespace. Something similar to the following:

App.IndexRoute = Ember.Route.extend({
  model: function() {
    return ['something','else'];
  }
});

This would resolve to index route of the application that is defined App. But with the new resolver (found at https://github.com/ember-cli/ember-resolver), you don't need to write or pollute the global namespace of your application, as it works on ES6 semantics.

The above index route will now be picked up from the app/routes/index.js file, which should return a valid ES6 module definition.

This is how a sample ES6 module-compatible index route will look:

// app/routes/index.js
import Ember from 'ember'
export default Ember.Route.extend({
  model: function(){
    return ["something","else"];
  }
});

Ember CLI's new resolver works by looking for the ES6 modules exported from corresponding files.

You can see that the names of the components are now picked up from designated file locations. The resolver looks for the module that is exported from app/routes/index.js, and initializes the index route of the application with the same. The same also applies to rest of the components in the Ember.js framework, including views, controllers, components, adapters, and models.

Managing the dependencies of your application

Ember CLI uses bower (http://bower.io/) as the default tool to manage the dependencies of your application. Bower lets you easily manage and keep your frontend dependencies up-to-date. Bower works by looking for and installing the dependent packages that you defined in its definition file.

Ember CLI also uses npm or the node package manager (https://www.npmjs.com/) to manage its internal dependencies. The best part about the above dependency management tools is that they are already integrated with the rest of the components, including the asset pipeline, and work flawlessly with Ember.js applications.

Content security add-on

Ember CLI comes with the content security add-on, which activates the content security policy on modern browsers while running the development server. This plugin, when enabled, sets the Content-Security-Policy HTTP header to the response that is sent from the Ember CLI development server. This guards your application against XSS attacks.

The default behavior for this plugin is to allow content form 'self'. This means that by default, you will only be allowed to load in assets from the domain that is serving the application. In order to change the content security settings of your development Ember CLI express server, you can change the settings in the config/environment.js file present in your project directory.

The Content-Security-Policy is currently supported by Chrome (25+), Safari (7+), and Firefox (23+).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.143.0.85