Dropdown value setting

[ShehanIshanka]

When a value is set to the dropdown component, it would cause to trigger the dropdown. How can we bypass this?

As an example, in the following code if I click the button it won't execute code related to the button handling event. It executes the dropdown handling event code section.

from h2o_wave import app, main, Q, ui, handle_on, on


@app("/")
async def serve(q: Q) -> None:
    if not await handle_on(q):
        await setup_page(q)

    print(f"ARGS : {q.args}")
    await q.page.save()


@on()
async def dropdown(q: Q):
    print("dropdown is triggered")


@on()
async def button(q: Q):
    print("button is triggered")


async def setup_page(q: Q):
    q.page['example'] = ui.form_card(box='1 1 2 2', items=[
        ui.dropdown(name='dropdown', label='Dropdown', value="choice1", choices=[
            ui.choice(name='choice1', label='Choice 1'),
            ui.choice(name='choice2', label='Choice 2'),
            ui.choice(name='choice3', label='Choice 3'),
        ]),
        ui.button("button", "button")
    ])

Screen.Recording.2022-06-04.at.00.14.52.mov

[vopani]

A button will submit all component values in a page. You need to track the value of the dropdown to handle what function you'd like to run.

Similar to #680 and #820

eg:

from h2o_wave import app, main, Q, ui, handle_on, on, copy_expando


@app("/")
async def serve(q: Q) -> None:
    if q.args.dropdown is not None and q.args.dropdown != q.client.dropdown:
        await dropdown(q)

    elif not await handle_on(q):
        await setup_page(q)

    print(f"ARGS : {q.args}")
    await q.page.save()


async def dropdown(q: Q):
    print("dropdown is triggered")
    copy_expando(q.args, q.client)


@on()
async def button(q: Q):
    print("button is triggered")


async def setup_page(q: Q):
    q.page['example'] = ui.form_card(box='1 1 2 2', items=[
        ui.dropdown(name='dropdown', label='Dropdown', value="choice1", choices=[
            ui.choice(name='choice1', label='Choice 1'),
            ui.choice(name='choice2', label='Choice 2'),
            ui.choice(name='choice3', label='Choice 3'),
        ]),
        ui.button("button", "button")
    ])
    q.client.dropdown = 'choice1'

[Far0n]

My 2 cents: In my opinion that's a major flaw regarding how the on-decorator and handle_on work. The latter invokes only the first matched handler and which one that will be depends on the order in which the components are defined. So the following would always print "button is triggered":

async def setup_page(q: Q):
    q.page['example'] = ui.form_card(box='1 1 2 2', items=[
        ui.button("button", "button"),
        ui.dropdown(name='dropdown', label='Dropdown', value="choice1", choices=[
            ui.choice(name='choice1', label='Choice 1'),
            ui.choice(name='choice2', label='Choice 2'),
            ui.choice(name='choice3', label='Choice 3'),
        ]),
    ])

That's super error prone if we don't restrict the use of "on" to buttons only (what @vopani's solution kinda implies).

As soon as we use trigger=True somewhere is becomes even worse, because there is no way to identify the source of the submit that easily. @vopani's solution works, but personally I find that these required if-elif checks in serve undermine the usefulness of "on" (the purpose of it is to get rid of if-elif blocks in the first place).

What I find useful is to exploit the fact, that there is always only 1 source of a submit:

• an event (from wave_emit)
• a button click
• a trigger = True event

For example, sorting button handlers to front of q.args would improve the handling and and allows to keep serve "clean".

from h2o_wave import app, main, Q, ui, handle_on, on

button_click_handlers = set()

def button_handler(func):
    button_click_handlers.add(func.__name__)
    @wraps(func)
    def wrapper(*args, **kwargs):
        func(*args, **kwargs)
    return wrapper

async def my_handle_on(q: Q):
    """put button_click_handlers to front of q.args"""
    args_keys = set(q.args.__kv.keys())
    args_keys = list(button_click_handlers & args_keys) + list(args_keys ^ button_click_handlers)
    button_args_first = {k : q.args[k] for k in args_keys}
    q.args.__kv.clear()
    q.args.__kv.update(button_args_first)
    return await handle_on(q)

@app("/")
async def serve(q: Q) -> None:
    await my_handle_on(q)
    await setup_page(q)

    print(f"ARGS : {q.args}")
    await q.page.save()

@button_handler
@on()
async def button(q: Q):
    q.client.triggered = "button"

@on()
async def dropdown(q: Q):
    q.client.triggered = f"drowdown: {q.args.dropdown}"
    q.client.choice = q.args.dropdown

async def setup_page(q: Q):

    q.page['example'] = ui.form_card(box='1 1 2 2', items=[
        ui.dropdown(name='dropdown', trigger=True, label='Dropdown', value=q.client.choice or "choice1", choices=[
            ui.choice(name='choice1', label='Choice 1'),
            ui.choice(name='choice2', label='Choice 2'),
            ui.choice(name='choice3', label='Choice 3'),
        ]),
        ui.button("button", "button"),
        ui.text(q.client.triggered or "")
    ])

with @button_handler:
https://user-images.githubusercontent.com/6949295/172024959-656236e0-2272-450c-b720-e2a54dc6dd37.mp4

without:
https://user-images.githubusercontent.com/6949295/172024967-3554772c-948e-43da-9b44-f37f758ed544.mp4

[vopani]

+1
I've struggled to get an intuitive workflow as well.

@Far0n I've seen your custom handle_on implementation before too and I certainly find that one of the better / cleaner solutions. Would be useful to have this somewhere in docs or example apps so that it can be referred easier.

Thanks for sharing again!

[lo5]

This is a very useful discussion - thanks for participating!

Event-handling and callbacks almost always get gnarly, no matter what - age-old problem in computing :)

This is why Wave didn't originally ship with a event/callback mechanism, and got added later because we were getting asked for a recommendation for organizing code (as opposed to a solution to a some other kind of problem). Therefore, @on/handle_on mechanism is opt-in only, and not a necessity.

The @on/handle_on is more of a general-purpose technique (tries hard to be one-size-fits-all). The implementation is very short (https://github.com/h2oai/wave/blob/master/py/h2o_wave/routing.py), and one can just as easily write a custom mechanism like that and not use the built-in @on/handle_on at all. There is a related discussion here as well.

I suspect the main reason why this gets gnarly is that @on functions are global-to-app, not local-to-page or local-to-scenario like you'd typically do in front-end programming. In other words, in front-end programming, button-clicks, dropdown-changes, etc. typically are handled within the context of a form or page (via a closure or class), which lets the front-end programmer store additional state/variables that track what specifically happened within the context of that page. Since there's no concept of multiple pages in Wave (there is only an "active page", this kind of state-tracking ends up being done inside q.client if you use @on/handle_on. Again, I'm over-exaggerating the "problem" here, and this may not be an issue that Wave app authors struggle with in a majority of situations.

Personally, I wouldn't use @on/handle_on in my apps - it's a lot easier for me to reason about application state without them, because with @on/handle_on the application logic ends up being scattered across different event-handling functions, as opposed to being able to read all the logic in one place inside a single function. The single function might jump into other smaller functions, but the important thing is that I'm in control of the logic, not obscured behind handle_on(), and I can decide how to handle q.args based on the situation at hand :)

I'm open to adding additional, alternate mechanisms to Wave, i.e. we could ship @Far0n's implementation with Wave, which can be imported as, say from h2o_wave.far0n_routing import on, handle_on.

My main hesitation with changing the behavior of the current @on/handle_on is that a lot of apps rely on the way it works today, and I don't hear strong opposition to it (maybe this discussion is?) and don't want to break the world.

[lo5]

My 2 cents: In my opinion that's a major flaw regarding how the on-decorator and handle_on work. The latter invokes only the first matched handler and which one that will be depends on the order in which the components are defined. So the following would always print "button is triggered":

This is not entirely correct. The order of handlers matter, the order of components don't.

Observe:

from h2o_wave import app, main, Q, ui, handle_on, on


@app("/")
async def serve(q: Q) -> None:
    if not await handle_on(q):
        await setup_page(q)
    await q.page.save()

@on()
async def dropdown(q: Q):
    show(q, [ui.text(f"dropdown triggered: {q.args}")])

@on()
async def button(q: Q):
    show(q, [ui.text(f"button triggered: {q.args}")])

async def setup_page(q: Q):
    show(q, [
        ui.dropdown(name='dropdown', label='Dropdown', value="choice1", trigger=True, choices=[
            ui.choice(name='choice1', label='Choice 1'),
            ui.choice(name='choice2', label='Choice 2'),
            ui.choice(name='choice3', label='Choice 3'),
        ]),
        ui.button("button", "button"),
    ])

def show(q, items):
    q.page['example'] = ui.form_card(box='1 1 2 2', items=items)

Clicking on the button produces:

dropdown triggered: dropdown:‘choice1’, button:True

Changing the dropdown produces:

dropdown triggered: dropdown:‘choice3’, button:False

Next, put the button before the dropdown:

async def setup_page(q: Q):
    show(q, [
        ui.button("button", "button"),
        ui.dropdown(name='dropdown', label='Dropdown', value="choice1", trigger=True, choices=[
            ui.choice(name='choice1', label='Choice 1'),
            ui.choice(name='choice2', label='Choice 2'),
            ui.choice(name='choice3', label='Choice 3'),
        ]),
    ])

Clicking on the button produces:

button triggered: button:True, dropdown:‘choice1’

Changing the dropdown produces:

dropdown triggered: button:False, dropdown:‘choice3’

So, changing the order of components did not change the behavior.

[Far0n]

@IO5 I'm not sure if sort_args would impvove much. You pointed out below that using on for something like dropdown is pointless, because its not a "on_change" semantic and I don't see a big practical diff between component definition order and lexicographical order of components-names (that's what I assume sort_args would imply)
However, what I think would be useful is the following: Prioritize handler for buttons and nav "on-clicks" over trigger=True submits.

[vopani]

I'm not convinced about the usefulness of sort_args. But let me experiment a bit and get back.

Some other points:

• It's fair that the @on handlers are opt-in (and not required to write an app). But it's nice and useful for pretty code. Worth trying to get it to work better. I see most apps (and app developers using it, so there must be something good about it) 🙂

• This example app is a particular case (the min-repro is too simple an example). This change / suggestion needs to be tested on some of the existing apps to see how they react to it and whether it is beneficial. Maybe enable the sorting args proposition in a branch to try out (if it's a simple code update)?

• @Far0n 's solution works really well, but again would need those additional bits of code in each app. Of course getting that snippet integrated in Wave is helpful but if we could approach to solve this in a simpler way (maybe we're all missing something trivial), that'd be ideal.

[Far0n]

@vopani I think you are right and here is my take on it: People facing issues, because they want to on-decorate handler for trigger=True events of components like a dropdown. But since q.args always holds the content of the dropdown the corresponding handler is always a candidate to be invoked by handle_on and this now "competes" with a button:True in q.args.

If I'm not mistaken sort_args wouldn't solve that, because that would still only work if all button names are lexicographical smaller than the ones of any component with Trigger=True.

Hence, I believe handle_on should always look for button/navigation "clicks" first and only then looks for other handlers. That works because contrary to trigger=True components the q.args for button/nav clicks are only truthy if a click actually happened.

[Far0n]

btw. toggles would still remain troublesome, because they have boolean values and a trigger event might give us toggle: False in q.args. Since that's not truthy handle_on wont invoke the handler for a True -> False switch (trigger = True).
So one actually needs to do @on("toggle", lambda x:True) to even have a chance to make it work.

Code_B9HpcaWUDu.mp4

The only thing that worked for me is to replace on with my own set of decorators, namely: on_click, on_change, on_event and on_path + corresponding handle_on replacements. From video above:

@app("/")
async def serve(q: Q) -> None:
    if q.client.toggle_01 is None:
        q.client.toggle_01 = False
    if q.client.toggle_02 is None:
        q.client.toggle_02 = False

    await handle_changes(q, compared_to=q.client)

    print(f"q.args : {q.args}")
    print(f"on_change.handlers: {on_change.handlers}")
    await setup_page(q)
    await q.page.save()

@on_change("toggle_{id}")
async def toggle_handler(q: Q, val, id):
    print(f"toggle_{id} changed, new val: {val}")
    q.client[f"toggle_{id}"] = val

async def setup_page(q: Q):

    q.page["example"] = ui.form_card(
        box="1 1 2 2",
        items=[
            ui.toggle(name="toggle_01", value=q.client.toggle_01, trigger=True),
            ui.toggle(name="toggle_02", value=q.client.toggle_02, trigger=True),
        ],
    )

[lo5]

Yeah agree. The "on changed" (expected) vs "on found" (actual) needs clarification in the docs.

With the addition of the .trigger event (@Far0n's suggestion), we can update the docs to show how to handle triggered events the right way (i.e. rely on the event, not the presence of an arg). That should address any future confusion.

[lo5]

Here's how I'd write the same example, without @on/handle_on.

from h2o_wave import app, main, Q, ui, handle_on, on


@app("/")
async def serve(q: Q) -> None:
    if not q.client.initialized:
        await setup_page(q)
        q.client.initialized = True 
    else:
        q.client.choice = q.args.dropdown
        show(q, [ui.text(f"You chose {q.client.choice}.")])
    await q.page.save()


async def setup_page(q: Q):
    q.client.choice = 'choice1'
    show(q, [
        ui.dropdown(name='dropdown', label='Dropdown', value=q.client.choice, trigger=True, choices=[
            ui.choice(name='choice1', label='Choice 1'),
            ui.choice(name='choice2', label='Choice 2'),
            ui.choice(name='choice3', label='Choice 3'),
        ]),
        ui.button("button", "button"),
    ])

def show(q, items):
    q.page['example'] = ui.form_card(box='1 1 2 2', items=items

To me, this is clearer and shorter, since any time trigger=True is used, I can blindly set q.client.x = q.args.x and always refer to q.client.x from that point on. Don't have to deal with questions like ":thinking: has the dropdown changed or not?"

[Far0n]

Yeah, that's indeed much cleaner. To be clear where I'm coming from: Personally I'm not a big fan of long if-elif constructs and more complex wave apps tend to have hundreds of loc's of these in a single function. But I know this is very debatable: :)
What I like about the decorator solution is the ability to put other decos like @log or @trace on top of it and overall it's more pleasing to my eyes (guess I just don't like (the look of) if-elif statements in python :D)

[lo5]

Yes, I'm not a fan of if-elif constructs either - I wish Python had a switches or pattern-matching ;-)

That said, I wasn't hinting at having hundreds of lines in a single function. The single function can just contain the overarching control flow, and call N other smaller functions, keeping itself small. In any case that's what handle_on() is doing, a sort of inversion-of-control / Hollywood principle thingy :-)

[lo5]

This was a useful discussion (and we found a subtle bug along the way). Here's a summary:

What confused me was that trigger=True was thrown into the mix, and when I re-read the original question, there is no Trigger=True involved :-)

To @ShehanIshanka's original question:

When a value is set to the dropdown component, it would cause to trigger the dropdown. How can we bypass this?

As explained here, @on('foo') (or @on() applied to a function foo()) must be read as "if q.args contains foo", not as "if q.args.foo changed". In your case q.args contained dropdown, and there was a function defined with @on('dropdown'), so it got invoked.

That said, what caused the confusion was that you had two handlers defined, one for the dropdown and one for the button, and in Wave, you'll never run into the situation where either q.args.dropdown or q.args.button is available. They will both always be available, regardless of whether the button was clicked or the dropdown was changed. So i'd say in your case, don't define the dropdown() function at all - it has no purpose.

[Far0n]

What confused me was that trigger=True was thrown into the mix, and when I re-read the original question, there is no Trigger=True involved :-)

I think that's on if the main sources of issues people running into with on. I believe it's quite natural to try something like:

@on("textbox") # trigger=True
def textbox_triggered(q: Q, value): 
  validate_input(value)

So reacting to certain app state changes instead of copy_expando => process app state as holistic entity.

[ShehanIshanka]

Thank you very much @vopani @Far0n and @lo5 for your responses. In my case, the code is organized with @on() handlers so that we could separate handlers' functionality in a nice way. Also if I use if-elif, then it also messes with the code structure. Further, I can't get rid of dropdown function, since dropdown component has a triggger=True. So all in all, I need to have a dropdown fucntion with @on().

Based on the responses, I did something like this and it worked. But the problem is if you have several other components in your view, you need to handle them.

@on()
async def dropdown(q: Q):
    if q.args.dropdown is not None and q.args.dropdown != q.client.dropdown:
        print("dropdown is triggered")
    elif q.args.button:
         await button(q)

Also, I feel from #1484, this problem would be solved as the component which is lastly interacted, will be prioritized from it.

[lo5]

I can't get rid of dropdown function, since dropdown component has a triggger=True.

It's not clear to me what you're trying to do.

Just for my understanding, why do you want to know that the "dropdown has changed", as opposed to simply knowing the value of the dropdown?

Front-end programmers typically handle change events to know when to read the latest value of the field. But Wave does that for you, and frees you from that detail - you unconditionally get the latest value.

[ShehanIshanka]

Actually, I want to know "dropdown has changed" as I have to update UI(Update a placeholder in a text field) based on the dropdown values. That's why.

[Far0n]

I actually believe this would be very useful: #1484 (comment)

TLDR: Imagine having not just wave.emit events in q.events, but all clicks and triggers, like so:

Example q.events and q.args after a toggle was clicked (with trigger=True):

q.events = {"toggle.triggered": True} # toggle was defined with trigger=True and has been clicked
q.args = {"toggle" : False} # new value of toggle

=>

@on("toggle.triggered")
def toggle_handler(q: Q):
    ...

I think that would work just fine, because afaik there would always at max 1 element in q.events.

[lo5]

I really like this. Let me think about it a bit further, but so far it feels like the right solution. Thanks @Far0n!