react-query-assist
react-query-assist copied to clipboard
vectordotdev
Async query example
Would be nice to have an example of an async query that takes some time to complete, and potentially have a built in spinner that's override-able.
Yeah I had a spinner originally, but changed it so the dropdown just doesn't open if it hasn't finished loading. Seemed simpler that way.
Side thought: The component only calls the getData prop once, when the input mounts. Should it be called every time the dropdown opens?
Yes we should definitely provide that option, for our use-case we make one fetch to gather all the field types and want to offer autocomplete functionality on the fly for each field as well. So if you're typing level we should be able to hit an autocomplete endpoint and get info, error etc. back as results.
Ah, we may have had a misunderstanding there. Does it not all come down at once following this format? I had thought all the enumerations would be included in the response of the initial request.
I can adjust the code to make async requests for the enums. In that case, would definitely need a spinner.
Ah yep, cool. We may have some options preloaded (that basics like level, request types, etc), but will need to make async requests to autocomplete, ideally we could show the options that are preloaded but append results as they come in.
So just to clarify what @binarylogic mentioned in slack while discussing this (https://timberio.slack.com/archives/G8ZSUPCV6/p1517621696000039):
You’ll get a complete schema to work with. It will include all of the fields names, types, and enumerations. We can also include short descriptions, etc. Sorry we didn’t flesh that out better. Basically it will have
name,type,enumerations(array, can be empty or null) for every field.
That all still holds true, but enumerations might be a partial list?
I believe he intended to offer the autocomplete API eventually, not an immediate need but will let him jump in.
If that's the case, it might be helpful to differentiate between partial enum lists and full enum lists to avoid unnecessary API calls.
What's the advantage to that as opposed to just appending the autocomplete results to existing enums?
Hm, I suppose just avoiding unnecessary API calls. Really depends on what will come back from the autocomplete API, whether it includes the original preloaded enums, is diffed, etc. I would say we only include the enumerations array in the initial request if it's a full list, otherwise we query the autocomplete API. Unless we want to handle diffing the response on the client-side.