@brandondees @RobertChristopher @mrbernnz @robcole @janz93 @btakita @albertoponti After pairing with @lukemelia & @samphippen last night at GORUCO mind was rattling on some refactors for our <infinity-calendar> example.
I don't quite recall the FULL intent. @lukemelia perhaps can shed some light on the dangers of prefixing exotic event handlers with on. This opens the door for the rare chance the platform specs implement (onluke, onfoo etc.) within GlobalEventHandlers
<button onclick=foo>Click Me</button>
<!-- this (NAMING) convention is now deprecated in snuggsi -->
<!-- <button onclick=onfoo>Deprecated</button> -->
Imperative Event Registration
(class extends HTMLElement {
foo () {} // better naming convention (sans `on`)
// this (NAMING) convention is now deprecated in snuggsi
// onfoo () {}
})
However I believe there is one convention we can implement for (nearly) "free". If an event handler is declaratively bound to the HTMLElement (i.e. onclick=onfoo) through GlobalEventHandler.register ()
Then we should bypass this handler on Element.introspect ()ion.
Declarative Event Naming Conventions
<foo-bar> Declarative Event Registration
<button id=baz onclick=onclick>Click Me</button>
</foo-bar>
<script>
Element `foo-bar`
(class extends HTMLElement {
onclick (event) {
// due to the fact there was a declarative event registration `onclick=onclick`
// snuggsi will bypass imperative (automagic) event registration
// of this event handler from being delegated
// to `foo-bar` custom element parent element.
console.log `${event.target} is button#baz`
}
})
</script>
Imperative Event Naming Conventions
<!-- <foo-bar onclick=onclick> -->
<foo-bar> Imperative Event Registration
<button>Click Me</button>
</foo-bar>
<script>
Element `foo-bar`
(class extends HTMLElement {
onclick (event) {
// this.introspect ()
// is called which will auto-register
// methods from this class which align
// with the GlobalEventHandlers.on* events.
// see: https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers
// This event handler delegates
// to `foo-bar` custom element parent element.
// Equivalent to
// this.on ('click', this.onclick)
// Using the snuggsi method `GlobalEventHandlers.on (event, handler)`
console.log `${event.target} is foo-bar`
}
})
</script>
The best part about the code review was the only changes we had to change were our thinking. Not core.
What I DO love @RobertChristopher is our goal of < 100LOC calendar is now at about ~80LOC in .es
and ~30LOC in .html
for a fairly well working calendar.
@brandondees @RobertChristopher @mrbernnz @robcole @janz93 @btakita @albertoponti After pairing with @lukemelia & @samphippen last night at GORUCO mind was rattling on some refactors for our
<infinity-calendar>
example.I don't quite recall the FULL intent. @lukemelia perhaps can shed some light on the dangers of prefixing exotic event handlers with
on
. This opens the door for the rare chance the platform specs implement (onluke
,onfoo
etc.) withinGlobalEventHandlers
Prerequisite
Declarative vs. Imperative Programming
Declarative Event Registration
Imperative Event Registration
However I believe there is one convention we can implement for (nearly) "free". If an event handler is declaratively bound to the
HTMLElement
(i.e.onclick=onfoo
) throughGlobalEventHandler.register ()
Then we should bypass this handler onElement.introspect ()
ion.Declarative Event Naming Conventions
Imperative Event Naming Conventions
The best part about the code review was the only changes we had to change were our thinking. Not core.
What I DO love @RobertChristopher is our goal of < 100LOC calendar is now at about ~80LOC in
.es
and ~30LOC in.html
for a fairly well working calendar.No code, like no code. /cc @tmornini