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

run_on stops routing to #foo after a textbox trigger=True #2216

Open
petergaultney opened this issue Dec 7, 2023 · 1 comment
Open

run_on stops routing to #foo after a textbox trigger=True #2216

petergaultney opened this issue Dec 7, 2023 · 1 comment
Labels
docs Documentation

Comments

@petergaultney
Copy link

petergaultney commented Dec 7, 2023

Wave SDK Version, OS

1.0.0, Mac

Actual behavior

calling await run_on(q) returns False and fails to route if __wave_submission_name__ is not #.

Expected behavior

This is undocumented behavior, and since the examples on https://wave.h2o.ai/docs/routing#hash-route-switching do not suggest that you should not route unconditionally based on the value of q.args['#'], it seems surprising to me that run_on is unwilling to route regardless of the value of __wave_submission_name__.

Further the docs strongly suggest a different behavior when they say "this function will be called when q.args['#'] == 'menu' - this is really not true, because it will only be called if that is true and the submission name is also #.

Steps To Reproduce

Write a simple app where a textbox created when routed to #hello has trigger=True, and expect that to route back to a handler decorated with @on('#hello'). It will only route the first time; after that, it will no longer find that route.

Further context

I'm trying to establish that I can do reasonably performant server-side validation of client input. I love how y'all have implemented debounce for input, for instance, so if I type a whole sentence, it doesn't send any events to the backend until I pause typing.

Once I get that event, and as long as I'm still on the "form-input" route, I want to be able to keep the state of the Submit button either enabled or disabled based on my server-side validation. It seemed like the right way to do this was to keep routing back to the same handler for that form. Apparently, however, that's not really possible with run_on - instead, I have to notice that run_on failed to route, and then do my own routing based on q.args['#'].

In the end, I can probably just build my own version of run_on. But it would be nice to be able to use the official one and just keep handling the same route that I'm already on.

@petergaultney petergaultney added the bug Bug in code label Dec 7, 2023
@mturoci
Copy link
Collaborator

mturoci commented Dec 7, 2023

the docs strongly suggest a different behavior when they say "this function will be called when q.args['#'] == 'menu' - this is really not true, because it will only be called if that is true and the submission name is also #.

This needs correction, yes.run_on handles only the "latest user interaction" so that means if user navigates to #hello, it calls #hello handler. If user fills textbox with trigger=True, it only calls the corresponding textbox handler. This means you either need to split validation into separate @on functions or write your own special routing to match your exact needs.

@mturoci mturoci added docs Documentation and removed bug Bug in code labels Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation
Projects
None yet
Development

No branches or pull requests

2 participants