to clarify, I am not stating this works now, I am just wondering why shouldn't it as I see it pretty natural to write and deal with

truth to be told, async listeners are a feature and a curse ... if you expect, as example, event.preventDefault() to happen after anything asynchronous that'd be too late for the DOM to deal with your intention ... it's a long standing thing on the Web that only recently received enough attention but I am afraid there's no ETA around when, or if ever, that would land.

truth to be told, async listeners are a feature and a curse ... if you expect, as example, event.preventDefault() to happen after anything asynchronous that'd be too late for the DOM to deal with your intention ... it's a long standing thing on the Web that only recently received enough attention but I am afraid there's no ETA around when, or if ever, that would land.

I already thought of the preventDefault() use case. Unfortunately, an async @ when might not be able to cleanly prevent the default from happening (because I assume the default could possibly happen before the async function is run). Unless you maybe add a "preventDefault" flag to the argument list for @ when().

Still, allowing us to use @ when on async functions seems like a neat idea.

why not?

Because normally you can't use await from within a non-async function. I do not think a top-level await changes this rule.

def non_async():
  await some_coroutine()

Would still raise an error I'd think.

I am not sure I am following ... I am talking about:

@when("click", "#my_button")
async def click(event):
  print(event.type)
  # await something(...)

I am not talking about:

async @when("click", "#my_button")
def click(event):
  print(event.type)
  # await something(...)

and I don't even know if that's a thing (it shouldn't?) ... so, in the first case, if we are aligned, the only difference is that the decorator adds an async function as listener, which is well allowed on the DOM and quite common these days.

In that regard, I don't see why it shouldn't be possible ... if it doesn't work already, it's about wrapping a task into a JS friendly async function, and that should be relatively trivial.

Unless you maybe add a "preventDefault" flag to the argument list for @ when().

That's the solution already in our stack: if you add an invoke field to the extra 3rd argument of addEventListener you can pass a string or an array of strings such as ['preventDefault', 'stopPropagation'] and both methods will be automatically invoked on the event side synchronously, whenever that happens ... a similar mechanism could be used for @when also because @when doesn't accept the 3rd argument which is indeed very helpful for some listener or behavior, most relevant being: { "once": True } when it comes to automatic removal of the event once it happens.

As you can see there is room for improvements, and adding both a 3rd argument + handling async tasks out of the box, seem to be a good improvement to me, not sure what others think though.

So if adding the third argument is as simple as... Just using the third argument that addEventListener already has... All that's left is to wrap the coroutine in a function that returns something that javascript recognizes as a Promise-like object, no? Either that, or wrap it in a function that invokes asyncio.create_task(). That might be easier?

P.S. there is also a difference with Pyodide VS MicroPython as latest doesn't have any signature introspection so maybe the gotcha was in the interpreter? I'll try to figure out but I'd love to know if you tried and failed with both Pyodide and MicroPython, thanks.

My entire application will break if I use mpy, so I haven't.

then I think this dance is overkill and not producing the desired outcome ... the MicroPython callback seems to indeed not suffer the mentioned issue: https://github.com/pyscript/pyscript/blob/main/pyscript.core/src/stdlib/pyscript/event_handling.py#L39-L61 ... maybe I can just use MicroPython code in there and call it a day ...

aha ... fixed in here, it's all good to me there and the fix easy enough ... the MicroPython thing is different and it resolves anyway, I had to manually check for a coroutine and resolve accordingly: #2158

Even though the nature of the problem I ran into was entirely different from what I initially assumed it was, I'm glad that me bringing this up has resulted in something.