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.

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