rgerkin
commented
4 years ago One solution (related to #384 and #380) would be to reduce the amount of content loaded per client-side interaction. Until then, or on expectation that it may never be fast enough, I think the timeout I proposed is easy enough. The user can type as fast as they want, but don't load from the server unless the previous load was more than ~500 ms ago.
From @rgerkin: When I filter, the server is not quite fast enough to keep up with typing, so if in the course of typing many different API queries are produced, it will try to load each of them in a row and so several of them might still be getting loaded in sequence after I have finished typing. When all filtering is client-side this not a problem because pure-JS filtering is fast, but since we are hitting the server API each time it is too slow. So maybe a timeout of a few hundred ms after each keystroke would help, to make sure that it doesn't try to load too many intermediate version of the filter I want. Anything selected from the autofill could be retrieved immediately, but anything typed probably shouldn't until there is a pause in the typing.
Alternatively this won't be a problem on Dendrite and the current user experience is fine. But on Spike it was a little weird because the content would update several times after I was done typing in some cases.