Handle Enter key press in textboxes

[mtanco]

I have found on apps with a text box and button, as a user, I keep hitting enter when I'm done typing. I know text boxes have the option for a time trigger, but this might be more intuitive. Thoughts?

[mturoci]

I am fine with adding enter support via a prop like trigger_on_enter cc @lo5 @geomodular

[lo5]

If the goal is to press the enter key to submit the form, then we should probably do this by default.

Rule can be: if the enter key is pressed when the focus is on a child of a form_card and there is at least one button with primary=True, simulate a click on that button.

The behavior should probably mimic html's type='submit', but not sure what browser quirks exist there or how well it plays with Fluent.

[mturoci]

@lo5 I am not sure this is possible right now, because qd.sync() submits all changes currently (correct me if I am wrong). This means that if user has 2 separate forms, both would be submitted despite the fact you entered just one.

[lo5]

this means that if user has 2 separate forms, both would be submitted despite the fact you entered just one.

Correct. And this is what happens today when you click on a button, so there's no change in current behavior after we introduce the enter-key handling.

[mturoci]

Yes, there is no change in behavior, but the behavior is still incorrect IMO. If it is desired though, what is the reason for:

Rule can be: if the enter key is pressed when the focus is on a child of a form_card and there is at least one button with primary=True, simulate a click on that button.
The behavior should probably mimic html's type='submit', but not sure what browser quirks exist there or how well it plays with Fluent.

There is no point in checking the actual form if it submits everything nonetheless. What about the usecase where you have just a single textbox (no buttons). You should be able to submit it with enter as well I think.

[lo5]

the behavior is still incorrect IMO

The behavior of submitting everything on the page is by design. Maybe you're equating form cards to HTML forms?A form card is simply a stack of components, and has nothing to do with HTML forms. Consider that events can be raised from non-form-cards (e.g. context menus on cards, plot events, etc.)

There is no point in checking the actual form if it submits everything nonetheless.

Consider that the enter key (or any key press/up/down event) might need alternate handling for other kinds of cards that are not form cards.

What about the usecase where you have just a single textbox (no buttons). You should be able to submit it with enter as well I think.

Then there should be no submission, because at that point it's not apparent which command was invoked (there are no buttons on the page).

I am fine with adding enter support via a prop like trigger_on_enter

Submitting page state is a function of the page, not a textbox. Consider that if trigger_on_enter is a property of the textbox, and you have 10 textboxes, you'd have to set that property on every textbox, which makes call sites verbose.

[mturoci]

The behavior of submitting everything on the page is by design. Maybe you're equating form cards to HTML forms?A form card is simply a stack of components, and has nothing to do with HTML forms. Consider that events can be raised from non-form-cards (e.g. context menus on cards, plot events, etc.)

Yes, that's my point. Imagine you type something within app, do not save / submit it just yet. In the meantime, some dialog / notification etc. pops up, you submit an action and accidentally submit all the data you previously filled. Not something I would expect. I am aware of the current submission handling, just sayin I don't consider it correct and we should come up with an idea of scoping it (or something similar).

Consider that the enter key (or any key press/up/down event) might need alternate handling for other kinds of cards that are not form cards.

Don't understand this one. Do we have any card-dependent submission handling? Every component just sets args and optionally calls sync afaik. Not sure what special handling you mean.

Then there should be no submission, because at that point it's not apparent which command was invoked (there are no buttons on the page).

But why? Isn't the main purpose of trigger prop getting rid of submit button and submit the value automatically? In churn app, I have added a filter textbox with trigger and no submit button at all. Not every input element needs accompanying submit button.

Submitting page state is a function of the page, not a textbox. Consider that if trigger_on_enter is a property of the textbox, and you have 10 textboxes, you'd have to set that property on every textbox, which makes call sites verbose.

Don't understand this. How is this prop different from any other textbox prop? You still have to specify your props per component instance.

[lo5]

Isn't the main purpose of trigger prop getting rid of submit button and submit the value automatically?

The usage patterns are different:
The purpose of the trigger property is "sync values whenever a component's value changes" (equivalent to textbox/dropdown onChange).
What this particular issue is asking for is: "sync values only when the enter key is pressed".

For example, if you enabled the former behavior on a login dialog, it would send username/password to the app as you were typing in either username or password.

How is this prop different from any other textbox prop?

Same explanation as above. For example, submitting a username/password combo is not an attribute of either the username textbox or the password textbox.

[geomodular]

I think I can highlight some information here to help with conversation.

The rule:

if the enter key is pressed when the focus is on a child of a form_card and there is at least one button with primary=True, simulate a click on that button.

Is correct, because the button carries name information which will be passed to client along with other changes. Without the name, it would be just qd.sync().

This name is then used in Python if to drive the program execution in desired way. Therefore, it makes sense to tie enter with the primary button for given form_card.

What about the usecase where you have just a single textbox (no buttons). You should be able to submit it with enter as well I think.
Not every input element needs accompanying submit button.

Consider having textbox with no buttons on form card but trigger, the enter action will be the same as trigger action on Python side. User would not be able to distinguish between them.

Yes, that's my point. Imagine you type something within app, do not save / submit it just yet. In the meantime, some dialog / notification etc. pops up, you submit an action and accidentally submit all the data you previously filled.

As stated above, this is by design.

Consider two form_cards simultaneously on page. Both have input boxes and own primary button. User fills the first form but clicks on the primary button of second form. All of the changes will be passed to server. On the python side, however, if will handle the primary button for second form with no values for the second form.

I hope I didn't mess something up. I think, the fact that button has name attribute was overlooked.

[mturoci]

Thanks for joining the discussion @geomodular!

Is correct, because the button carries name information which will be passed to client along with other changes. Without the name, it would be just qd.sync().
This name is then used in Python if to drive the program execution in desired way. Therefore, it makes sense to tie enter with the primary button for given form_card.

Makes perfect sense, I was wrong on this one. The design is correct then. Thanks for discussion and sorry for wasting your time guys.

[johannes-becker-otto]

Hi,
in case this isn't settled yet.
My dream change to textbox would be a enter_name string attribute.

def textbox(name: str, ..., enter_name: Optional[str] = None)

Then I could do

ui.textbox(name="password", ... , enter_name="password_enter")

...

if q.query or q.password_enter:
    # whatever my little heart desires

That would be great.
Cheers
Hannes

[random-developer]

It seems to me that this could be reasonably solved with an event, where:
ui.textbox(name='NAME', ...., enter_event='enter_pressed')
would result in a client-side javascript:wave.emit('NAME', 'enter_pressed', value);
(where value of course is the value of the text box).

[michaeltraxler]

This feature is really needed. Would be great if this is implemented and usable. In the moment, I don't see any action when "Enter" is pressed in a textbox with primary button in the same card.