Some suggestions...
Optional?
The handler is currently defined with event=None. Looking at MDN, I don't believe None should be allowed. It appears the decorator has no real effect if event is None.
event -> trigger
Calling it event is going to make it seem like an instance of Event. HTMX uses htmx-trigger="click". Perhaps we could use trigger.
Positional vs. Keyword
I suggest the first argument (event type) is positional, everything else is keyword. The current zen of Python might be moving towards all-keyword.
Tooling-friendly contraint on event type
It sucks when you slightly misspell an event name. On the HTML/JS side, tools will warn you. Would be nice on the Python side.
We could do an Enum. I think Brett Cannon did a Twitter poll, not sure if people liked that.
We could instead do it on the type hinting side, with a union of Literal for each possible value. But perhaps we don't want this at all, for the (very rare) case of custom events.
Some suggestions...
Optional?
The
handleris currently defined withevent=None. Looking at MDN, I don't believeNoneshould be allowed. It appears the decorator has no real effect if event is None.event->triggerCalling it
eventis going to make it seem like an instance ofEvent. HTMX useshtmx-trigger="click". Perhaps we could usetrigger.Positional vs. Keyword
I suggest the first argument (event type) is positional, everything else is keyword. The current zen of Python might be moving towards all-keyword.
Tooling-friendly contraint on event type
It sucks when you slightly misspell an event name. On the HTML/JS side, tools will warn you. Would be nice on the Python side.
We could do an
Enum. I think Brett Cannon did a Twitter poll, not sure if people liked that.We could instead do it on the type hinting side, with a union of
Literalfor each possible value. But perhaps we don't want this at all, for the (very rare) case of custom events.