Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐞 fix: use return value of event handler to decide if dispatching sho… #1414

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

zillionare
Copy link

…uld stop

if there's multiple controls in the view, when it's triggered, some textbox may contain value will be treated as True, thus trigger event handler accordingly. These value may not be changed at the moment, thus event handler should just ignore it by return False, however, routing.py currently lack the mech to leverage the return value, and search next event handler.

please refer to #1404 for more details

…uld stop

if there's multiple controls in the view, when it's triggered, some textbox may contain value will be treated as True, thus trigger event handler accordingly. These value may not be changed at the moment, thus event handler should just ignore it by return False, however, routing.py currently lack the mech to leverage the return value, and search next event handler.
@Far0n
Copy link

Far0n commented May 30, 2022

I also find the current behavior a bit inconvenient, because of the Trigger=True side effects (see also: #952).

This PR here by @zillionare looks similar to one of my workarounds, but I have propagation as opt-in rather than opt-out:

async def _match_predicate(predicate: Callable, func: Callable, arity: int, q: Q, arg: any) -> bool:
    if predicate:
        if predicate(arg):
            res = await _invoke_handler(func, arity, q, arg, **params)
            return True and res is not False
    else:
        if arg:
            res = await _invoke_handler(func, arity, q, arg, **params)
            return True and res is not False
    return False

Wouldn't that be okay @lo5? That doesn't change behavior of any current code, but would open a litte backdoor to allow invokation of more than one @on-matched handler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants