Architecting Ember.js Apps

Architecting Ember.js Apps

Covers building Ember.js apps with a focus on application structure, and how responsibilities are divided, and how to manage complexity as your app goes from small to large.

49612ba6e616ca3c4c668ad35e3e84ce?s=128

Luke Melia

August 22, 2012
Tweet

Transcript

  1. 5.

    Mobile Cross-platform, mobile-style UI with offline support, wrapper in PhoneGap

    5 Dashboard Simple one-pager for desktop/tablet, previously Rails + jQuery/ajax Editor Rich desktop-style app for desktop/tablet, previously a Sproutcore app
  2. 6.

    ▪ Develop an understanding of... ▪ Application structure ▪ Division

    of responsibilities ▪ How to manage complexity 6 Goals of the Talk
  3. 7.

    The Idea Behind the Talk ▪ 98% of application architecture

    is understanding your layers and knowing what code should go where 7
  4. 9.

    ▪MVC is not created equal ▪C is for Controller, but

    “controller” has many different meanings. 9 Lay of the Land: MVC
  5. 10.

    ▪ If you’ve never considered yourself a professional UI Engineer,

    you’re about to become one. ▪ Long-lived state ▪ UI responsiveness 10 Lay of the Land: This is UI Development
  6. 11.

    ▪ Ember is still pre-1.0 and moving quickly ▪ Some

    of the advice I share today is likely to be wrong soon. 11 Lay of the Land: Pre-1.0
  7. 12.

    12 How the layers relate Router / State Manager Controller

    Controller View View View View Model Model Model Model
  8. 13.

    13 Overall app data flow Router / State Manager Controller

    Controller View View View View Model Model Model Model Data flows down from models via bindings Events flow up from view layer to the router Router updates models & controllers based on events
  9. 14.
  10. 15.

    15 Router / State Manager Controller Controller View View View

    View Model Model Model Model Models: Usually serialized/deserialized to/from API API Client
  11. 16.

    16 Router / State Manager Controller Controller View View View

    View Model Model Model Model Models: Should not depend on controllers, views or other app state
  12. 17.

    17 Router / State Manager Controller Controller View View View

    View Model Model Model Model Models: May depend on other models
  13. 18.

    18 Router / State Manager Controller Controller View View View

    View Model Model Model Model Identity Map Models: Should use an identity map
  14. 19.

    ▪ To work with the router, a model class should:

    ▪ implement find(id) ▪ implement then(success, failure) (promise pattern) 19 Models: Working with router
  15. 20.

    20 Model Model Model Model Models: Testable in isolation Test

    Suite Test Suite Test Suite Test Suite
  16. 21.

    ▪ ember-data is an ORM for Ember ▪ Store +

    Adapter + Serializer ▪ DS.Store implements an Identity Map ▪ REST Adapter ▪ Work in progress; will be merged into ember.js 21 Models: ember-data
  17. 23.

    23 Router / State Manager Controller Controller View View View

    View Model Model Model Model Controllers: Present data for views to render
  18. 25.

    25 Router / State Manager Controller Controller View View View

    View Model Model Model Model Controllers: Often proxy models
  19. 26.

    Controllers: Ember.ObjectController ▪ Transparently proxies missing properties and methods to

    the object set as its content property ▪ Destroyer of boilerplate 26
  20. 30.

    Controllers: May collaborate with other controllers 30 Router / State

    Manager Controller Controller View View View View Model Model Model Model
  21. 33.
  22. 34.

    Views: Contain all DOM interaction 34 Router / State Manager

    Controller Controller View View View View Model Model Model Model
  23. 35.

    Views: Responsibilities ▪ Render HTML elements ▪ Handle DOM events

    ▪ Trigger actions that affect app state 35
  24. 36.

    Views: Rendering is usually handled with templates 36 Router /

    State Manager Controller Controller View View View View Model Model Model Model Handlebars
  25. 40.

    Views: Use with a single controller ▪ Should bind to

    properties of one controller ▪ If you need data from elsewhere, bring it into this view’s controller using connectControllers() as discussed above 40
  26. 41.
  27. 43.

    Views: Ember-dispatched events 43 touchStart, touchMove, touchEnd, touchCancel, keyDown, keyUp,

    keyPress, mouseDown, mouseUp, contextMenu, click, doubleClick, mouseMove, focusIn, focusOut, mouseEnter, mouseLeave, submit, input, change, dragStart, drag, dragEnter, dragLeave, dragOver, drop, dragEnd
  28. 46.

    Views: Using jQuery to handle events 46 preRender inBuffer inDom

    destroyed didInsertElement (after) willDestroyElement (before) inDom destroyed
  29. 48.

    View tips I ▪ Remember that views are created and

    destroyed over lifetime of app and at render time 48
  30. 49.

    View tips II ▪ It’s a good practice for views

    to know as little as possible about their parent view hierarchy 49
  31. 50.

    Data-binding caveat ▪ Bound properties, using computed properties or bindings,

    are very powerful ▪ Two-way bindings can lead to unexpected behavior and bugs and are often unnecessary 50
  32. 51.
  33. 52.

    Router: Tips ▪ It can get large. Break it up

    into separate files, one per state. ▪ Be careful with asynchronicity in the router event handlers. ▪ Delegate to separate state managers where possible. 52
  34. 53.

    53 Overall app data flow, reprise Router / State Manager

    Controller Controller View View View View Model Model Model Model Data flows down from models via bindings Events flow up from view layer to the router Router updates models & controllers based on events
  35. 54.

    Q & A Follow me @lukemelia Some examples appear courtesy

    of my company, Yapp (which is hiring now or soon). Creative Commons photo credits: flickr.com/photos/fictures/4596895 54