3 ms·

They do that, yet proceed to kneecap the perceived latency by delaying the render. > And on keyUp (the user releases the key), we render the suggestions.

by wky 1mo ago

weird-eye-issue 1mo ago
There are a large number of edge cases where rendering it on key down would not be desirable (user types Ctrl+v, how accented characters are enetered, how some Asian languages get handled, backspace/delete, user holds a key down, etc). This is getting into the point of optimization where it simply does not matter and can actually harm things
- wky 1mo ago
  Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released. Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
  - weird-eye-issue 1mo ago
    Why would you argue that makes more sense? That is not how any autocomplete works that I know of, it's not like this is a new pattern.
    - Dylan16807 1mo ago
      What autocompletes are you testing? I set my repeat delay to be very long so it doesn't interfere with the test, and then went to google and held down some keys for half a second. It types the letter and autocompletes long before I let go. Every UI I can find types the letter on keydown, and I don't know why you'd want typing and autocomplete to use different timings. Waiting for release is for mice and touch, not keyboards. And that's only because they have to deal with dragging.
      - weird-eye-issue 1mo ago
        Your test is flawed, it's triggering keyup if it's showing in the input.
        Dylan16807 1mo ago
        I go to the text box in HN and hold down a key. The letter appears instantly, then after a moment a lot more copies of the same letter start showing up rapid-fire. What are you calling flawed about my test? This happens on both Windows 10 and Linux Mint, in Firefox.
        weird-eye-issue 1mo ago
        Overall the correct event to listen to would be the input even not the keydown event since it handles the edge cases I mentioned earlier I never meant to infer that the keyup event is specifically what should be listened to

They do that, yet proceed to kneecap the perceived latency by delaying the render. > And on keyUp (the user releases the key), we render the suggestions.

by wky 1mo ago

They do that, yet proceed to kneecap the perceived latency by delaying the render. > And on keyUp (the user releases the key), we render the suggestions.

weird-eye-issue 1mo ago

There are a large number of edge cases where rendering it on key down would not be desirable (user types Ctrl+v, how accented characters are enetered, how some Asian languages get handled, backspace/delete, user holds a key down, etc). This is getting into the point of optimization where it simply does not matter and can actually harm things

wky 1mo ago
Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released. Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
- weird-eye-issue 1mo ago
  Why would you argue that makes more sense? That is not how any autocomplete works that I know of, it's not like this is a new pattern.
  - Dylan16807 1mo ago
    What autocompletes are you testing? I set my repeat delay to be very long so it doesn't interfere with the test, and then went to google and held down some keys for half a second. It types the letter and autocompletes long before I let go. Every UI I can find types the letter on keydown, and I don't know why you'd want typing and autocomplete to use different timings. Waiting for release is for mice and touch, not keyboards. And that's only because they have to deal with dragging.
    - weird-eye-issue 1mo ago
      Your test is flawed, it's triggering keyup if it's showing in the input.
      - Dylan16807 1mo ago
        I go to the text box in HN and hold down a key. The letter appears instantly, then after a moment a lot more copies of the same letter start showing up rapid-fire. What are you calling flawed about my test? This happens on both Windows 10 and Linux Mint, in Firefox.
        weird-eye-issue 1mo ago
        Overall the correct event to listen to would be the input even not the keydown event since it handles the edge cases I mentioned earlier I never meant to infer that the keyup event is specifically what should be listened to