Sorry about the made up word: Attribute-Level Component.
If you have experiences on angular, you would know Attribute-Level Directive. As far as I know, components are some sort of equivalent things compares to directives, and attribute directives are real useful in many situations.
For example, if I want to track some DOM element, to change its width/height when window size changed, or do something when mouse moves to the edge of that DOM element. I can write an attribute directive and attach it to the HTML tags for both cases. Since this behaviour could happens on everywhere, it should better be an attribute than an element.
In Ember.js, I can’t find such mechanism to help me out. I’m wondering that maybe write a mixin and use it to every component needed, but not every DOM manipulation suits for custom component, what if I need it on <html>, or <body>?
This seems like something a helper should do. Although your example, changing an element’s size based on window size, can easily be achieved using CSS alone. Look into viewport units.
…or do something when mouse moves to the edge of that DOM element.
To be more specific, If I want to track mouse move, when it close to the edges of document or window, something should happen, like dropdown a menu. How this behaviour should be implemented in Ember way? In traditional way, we could listen mousemove on document, but this can also happen on every element, or happen on multiple elements at the same time/view. How to encapsulate these kinds of actions and use it more conveniently? In Angular this can be written as an attribute directive, you can attach this custom attribute on any HTML tags, how about Ember?
In fact, there are lots of scenarios that components could be “too heavy”, some of them do really need javascript, not easy as the viewport-unit case.
Compare to Angular, I think helpers are more like filters, they’re useful for data transformation, but not good for trivial DOM manipulation or handle browser events.
OK, yeah, a helper probably isn’t what you want for this. If the elements involved are all components then I suppose you could use a mixin. If not, i’m really not sure. Create a component that wraps all of your elements?
A wrap-all component may helps for some situations, I had thought about it, but later I realized it is not an ideal method. Because it could wrap many many elements/components, some of them may need additional behaviours but some not. It is hard to setup or to change programatically, even worse, elements/components could be dynamically added/removed in this wrapper component, a component should not to know or be responsible to such complex scenario, these behaviors should act on the very specific target element not conditional children.
I think your Problem is that you want to solve something outside of the ember flow.
You think too much about DOM elements, DOM events and manipulating them.
But in a Ember app you want that Ember knows mostly everything. So we have to split your requirement into event listening and DOM manipulation.
The DOM Manipulation is easy with ember. Bind CSS to Properties, and you are able to open/close a dropdown in a very elegant way. May use special Components and/or mixins for that.
And the events are actually avaliable on every View, so also every Component since Em.Component extends Em.View.
If you want to listen on global events (mousemove, scroll, etc.) you usually you only want this only while a specific component is alive, so use didInsertElement. I’ve done this to implement a foreverscroll.
Always try to handle every application state inside the Ember application, and not in legacy javscript.
I’ve had the exact same question. My main need with an Attribute Component is access to the DOM element it was used on. IMO, a Helper does not work well in this case, and is the last piece missing from Angular Directives. I’m not sure what the feelings of the core members are, but I’d really like to see this some day…
Always try to handle every application state inside the Ember application
But this still doesn’t help for particular problems, we can hacks for these in order to put them in the Ember way, but the true problem is Ember lacks of some support on these scenario, otherwise users (like me) would not have to ask helps.