wave: "handle_on" depends on order of components in a form (it should not)

@lo5 wouldn’t the following be an option: I believe currently q.events is only used for wave.emit() stuff. What if it would always hold the “source event” that led to invoking serve?

For example: Let’s say we have an ui.toggle with trigger = True and we “click” it. Let’s further assume the value changes from True to False. That would result in:

q.events = {"toggle.triggered": True}
q.args = {"toggle" : False}

That would enable a quite convenient usecase for @on in my opinion:

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

edit: I also think button clicks should find their way into q.events, like so:

q.events = {"button.clicked": True}
q.args = {"button" : True}

For sake of backwards compatibility we can’t remove it from q.args. So the redundancy could be an argument against it. But I feel one could still argue, that q.events holds the implicit “trigger = True” for the button and q.args it’s value. So non-clicks could still be this, I guess:

q.events = {}
q.args = {"button" : False}

I currently expose the name of the cause in q.args['__wave_submission_name__']. It’s prefixed with __ to mark it as “do not touch unless you know what you are doing”. I suppose that should be enough?

But seems like the answer is no its whole purpose is to identify the serve invocation cause.

Yes, that’s what I believe to remember at least 😄 (back when I thought about it … so take it with a grain of salt ^^)

edit: so yeah I think these 2 things: a) root cause b) solution for the “is not truthy” issue with current (handle_on, @on). And a proper solution to a) should also solve b) I guess.