Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Brief Introduction To Ember.js

A Brief Introduction To Ember.js

Christopher Meiklejohn will be presenting a basic overview of Ember.js, why you would want to use it, and how Basho uses it in their web applications.

Christopher Meiklejohn

September 26, 2012
Tweet

More Decks by Christopher Meiklejohn

Other Decks in Programming

Transcript

  1. Basho • Creators of Riak • Dynamo • Erlang •

    We are hiring! 3 Friday, September 28, 12
  2. Goals • This is not a tutorial. • Not trying

    to teach every single implementation detail of an Ember application. • Focusing on concepts and not syntax. • Showing an easier and more expressive way of building web applications. 4 Friday, September 28, 12
  3. Ember.js • MVC framework • Inspired by Cocoa • Fork

    of SproutCore 2.0 • In the family of MV* style frameworks. • Knockout.js, Angular.js, Backbone.js • Leverages jQuery, Metamorph, Handlebars 6 Friday, September 28, 12
  4. Goals • Eliminate boilerplate • Loading a series of data

    • Rendering data into the DOM • Updating the DOM as it changes • Provide standard application architecture • MVC-based framework • Rich application router / state manager 8 Friday, September 28, 12
  5. Part 1: Concepts • Ember Core Features • Bindings/Computed Properties

    • Auto-updating templates • State Manager • Router • Ember Data • Run Loop and Asynchrony 9 Friday, September 28, 12
  6. Bindings • Keeps properties of objects in sync • One-way

    or two-way • Propagation of changes in direction • Chainable • Extremely useful with MVC • Model => Controller => View 12 Friday, September 28, 12
  7. Computed Properties • Treat a function like a property •

    De!ne dependencies of that function • Binding changes cause property to update • Chainable 14 Friday, September 28, 12
  8. State Manager • Implementation of a !nite state machine •

    Building block for several applications • Perfect for managing many complex states 19 Friday, September 28, 12
  9. State Manager • Concepts • enter/exit • actions • states/nested

    states • Examples • record lifecycle in Ember Data • routing in Ember 21 Friday, September 28, 12
  10. Router • Built on top of the Ember state manager

    • De!nes a series of application states • Generates URLs based on state • Serialization of current state • Allows linking to speci!c application state • URL is deserialized • State chart traversal 22 Friday, September 28, 12
  11. Router • Upon entering a state the router can: •

    Insert a particular view into the DOM • Load content from the data store • Assign content to the controller 24 Friday, September 28, 12
  12. Data • Data persistence layer for Ember • Exposes API

    for persisting and loading records • Pluggable adapters • Fixture/REST/IndexedDB • Uses StateManager, integrates with Router • Alpha quality 26 Friday, September 28, 12
  13. Asynchrony • Property change causes invalidation of dependencies • Changes

    are queued, and subsequently coalesced • As run loop !nishes, changes are propagated down to all bindings • Extremely e"cient • Coordinated by the Ember Run Loop 28 Friday, September 28, 12
  14. Riak Control • Control panel for managing Riak • Server

    written in Erlang • UI originally built with jQuery and pjax • Re-architected in Ember.js • Improved performance • Massive reduction in view rendering code • In place updates of content when polling 32 Friday, September 28, 12
  15. Models • De!ne Ember Data models • De!ne attribute types

    • Also supports hasMany, belongsTo • Adapter responsible for retrieving the object • Default RESTAdapter very opinionated 34 Friday, September 28, 12
  16. Router • De!ne a state for each top level state

    • Snapshot, Cluster, Ring, etc. • De!ne actions on the router which will be used for state transitions, or navigation. • De!ne default state for the router. • When entering state, load models and connect the router. 36 Friday, September 28, 12
  17. Application Template • Consists of a series of links and

    an outlet • Router will, based on current state • Instantiate (one or more) controller/view pair for that state • Connect that view to the outlet 38 Friday, September 28, 12
  18. Template and View • Consists of a series of computed

    properties • Automatically updated as the model changes • View renders only the template 41 Friday, September 28, 12
  19. Controller • Controller is responsible providing !ltered computed properties to

    the view. • Not showing you awful hack to refresh objects via XHR. 44 Friday, September 28, 12
  20. Conclusion • Lots of conventions • Follow the conventions, and

    bene!t • Eliminate boilerplate code in your app • If you don’t like changing APIs, wait for 1.0. 48 Friday, September 28, 12