correct way to jump out event handler

[zillionare]

say, I have a textbox control, and set trigger = True, and contains default value. In such case, when user triggered any events on same page, q.args will always contains this textbox's value and trigger my handler.

Since the page doesn't have to be re-rendered (at lest this handler should NOT respond this time), how to jump out the handler without render page? If I just jump out with return, seems I'll got a spin cursor in the browser.

[mtanco]

Hi @zillionare could you please provide a minimal reproducible example? Thank you!

[zillionare]

Thanks for help me out @mtanco

please refer to above screenshot.

when user press << button, a 'fastbackward' event is triggered, and the q.args is as following:

handling set_frame_type_1d:False, set_frame_type_1w:False, set_frame_type_1M:False, set_frame_type_30m:False, set_frame_type_1m:False, choose_symbol:None, add_favorite:False, favorites:[], set_start:'2021-11-09', set_end:'2022-05-11', fastbackward:True, backward:False, forward:False, fastforward:False, settings:False

Unfortunelately, both set_start, set_end and fastbackward hold values (it's quite normal since set_start is a textbox). The problem is, event handler on_set_start is invoked before fastbackward. Since start is not actually changed, so I do want bypass this eventhandler( and not re-rend the page at the moment), and let on_fastbackward to calc the start/end, and re-render the page.

I can test if start is really change in set_start event handler, if there's no change, I will skip re-rendering the page. However, in function on_set_start, no matter which result (False/True) is returned, seems like no way let on_fastbackward to handle the event.

[zillionare]

or, since the value set_start is not change during button fastbackward is clicked, if there's a way to let q.args contains no set_start, this would help, or the question is, why q.args would contains set_start since it's not changed at the moment? @mtanco

[zillionare]

my suggestion is to rewrite the following code:

async def _invoke_handler(func: Callable, arity: int, q: Q, arg: any):
    if arity == 0:
        await func()
    elif arity == 1:
        await func(q)
    else:
        await func(q, arg)


async def _match_predicate(predicate: Callable, func: Callable, arity: int, q: Q, arg: any) -> bool:
    if predicate:
        if predicate(arg):
            await _invoke_handler(func, arity, q, arg)
            return True
    else:
        if arg:
            await _invoke_handler(func, arity, q, arg)
            return True
    return False

to pass result(True/False) of user's event handler to handle_on, if it's False, means handle_on should search other event handler, else return immediatly. In this way, I can bypass on_set_start if start is not actually changed, thus fast_backward will get its chance to handle the event.

[zillionare]

I've created a PR #1414, trying to fix this.

[lo5]

@zillionare The arg handling works as designed (so we'll probably not merge your PR).

The arg handling checks for presence of args, and calls the corresponding handler.

In your particular case, set_start and set_end are probably set to trigger=True, which I'd argue is an odd UX/design choice.

A better way to handle this is to store the last known values of the start and end textboxes in q.client and then compare the last known values with the current values in both the @on handlers for the start and end textboxes. Then, update the visualization only if you detect a change. This way, you're not relying on the current values of the textboxes, and you're not unnecessarily updating the visualization in either handler.

e.g.

@on(...)
def on_start_date_changed(...):
    if q.client.start_date != q.args.start_date:
        q.client.start_date = q.args.start_date
        update_visualization(q)

def update_visualization(q):
    start_date = q.client.start_date
    end_date = q.client.end_date
    # do something with start/end dates

[zillionare]

@lo5

I've already do the check, and if the value doesn't change, abort update the page. and yes, I do set trigger = True on these two textbox:

@on()
async def set_start(q: Q):
    try:
        start = tf.day_shift(arrow.get(q.args.set_start).date(), 0)
    except Exception as e:
        return False

    if start == q.client.research.start:
        logger.info("start not changed")
        return False

    frame_type = q.client.research.frame_type
    if q.client.research.frame_type in tf.minute_level_frames:
        start = tf.first_min_frame(start, frame_type)

    q.client.research.start = start

    await render_view(q)

the issue is:

1. textbox currently doesn't respond to enter key, so I have to set trigger = True. There's another PR waiting your team to merge, if textbox will respond to enter key, then everything should be OK in this special scenario
2. in my app.py, I have this code:

@app("/", on_startup=on_startup, on_shutdown=on_shutdown)
async def serve(q: Q):
    if not q.client.initialized:
        await on_client_connected(q)
        q.client.initialized = True

    # Handle routing.
    await handle_on(q)

handler_on is a func defined in routing.py, which will go through all registered event handler, and invoke them one by one if match some criteria. The issue in my scenario is, when user clicked on button fast_backward, q.args get both fast_backward and set_start triggered, and on_set_start take first.

No matter what kind of result on_set_start returned, the wrapper (handle_on > _match_predicate) always treat it as true and on_fast_backward will never get called.

The capability to let event handler to decide whether to stop event propagation or not could be a common requirement and it's part of chain of responsibility pattern. And the capability for textbox to handle enter key is also quite common. So, would you please consider again to merge these two changes?

[lo5]

The capability to let event handler to decide whether to stop event propagation or not could be a common requirement and it's part of chain of responsibility pattern.

The @on annotation is not modeled after the CoR pattern, since the common usage in Wave is form/menu click handling from different cards. CoR is more suited for event bubbling (in which case your PR for bubble cancellation makes sense).

I would recommend not using @on/handle_on in your case (it's an opt-in feature any way, not the only way to do things, and not suited for your scenario).

Instead, simply process q.args in serve() (or a function called from serve()), in which case you'll have access to the state of your entire toolbar - from, to, and seek buttons.

e.g.

async def handle_toolbar(q: Q) -> bool:
    # process q.args
   return False # or True if handled.

@app("/", on_startup=on_startup, on_shutdown=on_shutdown)
async def serve(q: Q):
    if not q.client.initialized:
        await on_client_connected(q)
        q.client.initialized = True

   if await handle_toolbar(q):
       return

    # Handle routing.
    await handle_on(q)

If you don't want to do it this way, it's fairly simple to write and use your own @on variant with event bubbling (say, @opt_on) in < 10 lines of code (most of the complexity in routing.py is due to fancy predicate handling, which you don't need here). In fact earlier versions of Wave did not have @on at all for this reason, and early adopters handled q.args in ways that best suited the scenario.

[zillionare]

I've copied routing.py from h2o wave, and add StopPropagation exception handling in handle_on like this:

async def handle_on(q: Q) -> bool:
    """
    Handle the query using a query handler (a function annotated with `@on()`).

    Args:
        q: The query context.

    Returns:
        True if a matching query handler was found and invoked, else False.
    """
    event_sources = expando_to_dict(q.events)
    handled = False
    for event_source in event_sources:
        event = q.events[event_source]
        entries = _event_handlers.get(event_source)
        if entries:
            for entry in entries:
                event_type, predicate, func, arity = entry
                if event_type in event:
                    arg_value = event[event_type]
                    try:
                        logger.info("routing events: %s, %s, %s", event_source, event_type, arg_value)
                        if await _match_predicate(predicate, func, arity, q, arg_value):
                            handled = True
                    except StopPropagation:
                        return True

    args = expando_to_dict(q.args)
    for arg in args:
        arg_value = q.args[arg]
        if arg == '#':
            for rx, conv, func, arity in _path_handlers:
                match = rx.match(arg_value)
                if match:
                    try:
                        params = match.groupdict()
                        for key, value in params.items():
                            params[key] = conv[key].convert(value)
                        
                        logger.info("routing path: %s, %s", arg, arg_value)
                        if len(params):
                            if arity <= 1:
                                await _invoke_handler(func, arity, q, None)
                            else:
                                await func(q, **params)
                        else:
                            await _invoke_handler(func, arity, q, None)
                    except StopPropagation:
                        return True
                    return True
        else:
            entries = _arg_handlers.get(arg)
            if entries:
                for entry in entries:
                    predicate, func, arity = entry
                    try:
                        logger.info("routing arg: %s, %s", arg, arg_value)
                        if await _match_predicate(predicate, func, arity, q, arg_value):
                            handled = True
                    except StopPropagation:
                        return True
    return handled

So if q.args can trigger multiple handler, by default all event handler will be invoked. If by change one of them want to stop the propagation, then it can raise StopPropagation so the rest handler will not be invoked.

I agree h2o wave's focus at this part is to handling form/menu click well, and my scenario may not be common or, not a designed one. Wave is very convenient and promising, I think more and more python developers will find it and embrace it. So please don't lock (sorry I'm not native speaker) its power by disallow user doing common scenarios that b/s arch can do. As javascript developer can do both client/server side job, I guess python developer may feel same, at least I am. @lo5 @mtanco