Ember.Decorator.md

Dear Ember.JS team, for your consideration:

We have things like title and draggable natively: attributes that add behavior to an element. I'd like this ability in ember. It could work something like this:

App.TooltipDecorator = Ember.Decorator.extend({

  tooltipElement: function() {
    return Ember.$('#'+this.get('tooltip'));
  }.property('tooltip'),

  show: function() {
    this.get('tooltipElement').show().position({
      of: this.$()
    });
  },

  hide: function() {
    this.get('tooltipElement').hide();
  }.on('didInsertElement')

  mouseEnter: Ember.aliasMethod('show'),
  
  mouseLeave: Ember.aliasMethod('hide').on('didInsertElement')

  // basically the api in here is the same as for an Ember.View,
  // with dom event hooks, this.$(), on('didInsertElement') etc.

});

And the template:

{{#x-foo tooltip="foo-tooltip"}}Hello and stuff{{/x-foo}}

<div id="foo-tooltip">I am the tooltip</div>

Thanks.

This looks like a very concise way to add common functionality to components that's otherwise very awkward to add.

How is this different than a mixin that is injected into Ember.Component via reopen?

It's actually quite similar to that and possibly even the correct implementation. Let's think about how this fits in with web components (my only concern in the past) and get this on the docket. Maybe we'll Eben be able to influence the spec.

http://www.w3.org/TR/components-intro/#decorator-section

Decorators ... do not have a specification yet.

@ebryn

Three differences I think are important:

1. Its an explicit API with specific behavior, makes it more obvious how to create this kind of functionality (and therefore easier to document, etc etc.)
2. You don't have to write the code to check for the presence of the attribute to make things happen.
3. (and most importantly) you don't pollute the "global" component definition. You could never do Ember.Component.reopen({ show: function(){} }) without breaking other decorators.