Ember power select aims to be maximally flexible and because of that it doesn't try to make strong assumptions about how you want to use it. Instead it embraces DDAU (Data Down Actions Up) philosophy of Ember 2.0 so data flow always is unidirectional and explicit.
Data changes that occur in the component are not propagated to the outside using two-way bindings, but rather they are communicated via actions.
This section describes the available actions with the notable exception of the
because there is an entire section dedicated to it, and gives you some examples of what you
can do with each of them.
This action will fire whenever an option of the component is selected or unselected.
The most common use case when you want changes inside a component to do something on its context is expressed this way:
That gives you the freedom of doing whatever suits your needs when the user selects a value.
If the only thing you want to do is update the value, you can make it more concise by using the
It might seem a bit more verbose at first for this, the simplest use case possible, but it simplifies a lot the mental model and enables some advanced usages that would otherwise be very tricky to implement.
The second option you can provide to the component to customize it's behavior is
This option will be fired whenever the user presses a key while the component or the search input inside
have the focus.
This action receives two arguments,
event. The first one is
an object that you can use to control the component through its actions (open, close, toggle...).
The event is the raw
keydown event you can use to decide what to do next.
If you desire to hijack the browser's default bahaviour you can call
preventDefault on that
event. If you want to avoid the component's default behaviour (e.g., open/close the select or
navigate through the options using the arrow keys) return
false from this action.
One particular common use case for this action is to add new options in multiple selects when the user introduces free text.
Selects might have searchboxes. When you type on them you usually want to search, which is the default behaviour,
but what if you whant to do other things before searching? Then you have the
oninput action that is
fired before the search.
This action gives you the opportunity to react to any change in the inputs of the select, even when the inputs are
emptied, because the
search action doesn't fire in that case. If you return false from this action,
you will prevent the default behavior, which is searching.
Let's create a select that searches only if the length of the search is bigger than 3 chars.
The next actions you can use are
onfocus/onblur. It does exactly what the names suggests and receives
You can use this action for many things (fire a request to prefetch data, show a tooltip, trigger some animation ...) but perhaps the most straightforward use case is to automatically open the component on focus.
Note that this action will be fired when the component or another element inside, like the searchboxes, gain the focus,
and sometimes you need which one triggered the focus/blur event. Since the
FocusEvent is received
as last argument, you can check
event.target to know what element gets the focus, and
to know the element that had the focus before.
As their names suggest, these actions are fired when the component is about to be opened or closed respectively,
and they both have the same signature
(select, event) (the event will be undefined if
the component is not opened as result of user interaction).
You can use this action for many useful purposes, but since the troll-force is strong in me, I want to show a useless example: The select components for spies!
Another neat trick is that you can prevent the component from open/close if you return
from these actions, so you have the last word. This is all it takes to create a mandatory select component
that once opened cannot be closed until you select some value, and changes
the styles of the component.
Have I mentioned that your can also render groups?