Text input example drops keys

[joshalbrecht]

If you type quickly in the Text Input example on the API Reference page, you can see that it drops some characters. This makes it almost completely unusable in practice.

[claytonaalves]

Yes, I can confirm that. I've got the same behavior here.

Works ok if you type slowly thou.

[falkoschindler]

You are right, typing in a text input can drop keys.

It actually happens because every value change is sent to the server where the event is processed and the new value is sent back to the client. I implemented this roundtrip because Quasar's QToggle simply wouldn't change its state when clicking on it even though the event was sent to the server. Somehow I had to send the updated value back to the client for it to move.

While this technique might be needed for some elements for whatever reason, it might not be necessary for others. Apparently we don't need to send the new value for a QInput. So I'll introduce an option in NiceGUI's ValueElement base class so that ui.toggle can behave differently than ui.input in this regard. This will hopefully avoid dropping keys while typing.

[falkoschindler]

I checked the behavior for all elements deriving from ValueElement with the following code:

with ui.row():
    ui.checkbox('Checkbox')
    ui.switch('Switch')
with ui.row():
    ui.radio(['A', 'B', 'C'])
    ui.select(['A', 'B', 'C'])
    ui.toggle(['A', 'B', 'C'])
with ui.row():
    ui.input('Input')
    ui.number('Number')
    ui.color_input('Color input')
with ui.row():
    with ui.menu() as menu:
        ui.menu_item('Ok')
    ui.button('Menu', on_click=menu.open)
    with ui.dialog() as dialog:
        ui.button('Ok', on_click=dialog.close)
    ui.button('Dialog', on_click=dialog.open)
with ui.row().classes('w-96'):
    lp = ui.linear_progress()
    cp = ui.circular_progress()
    ui.slider(min=0, max=1, step=0.1).bind_value_to(lp, 'value').bind_value_to(cp, 'value')
with ui.row():
    ui.date()
    ui.time()

I tried it once with sending changed values back to the client and once without.
To detect problems caused by the roundtrip, I simulated a slow connection using the Chrome developer tools.

• All input elements involving typing (ui.input, ui.number, and ui.color_input) show flickering and lost characters. When disabling the roundtrip, the flickering is gone but they get cleared when loosing focus. So we probably need to set their state sometime, maybe on change but with some throttling.
• The minute finger of the ui.time element flickers when being dragged around quickly. In contrast to the three aforementioned input elements, it isn't cleared after loosing focus.
• All other elements don't show any flickering or lost values. However, they don't work at all if changed values are not sent back to them.

So I guess we should treat ui.input, ui.number, ui.color_input, and ui.time differently then the other value elements by updating the frontend later or less frequently. But I'm not sure about the details.

[falkoschindler]

Updating on blur doesn't work well. When throttling the network connection, delayed messages from the server are messing up the user experience.

[FI-Mihej]

Hello! I've made a fix for this issue. Please review: #306

[falkoschindler]

Based on @FI-Mihej's PR (see discussion over at #306) I came up with a solution that might be the essence of #306 without introducing too much change of behavior and/or API: https://github.com/zauberzeug/nicegui/tree/no_loopback_for_input

The key changes are as follows:

• Value elements have a static parameter LOOPBACK set to True by default.
• ui.input, ui.number, and ui.color_input overwrite LOOPBACK with False.
• On a value change event the server won't send an update message if loopback is false.
• On a update:model-value event the client will set the model-value directly if loopback is false.

The last point was the missing piece: The client needs to listen to the change event and set the value directly. Otherwise the element would need to wait for a server response.

What do you think?

[kepler]

This issue is also biting us quite hard: when using ui.input with props=textarea, the caret jumps to the end of the box when typing mildly fast. So any quick fix is very welcome.

[rodja]

Hopefully we will merge #306 today. v1.1.5 will be released tomorrow at the latest.

[rodja]

Some last minute tests before the release uncovered major drawbacks with the new implementation. We hope to find a solution as soon as possible. Sorry for the delay.

[falkoschindler]

I pushed a possible fix to https://github.com/zauberzeug/nicegui/tree/loopback.
Needs review and thorough testing.

[falkoschindler]

The fix from 061b388 is working nicely.

[rodja]

v1.1.5 has just been released.