Independant source resolution #620
sarahdayan
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
If I understood the original discussion correctly, this is on purpose to avoid UI flashes, you'd never want a source that's first not to load immediately and later pop in, because that will cause misclicks. How would you link the UI and the split in rendering, force the slower source to be rendered lowest? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Description
Because of the way the Requester API is currently implemented, we wait on every source before returning anything from
onInput
. This means that the slowest source slows down every other source, and they're all returned at once.This can be a problem if you're doing multi-sources with asynchronous APIs which either aren't as performant, or not designed for as-you-type usage. For example, if you have an Algolia source and a GitHub source, the GitHub one will be slower and you'll have to debounce it anyway to avoid rate-limiting. Therefore, even if the Algolia source has returned results, it will be suspended until the GitHub one is done, and everything will be returned at once.
In practice, this may not be a huge issue because you may not need to have radical differences in response time, and you may also want to avoid too many UI flashes. However, this isn't something that should be decided by a shortcoming in our implementation, but designed so the user has control.
Reproduction
Preview →
Steps
Expected behavior
Ideally, we should be able to have sources resolve independently if they have no dependencies with one another. For example, if two sources use
getAlgoliaResults
, they are inherently dependent because we batch calls. However, this shouldn't impact other sources that use third-parties, or static sources that are immediately resolved.This circles back with the initial idea from @francoischalifour for scheduling. For now, the Requester API does only one part of what we initially discussed—batching Algolia calls. What it doesn't do is scheduling, allowing users to determine a resolution strategy and control it either individually, at the source level, or globally, at the Autocomplete level.
Beta Was this translation helpful? Give feedback.
All reactions