Application Patterns tw://adman65 - gh://twinturbo - me@broadcastingadam.com -präsentiert in Hamburg

Wer bin Ich? • Adam Hawkins • broadcastingadam.com • twitter.com/adman65 • github.com/twinturbo • speaker.com/u/twinturbo • Jeden Tag arbeite ich an ember Apps

How to Avoid This Feeling

Express Your Application in Handlebars

Bad BlogPostView = Ember.CollectionView.extend({ elementId: 'posts', classNames: ['post-list'], itemViewClass: Ember.View.extend({ // your stuff here classNames: ['post'], }) });

Good

{{each controller}}

• {{title}}

  {{text}}
{{/each}}

Why? • More designer friendly • Styling and markup is not application level, it’s presentation • Hard to track down where markup happens • Break this rule: when you have more complex views

Views bind to Controllers

Bad

Baz: {{someHelper "App.foo.bar.baz"}}

Good ViewController = Ember.Controller.extend({ bazBinding: Ember.Binding "App.foo.bar.baz" })

Baz: {{someHelper baz}}

• Just because you can reach out, doesn’t mean you should • Views use their controller, not others • Controller provides everything a view needs Why?

Router Handles Persistent State

if(stateAccessibleViaURL) { app.stickInRouter(); } else { app.stickInController(); }

Unbind Event Listeners (when you need to)

Ember.View.extend({ // we need a reference to this resizeListener: (function({ $.proxy this.windowDidResize, this }).property(), windowDidResize: function({ // your logic here }), didInsertElement: function({ $(window).on('resize', this.resizeListener) }), didRemoveElement: function({ $(window).off('resize', this.resizeListener) }) });

Respect the following diagram

• Respect the boundary at the top • User’s interact with your app via the URL and DOM • Controllers do most of the work • Handlebars represents the UI at any given point • Controllers don’t interact directly with views • Views interact with the DOM via didInsertElement and friends

If you only remember one thing: remember the diagram

DS.FixtureAdapter

SCHEIßE DINGE

• Forces your mind into an API box • Extremely test unfriendly • Development & testing concerns mix with production concerns • Fixtures are not application model, they are API responses Wieso?

Was ist besser?

Respect the Boundary in the Diagram

DS.InMemoryAdapter • Uses a “pass through” serializer • Instantiate the DS.Model objects you want and call commit() • No need to track FK’s. Just add to the association and call commit() • Focus on application data • Leverage the boundary for your benefit

Bad Post.FIXTURES = [ { id: "1", title: "Post 1", text: "Lorem...." comment_ids: ["1", "2"] } ] Comment.FIXTURES = [ { id: "1" text: "Zomg" post_id: "1" } ]

Good post = Post.createRecord({ title: "Post 1" text: "Lorem..." }); comment = Comment.createRecord({ text: "Zomg" }); post.get('comments').pushObject(comment); store.commit()

Respect the Boundary

Test the application independently from data sources

Test data source interaction at the adapter level

• Ember.Binding.oneWay when applicable • Ember.Computed.alias (in the works) • Use a build tool (Iridium is the best) • If using Rails + Ember Data, then use ActiveModel::Serializers • Push async code to the edge of your application • Controllers decorate objects Grab Bag

Ende Wer hast eine Frage?