avoid triggering event after textbox initialized with a user-defined input

[henrycs]

Wave SDK Version, OS

wave 0.22.0, Ubuntu 20.4

Actual behavior

I put a textbox (with value, not empty) in my page, after page initialized, if there is any event triggered, the value of textbox will be added in this event (q.args). since the value of textbox is set by me, so I don't think it's a good idea to trigger this event (no value changes), in some cases, I have to handle this "useless" event.

Expected behavior

no event will be triggered if no value changes of input elements (such as textbox, choice_group, etc.)

Steps To Reproduce

after page initialized, click the button (ButtonA) to trigger an event.
my demo code:

@on("textbox_trigger")
async def on_mytrigger(q: Q):
    print("I'm triggered: ", q.args)
    q.page["demo"].items[1].text.content=q.args.textbox_trigger

@on("generate_event")
async def on_generate_event(q: Q):
    q.page["demo"].items[1].text.content="2"  # just update page

@app('/demo')
async def serve(q: Q):    
    if not q.client.initialized:
        q.client.initialized = True
        q.page['demo'] = ui.form_card(
            box='1 1 4 3', title='Test Page',
            items=[
                ui.textbox(value="wave is great!", name='textbox_trigger'),
                ui.text(content=""),
                ui.button(label="ButtonA", name="generate_event"),
            ]
        )
        
    await handle_on(q)
    await q.page.save()

[aalencar]

Hi @henrycs, could you describe in which cases you have to handle the "useless" event?

[vopani]

This occurs in any case where there are trigger components with set values in a page.

It's quite unintuitive to trigger the event when there is no change in value (and quite annoying to handle as well).

[vopani]

In @henrycs 's example, the button is clicked, but the app runs the textbox trigger. Many apps face similar situations. Extra (redundant) code is required to prevent the textbox trigger (but to run it when textbox is actually edited).

[henrycs]

jsut like vopani said, if we set the initial value of a textbox, after page loaded, we have to process this first useless event.

in my real case, I want to set textbox in other events and show the new value in the page, but current version of wave cannot do this, so I look for the second way, set new value to textbox using q.client.xxx or q.user.xxx, then reload the page, this time I get the expected result, but I have to handle this useless event, I don't know: the value is set by me or edited by user?

@aalencar

[lo5]

This is not a bug. The semantics are not "submit only when values change". By design, all values are sent from the UI to the app.

@on("foo") does not mean "when foo is changed". It means "when foo is found".

See docs.

[vopani]

By design, all values are sent from the UI to the app.

It means "when foo is found".

I thought the same but there is some gap. It might not be a bug but it is difficult to handle easily because of how it's being submitted. Take the example above itself.

After launching the app, when the button is clicked, the set textbox value is submitted even though not edited. Let's say this is fine (because some value is found).
If I click the button again, why doesn't the textbox value be submitted then? (I expect it to because again some value is still found)

• If the expectation is to submit "when foo is found", it should be submitted both times.
• If the expectation is to submit "when foo is changed (from original set value while defining component)", it should not be submitted either time.

It is currently being submitted only the first time, and not the second (which is the root cause of the handling problem).

[mturoci]

Hey @vopani @henrycs. I understand your confusion, let me clarify.

TLDR

#2113 solves your problem (or using if else statements instead)

The long story on why the current behavior makes sense

The reason why the value is submitted when set initially is because that's how forms work on the web in general. Imagine we have a form with 2 textboxes and one button. The first textbox is prefilled, the second is not. The user is expected to fill the second textbox, alter the first one if needed and hit the submit button. Wave submits the "whole" form in this case so that you can process all the data filled. The reason it's confusing when using handle_on is its bad design that depends on the order of q.args which is arbitrary and not guaranteed. This problem is fixed with the new run_on (still working on name) in the PR mentioned in the TLDR.

If the expectation is to submit "when foo is found", it should be submitted both times.

Not really. In our example, the form has already been submitted once so Wave assumes it had been processed already and there is no need to submit it again. Also "found" is meant like found in q.args, not found in the UI.