Good point! It means you could react sooner (if it's in the cache) but it's also quite rare that the cache gets used. For an autocomplete it only really happens if you backspace a couple of characters and go back to a query you've done before.
Arguably, by putting the cache-use nearer the fetch() call makes it slightly easier to keep things mentally in the right places.
Shouldn't the cache check be done in `changeQuery` listener(before the decision to throttle or debounce) instead of in `makeAutocompleteLookup`?
If we already have the results, there's no need to throttle/debounce this operation because it takes only a couple of milliseconds to rerender the list with new data.
Comment
Good point! It means you could react sooner (if it's in the cache) but it's also quite rare that the cache gets used. For an autocomplete it only really happens if you backspace a couple of characters and go back to a query you've done before.
Arguably, by putting the cache-use nearer the fetch() call makes it slightly easier to keep things mentally in the right places.
Parent comment
Shouldn't the cache check be done in `changeQuery` listener(before the decision to throttle or debounce) instead of in `makeAutocompleteLookup`? If we already have the results, there's no need to throttle/debounce this operation because it takes only a couple of milliseconds to rerender the list with new data.