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. Architecting Ember.js Apps Luke Melia Ember.js NYC Meetup October 22nd,

    2012
  2. About this Emberaño 2

  3. Relevant Experience 3

  4. My Experience Building Ember Apps 4

  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
  6. ▪ Develop an understanding of... ▪ Application structure ▪ Division

    of responsibilities ▪ How to manage complexity 6 Goals of the Talk
  7. The Idea Behind the Talk ▪ 98% of application architecture

    is understanding your layers and knowing what code should go where 7
  8. 8 Lay of the Land

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

    “controller” has many different meanings. 9 Lay of the Land: MVC
  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
  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
  12. 12 How the layers relate Router / State Manager Controller

    Controller View View View View Model Model Model Model
  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
  14. Models 14

  15. 15 Router / State Manager Controller Controller View View View

    View Model Model Model Model Models: Usually serialized/deserialized to/from API API Client
  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
  17. 17 Router / State Manager Controller Controller View View View

    View Model Model Model Model Models: May depend on other models
  18. 18 Router / State Manager Controller Controller View View View

    View Model Model Model Model Identity Map Models: Should use an identity map
  19. ▪ To work with the router, a model class should:

    ▪ implement find(id) ▪ implement then(success, failure) (promise pattern) 19 Models: Working with router
  20. 20 Model Model Model Model Models: Testable in isolation Test

    Suite Test Suite Test Suite Test Suite
  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
  22. Controllers 22

  23. 23 Router / State Manager Controller Controller View View View

    View Model Model Model Model Controllers: Present data for views to render
  24. Controllers: Expose bindable properties 24

  25. 25 Router / State Manager Controller Controller View View View

    View Model Model Model Model Controllers: Often proxy models
  26. Controllers: Ember.ObjectController ▪ Transparently proxies missing properties and methods to

    the object set as its content property ▪ Destroyer of boilerplate 26
  27. Controllers: Ember.ObjectController 27

  28. Controllers: Ember.ArrayController 28

  29. Controllers: Created during app initialization 29

  30. Controllers: May collaborate with other controllers 30 Router / State

    Manager Controller Controller View View View View Model Model Model Model
  31. Controllers: connectControllers(...) 31

  32. 32 Controller Controller Controllers: Testable in isolation Test Suite Test

    Suite
  33. Views 33

  34. Views: Contain all DOM interaction 34 Router / State Manager

    Controller Controller View View View View Model Model Model Model
  35. Views: Responsibilities ▪ Render HTML elements ▪ Handle DOM events

    ▪ Trigger actions that affect app state 35
  36. Views: Rendering is usually handled with templates 36 Router /

    State Manager Controller Controller View View View View Model Model Model Model Handlebars
  37. Views: Let Handlebars do the heavy lifting 37

  38. Views: Understanding keywords ▪ controller ▪ view ▪ context 38

  39. View: Understanding keywords 39

  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
  41. Views: Ways to handle DOM events ▪ Ember-dispatched events ▪

    Handlebars action helper ▪ jQuery 41
  42. Views: Ember-dispatched events 42

  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
  44. Views: Ember-dispatched events 44

  45. Views: Handlebars action helper 45

  46. Views: Using jQuery to handle events 46 preRender inBuffer inDom

    destroyed didInsertElement (after) willDestroyElement (before) inDom destroyed
  47. Views: Using jQuery to handle events 47

  48. View tips I ▪ Remember that views are created and

    destroyed over lifetime of app and at render time 48
  49. View tips II ▪ It’s a good practice for views

    to know as little as possible about their parent view hierarchy 49
  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
  51. Router 51

  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
  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
  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