Slide 1
Slide 1 text
Architecting
Ember.js
Apps
Luke Melia
Ember.js NYC Meetup
October 22nd, 2012
Slide 2
Slide 2 text
About this Emberaño
2
Slide 3
Slide 3 text
Relevant
Experience
3
Slide 4
Slide 4 text
My
Experience
Building
Ember
Apps
4
Slide 5
Slide 5 text
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
Slide 6
Slide 6 text
■ Develop an understanding
of...
■ Application structure
■ Division of responsibilities
■ How to manage complexity
6
Goals of the Talk
Slide 7
Slide 7 text
The Idea Behind the Talk
■ 98% of application
architecture is
understanding your layers
and knowing what code
should go where
7
Slide 8
Slide 8 text
8
Lay
of the
Land
Slide 9
Slide 9 text
■MVC is not created equal
■C is for Controller, but
“controller” has many different
meanings.
9
Lay of the Land:
MVC
Slide 10
Slide 10 text
■ 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
Slide 11
Slide 11 text
■ 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
Slide 12
Slide 12 text
12
How the layers relate
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Slide 13
Slide 13 text
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
Slide 14
Slide 14 text
Models
14
Slide 15
Slide 15 text
15
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Models:
Usually serialized/deserialized
to/from API
API Client
Slide 16
Slide 16 text
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
Slide 17
Slide 17 text
17
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Models:
May depend on other models
Slide 18
Slide 18 text
18
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Identity Map
Models:
Should use an identity map
Slide 19
Slide 19 text
■ To work with the router, a model
class should:
■ implement find(id)
■ implement then(success, failure)
(promise pattern)
19
Models:
Working with router
Slide 20
Slide 20 text
20
Model Model Model Model
Models:
Testable in isolation
Test Suite Test Suite Test Suite Test Suite
Slide 21
Slide 21 text
■ 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
Slide 22
Slide 22 text
Controllers
22
Slide 23
Slide 23 text
23
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Controllers:
Present data for
views to render
Slide 24
Slide 24 text
Controllers:
Expose bindable properties
24
Slide 25
Slide 25 text
25
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Controllers:
Often proxy models
Slide 26
Slide 26 text
Controllers:
Ember.ObjectController
■ Transparently proxies missing
properties and methods to the
object set as its content property
■ Destroyer of boilerplate
26
Slide 27
Slide 27 text
Controllers:
Ember.ObjectController
27
Slide 28
Slide 28 text
Controllers:
Ember.ArrayController
28
Slide 29
Slide 29 text
Controllers:
Created during app
initialization 29
Slide 30
Slide 30 text
Controllers:
May collaborate with other
controllers 30
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Slide 31
Slide 31 text
Controllers:
connectControllers(...)
31
Slide 32
Slide 32 text
32
Controller Controller
Controllers:
Testable in isolation
Test Suite Test Suite
Slide 33
Slide 33 text
Views
33
Slide 34
Slide 34 text
Views:
Contain all DOM interaction
34
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Slide 35
Slide 35 text
Views:
Responsibilities
■ Render HTML elements
■ Handle DOM events
■ Trigger actions that
affect app state
35
Slide 36
Slide 36 text
Views:
Rendering is usually
handled with templates 36
Router /
State Manager
Controller Controller
View View
View View
Model Model Model Model
Handlebars
Slide 37
Slide 37 text
Views:
Let Handlebars do
the heavy lifting 37
Slide 38
Slide 38 text
Views:
Understanding keywords
■ controller
■ view
■ context
38
Slide 39
Slide 39 text
View:
Understanding keywords
39
Slide 40
Slide 40 text
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
Slide 41
Slide 41 text
Views:
Ways to handle DOM events
■ Ember-dispatched events
■ Handlebars action helper
■ jQuery
41
Slide 42
Slide 42 text
Views:
Ember-dispatched events
42
Slide 43
Slide 43 text
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
Slide 44
Slide 44 text
Views:
Ember-dispatched events
44
Slide 45
Slide 45 text
Views:
Handlebars action helper
45
Slide 46
Slide 46 text
Views:
Using jQuery to handle events
46
preRender
inBuffer
inDom
destroyed
didInsertElement (after)
willDestroyElement (before)
inDom
destroyed
Slide 47
Slide 47 text
Views:
Using jQuery to handle events
47
Slide 48
Slide 48 text
View tips I
■ Remember that views are
created and destroyed over
lifetime of app and at render time
48
Slide 49
Slide 49 text
View tips II
■ It’s a good practice for views to
know as little as possible about
their parent view hierarchy
49
Slide 50
Slide 50 text
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
Slide 51
Slide 51 text
Router
51
Slide 52
Slide 52 text
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
Slide 53
Slide 53 text
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
Slide 54
Slide 54 text
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