Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Ember Components

jrallison
August 22, 2013

Ember Components

EmberNYC August 2013

jrallison

August 22, 2013
Tweet

More Decks by jrallison

Other Decks in Programming

Transcript

  1. JOHN ALLISON @JRALLISON Thursday, August 22, 13 Picture from our

    company retreat last week. It was awesome, you should do it.
  2. embereNos since JUNE ’12 Thursday, August 22, 13 Used ember.js

    in production for over a year. Ember has been moving fast (as you know), we have lots of bumps and bruises, but really liking where the framework is headed. large ember application... 41 controllers (story)
  3. Reuse Reuse Reuse Reuse simplify Reuse Views Thursday, August 22,

    13 taking a step back One of the recurring themes we’ve faced is how to extract templates and behavior to simplify and better reuse code. We’ve tried several approaches and most brought us....
  4. How to reuse? Thursday, August 22, 13 taking an example...

    we have a “paginated list” used many places around our ember application has a variety of different uses, different columns, content, paginated or infinite scroll, etc... prior to components, what are the options for sharing view templates and behavior? all prior alternatives have great use-cases, but I’d argue that they aren’t really suited for real reuse
  5. Custom handlebars helpers? Thursday, August 22, 13 pro: ? very

    low-level control if you need it... con: can be quite confusing to make sure you know about how to setup context, etc. con: not something you should be doing if you want reusable code to be a pattern in your codebase IMO.
  6. Partials? Thursday, August 22, 13 pro: great for simplifying views

    by breaking up into smaller pieces con: no real way to encapsulate behavior con for reusable code: context is the parent view, no separation
  7. Shared views? Thursday, August 22, 13 this is what we

    ended up doing when we faced this problem awhile ago. pro: can encapsulate both template and behavior con: you’re still sharing context with the parent view, which can make it hard to reuse if you aren’t careful con: if you need data for your shared view, you’ll have to manually setup any controllers or related objects
  8. Shared views? (share implemention of paginated view) Thursday, August 22,

    13 also has a view object, state machine, and associated controller which aren’t shown not great but it worked for us.
  9. RenDER? Thursday, August 22, 13 if render had been around

    when we were building this, we may have used it instead. I don’t have much hand on knowledge of render, but the idea is it setups up a MVC structure like a route would. pro: encapsulated, isolated template and behavior! con: can be heavy weight if you don’t have a model or much related data con: expects a model, which can make it hard to reuse in a generic way.
  10. ComponentS Introduced in 1.0 RC.6 Isolated, self-contained “Views” Implementation modeled

    after W3C “Custom Elements” Spec Thursday, August 22, 13
  11. BUILDING components Thursday, August 22, 13 while on our retreat,

    we talked high level company goals but we also were able to start hacking on a refresh of our interface and update our ember skillz with all the newest stuff and write some golang...
  12. BUILDING components Thursday, August 22, 13 sparkline: great candidate for

    components. used elsewhere in the app, not just specific to campaigns. Just needs to know about a few pieces of data needs control over template and view to properly setup and render.
  13. BUILDING components Thursday, August 22, 13 ‘components/’ namespace dash is

    to met the “Custom Elements” spec context is limited to only data passed to the component. we can now use the component to render any type of data (rather then being tied to a campaign, etc)