On 3/7/2023 7:33 AM, Dino wrote:
It must be nice to have a server or two...
No kidding
About everything else you wrote, it makes a ton of sense, in fact it's a
dilemma I am facing now. My back-end returns 10 entries (I am limiting
to max 10 matches server side for reasons you can imagine).
As the user keeps typing, should I restrict the existing result set
based on the new information or re-issue a API call to the server?
Things get confusing pretty fast for the user. You don't want too many
cooks in kitchen, I guess.
Played a little bit with both approaches in my little application.
Re-requesting from the server seems to win hands down in my case.
I am sure that them google engineers reached spectacular levels of UI
finesse with stuff like this.
Subject of course to trying this out, I would be inclined to send a much
larger list of responses to the client, and let the client reduce the
number to be displayed. The latency for sending a longer list will be
smaller than establishing a new connection or even reusing an old one to
send a new, short list of responses. When the client types more, it can
only reduce the number of possibilities - among the (possibly imaginary)
larger original number of them. After the next round of user typing, the
client can check and see if there are enough surviving responses to
list. If not, it can then request a new list from the server.
Using this in reverse, if the user deletes some characters from the end,
there should be no need to go back to the server. The possible
responses would already have been sent to the client. They could be
interned in an associative array keyed by the string the client had
typed to get those responses.
--
https://mail.python.org/mailman/listinfo/python-list
