Support async choices loading in single-dropdown

[nidu]

Hello.

Can we add support of async choices loading to single-dropdown component? Here are some thoughts:

Description

Sometimes i need to load only portion of large data list. Probably i don't even want all this data outside the dropdown so don't wanna bother with fetching it around the list and updating on key press, so it could be convenient to embed this behavior into the component.

I suppose it doesn't need to use any external dependencies as using js setTimeout can be enough.

Why not just use typeahead? To me having two separate components for sync and async dropdowns looks inconsistent in both API and UI. Moreover single-dropdown have some great features like grouping.

UI

Async data load adds two features to UI:

• We probably would like to show that data is loading. It may be shown in dropdown itself with dimmed text "Loading..." for example (or throbber could be used). Showing this status in dropdown list allows informing user only when he's interested in it (opens dropdown) and not on page load for example.
• We would like to show error if data couldn't be loaded. This may be shown similar to Loading status above but on reddish background (probably with "Error:" prefix).

Other than that UI is same. Async loader should return choices in same format as they are currently provided.

API

• :choices should also accept function of signature (opts, done, fail) -> nil where
  • opts is a map with filter-text and regex-filter? (Question: is it sufficient?)
  • done: (choices -> nil) is called by client with when data is received
  • fail: (error -> nil) is called by client when failed to receive data Client should call either done or fail, not both. To ensure this an error can be thrown or these methods could be grouped into one. For example function would have signature (opts, callback) -> nil where callback would be called with either {:result ...} or {:error ...}.
• add :debounce-delay functioning similar to typeahead

If :choices is not function all this async stuff is just skipped and dropdown works same way as of now.

Question: Alternatively :choices can operate with promises - would it be a nice choice considering that re-com doesn't strive for old browser support? Using callbacks is more universal and is enough here as for me.

Any thoughts about this? Maybe this task should be implemented differently?

UPD 1: here is an example implementation (see demo9 in dropdown demos).

[Gregg8]

We've had a play with your fork and decided to merge it as is. We're fine with all your choices.

That's not to say it cannot continue to be further iterated.

Thanks for this!