Custom search action

Custom search action

In The search chapter we saw all the possible ways of personalizing the way the component can filter but they all had something in common. You had all the options available upon initialization and you were just filtering that collection.

There are occasions when having all the options available upfront on the client side is not convenient or is downright impossible.

When that's the case you can provide a search action instead of options (it's the only situation where the options are not mandatory) that will be invoked with the search term whenever the user types on the search box.

Using that option you have complete freedom about how you search. Synchronous, asynchronous, with debouncing, using generators, you name it. It's entirely up you you.
There is only three things to know about this action:

  • You should return a collection or a promise that resolves to a collection from this action.
  • You can provide both options and a search action. Those options will be the initial set of options, but as soon as the user performs a search, the results of that search will be displayed instead.
  • This action will not be fired when the search term is blank. It will display the elements inside the options instead.

(It might fail if the API limit is exceeded)

Handling of thenables and cancellables (p.e. ember-concurrecy)

It's also worth mentioning that Ember Power Select is smart enough to always prioritize the last request made, so in the best scenario avoids expensive repaintings, and in the worst case (when the second request resolves before the first), when the first resolves it doesn't override the most recent request.

Also, if the returned thenable is also a cancellable (it responds to a .cancel() method), Ember Power Select will attempt to cancel once it isn't interested anymore in it's result. By example, using ember-concurrency's tasks, if you close the component while a search task is still being processed, it gets cancelled saving a potentially expensive operation that would be ignored anyway.

Open your dev tools and go to the network tab. I'll wait.

In this example below, if you keep typing, no search is fired until after 1500ms of idle time have elapsed. And if before those 1500ms you clear the search or close the select, no request is made at all!

Cool, eh? Now let's see how you can use all of this in testing.