Proper handling of trigger=True "events"

[Far0n]

Given the following app:

@app("/")
async def serve(q: Q):
    print("args", q.args)
    
    if not q.client.initialized:
        q.page['meta'] = ui.meta_card(box='')
        q.client.initialized = True
        q.client.textbox1 = q.client.textbox2 = ""
        await q.page.save()
    
    await handle_on(q)  
        
    q.page['main'] = ui.form_card(
        box='4 2 3 3',
        title='',
        items=[
            ui.textbox(name="textbox1", label="textbox 1", trigger=True, value=q.client.textbox1 or ""),
            ui.textbox(name="textbox2", label="textbox 2", trigger=True, value=q.client.textbox2 or ""),
            ui.text(content=q.client.changed_text or ""),
        ],
    )              
    await q.page.save()
    
# @on("textbox1") # won't trigger when textbox is cleared, because "" is not truthy
@on("textbox1", lambda x: x is not None)
async def ontextbox1(q: Q):
    print("textbox1 changed")
    if q.client.textbox1 != q.args.textbox1:
        q.client.changed_text = f"textbox1 value changed from {q.client.textbox1} to {q.args.textbox1}"
    q.client.textbox1 = q.args.textbox1
    
    # without the following 'ontextbox2' would never be called 
    q.args.textbox1 = None
    await handle_on(q)

            
@on("textbox2", lambda x: x is not None)
async def ontextbox2(q: Q):
    print("textbox2 changed")
    if q.client.textbox2 != q.args.textbox2:
        q.client.changed_text = f"textbox2 value changed from {q.client.textbox2} to {q.args.textbox2}"
    q.client.textbox2 = q.args.textbox2
    q.args.textbox2 = None
    await handle_on(q)

1. handle_on(q) seems only to invoke the first function for which a predicate is true. So without the await handle_on(q) propagation ontextbox2 would never be called, because "textbox1", lambda x: x is not None is always true. What is the correct use of handle_on here ('cause above feels not right to me)?
2. Is there a better way to detect which component actually triggered the event? Doesn't look like anything goes into q.events and the only way to identify the source is to check for changes like q.client.textbox1 != q.args.textbox1. What am I missing?

[lo5]

The on/handle_on duo is merely a syntactic sugar for multiple if/elif.../else that one would normally do inside serve(), so the behavior where handle_on() calls exactly one handler is intentional. Explained here: https://wave.h2o.ai/docs/routing#reducing-boilerplate

The trigger simply means "submit everything when this field changes", and not "submit this field when it changes". Wave apps generally handle all available fields in aggregate, and not individually as in a traditional event-handling / callback style programming.

I'm curious why you'd want to know which textbox triggered it. I can suggest alternatives if I can understand your situation better.

[Far0n]

I'm curious why you'd want to know which textbox triggered it. I can suggest alternatives if I can understand your situation better.

Simply to know what caused the submit. Like in the example above: In order to find the proper value for changed_text I basically need to iterate over all UI components to detect where the text change happened. I thought it might simplify implementation of certain logics if we knew the source and type (trigger, button click, navigation click, text link etc.) by just looking into q.events or something.

[Far0n]

@IO5 Maybe to elaborate a bit more: Like you said handle_on is syntactic sugar for if/elif.../else. There are two issues I see with that:

1. The order in which we define our @on-decorated functions matter if used as shown in the docs. Same as with if/elif.../else, but there it is just "natural" and the code is in one place. For our functions not so much. So if we @on-decorate a function, we need to care about if there is no other @on-decorated function somwhere "above" that might "steal" the caller.
2. Because trigger events don't populate q.events we need to use a q.args predicate to trigger an event handling. Because of 1) we need to define these @on-"callbacks" prior to all other @on-decorated functions to make sure its called every time the trigger caused a submit. Very easy to mess this up, esp. when we carry over our expecations on how event handlers work in other environments.

There are even broken examples right now, kinda proofing the point that it is very easy to mess things up when relying on well-ordered if/elif.../else statements.

[lo5]

I understand what you're saying, but again, the @on mechanism is nothing like traditional event handlers, on purpose.

Traditional event handlers / callbacks are necessary when components raise more than one event (e.g. component changed, clicked, double-clicked, hovered, etc.). We don't have such scenarios in Wave: every component on the page accounts for the most-common-case event - either input some data, or issue some command.

The programming paradigm to use is: the request contains the current state of the UI, and the response needs to return the entire new state. It's very rare that you'll need to accept a partial state and update a card partially.

we need to care about if there is no other @on-decorated function somwhere "above" that might "steal" the caller.

But that would be a logic bug. The @on handler tests are mutually exclusive conditionals, per the docs.

Because trigger events don't populate q.events we need to use a q.args predicate to trigger an event handling.

The form submissions caused by trigger=true are not treated as events tied to the component that caused the submission. They are meant to be used as substitutes for buttons (e.g. change values in dropdown2 when dropdown1 changes, without having to click a button).

we need to define these @on-"callbacks" prior to all other @on-decorated functions to make sure its called every time the trigger caused a submit. Very easy to mess this up, esp. when we carry over our expecations on how event handlers work in other environments.

I don't see how this is different from traditional event handling, where observers, subscribers, handlers, or callbacks are invoked in order of subscription, FIFO.

There are even broken examples right now

I don't see the relation. They are related to overly clever location-hash related coding that broke when #769 was addressed. The examples relied on the non-existence of a parameter instead of relying on the value.

It would be good if I could stare at an example (code) that demonstrates what's problematic (or not possible) to achieve, and specifically why it's necessary to know what caused the submission. Maybe I can suggest alternatives, or make improvements to Wave.

[Far0n]

The programming paradigm to use is: the request contains the current state of the UI, and the response needs to return the entire new state. It's very rare that you'll need to accept a partial state and update a card partially.
The form submissions caused by trigger=true are not treated as events tied to the component that caused the submission. They are meant to be used as substitutes for buttons (e.g. change values in dropdown2 when dropdown1 changes, without having to click a button).

Ye, maybe it's more an issue mith my mental model overall. Or in other words: A case of RTFM! :)

I don't see how this is different from traditional event handling, where observers, subscribers, handlers, or callbacks are invoked in order of subscription, FIFO.

That's basically what you said above "The form submissions caused by trigger=true are not treated as events tied to the component that caused the submission" .. and I was expecting the opposite, i.e. that @on handlers for trigger=True events are always called, no matter what.

I don't see how this is different from traditional event handling, where observers, subscribers, handlers, or callbacks are invoked in order of subscription, FIFO.

I was referring to the behavior of the trigger=True events like in the example below. My uninformed expectation was, that it would behave similar to something like on_click=.... That is, that the event handler gets always called on this event (or at least there is some way to control the event flow to ensure that). It seems, that it is not possible to mimic that by just using @on without extra logic.

Here is an example app that is based on the ill-formed mental model about how things work regarding the @on handlers:

tabs = [
    ui.tab(name='#email', label='Mail', icon='Mail'),
    ui.tab(name='#events', label='Events', icon='Calendar'),
]

@app('/')
async def serve(q: Q):
    print("q.args", q.args)
    
    if not q.client.initialized:      
        q.client.text = ""
        if not q.client.menu:
            q.client.menu = "#email"
        q.client.initialized = True

    await handle_on(q)
    q.page['example'] = ui.form_card(box='1 1 4 10', items=[
        ui.tabs(name='menu', value=q.client.menu , items=tabs),
        ui.textbox(name="textbox1", label="textbox1", trigger=True, value=q.client.textbox1 or ""),
        ui.textbox(name="textbox2", label="textbox2", trigger=True, value=q.client.textbox2 or ""),
    ])    
    await q.page.save()

@on('#email')
async def on_email(q):
    print("on_email")
    q.client.menu = "#email"

@on('#events')
async def on_events(q):
    print("on_events")
    q.client.menu = "#events"

@on('textbox1')
async def on_textbox(q):
    print("on_textbox1")
    q.client.textbox1 = q.args.textbox1

@on('textbox2')
async def on_textbox(q):
    print("on_textbox2")    
    q.client.textbox2 = q.args.textbox2

dBTXbaWzXw.mp4

[Far0n]

related: #952