You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Some suggestions...
Optional?
The
handler
is currently defined withevent=None
. Looking at MDN, I don't believeNone
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 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
Literal
for each possible value. But perhaps we don't want this at all, for the (very rare) case of custom events.The text was updated successfully, but these errors were encountered: