Ember.Component - October 2013 Seattle Ember.js meetup

Alex Matchneer introduces Ember.Component and outlines his ideas for fostering an ecosystem of reusable/composable/shareable components

Transcript

1. Ember Components Seattle Ember.js Meetup: October 10, 2013 Thursday, October 17, 13
2. ❖ Ember Core Team Member ❖ Author of Emblem.js ❖ Mr. Router 2 Alex Matchneer @machty Thursday, October 17, 13
3. Ember.Component ❖ A special kind of Ember.View ❖ With a focus on being reusable, composable, and (hopefully soon) shareable ❖ Goal: Maintain parity with Web Components specifications 3 Thursday, October 17, 13
4. Classic Ember.View ❖ In above example, foo is provided by the controller ❖ Subviews (e.g. custom-widget) inherit scope from parent view 4 Thursday, October 17, 13
5. Classic Ember.View ❖ Views provide templates with a context (i.e. where to look up the value of {{foo}}) ❖ Most often, this context is a controller ❖ Allows for separation of concerns: Views manage DOM elements, Controllers drive templates with data. 5 Controller foo: 123 View context: controller Template {{foo}} Thursday, October 17, 13
6. 6 Limitations Classic Ember.View ❖ Separation of concerns in this case can come at expense of reusability/refactorability ❖ Two controllers that want to render the same view must adhere to the same duck-type-y interface, e.g. both controllers have to define a property called foo Thursday, October 17, 13
7. Enter Ember.Component ❖ An Ember.View subclass whose template context is the component instance itself (i.e. look for {{foo}} on the component) ❖ Isolated scope ❖ Aaaand much more... 7 Thursday, October 17, 13
8. ❖ Within the components/custom-widget template, foo is looked up within AutoCompleteComponent ❖ No scope leaking 8 Thursday, October 17, 13
9. Components are way isolated 9 Thursday, October 17, 13
10. 10 ❖ A Component defines an interface for how data comes in and actions fire out ❖ Pass in data explicitly, e.g. {{some-component foo=someControllerProperty}} ❖ Map component actions to controller/route actions {{some-component component-action=‘routeActionName’}} Components are way isolated Thursday, October 17, 13
11. 11 ❖ Rendering components multiple times, in multiple templates is easy: ❖ Just pass in different data, e.g. {{some-component foo=otherControllerProperty}} ❖ Or change action mappings, e.g. {{some-component component-action=‘otherActionName’}} ❖ No need to change controller property names to accommodate component templates Components are way reusable Thursday, October 17, 13
12. Demo 12 https://machty.s3.amazonaws.com/ember-seattle-components/index.html Thursday, October 17, 13
13. About Shareability ❖ No agreed-upon / caveat-free of packaging your component code/template/CSS ❖ But soon... 13 Thursday, October 17, 13
14. Alex’s Thoughtz ❖ Disclaimer: this is far from official doctrine ❖ Goal: foster an ecosystem of flexible, overridable, composable components ❖ Goal++: don’t let it dissolve into jQuery-plugin-150+ options-barely-configurable-free-for-all 14 Thursday, October 17, 13
15. Example: Calendar ❖ After importing calendar component code... 15 Thursday, October 17, 13
16. Example: Calendar ❖ Day cells should also be emphatic! 16 Thursday, October 17, 13
17. Example: Calendar ❖ The Calendar component author never intended to make the month header clickable... how do we make it clickable? 17 Thursday, October 17, 13
18. cray cray? ❖ Again, this doesn’t exist yet, no one really agrees with me, yet, but... ❖ The important focus is composability/overridability with intelligent defaults 18 Thursday, October 17, 13
19. Demo 19 Thursday, October 17, 13
20. Thank you! ❖ @machty on Twitter / GitHub 20 Thursday, October 17, 13