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
It should be able to recognize real web-component classes as
$('comp-popover').is(Popover)classPopover{}
It should be able to upgrade simple tags too
$('div').is(SuperDiv)classSuperDiv// must be auto-extendedfunctionSuperDiv
Aspect is the same as main component
$el.use(Popover)$el.is(Popover)
Native custom elements mechanism runs custom element constructor automatically whenever new registered component is created, so for our purpose it's enough to define custom tag, and/or (worst-case), provide polyfill.
Possible problem - assigning custom element to a single selector, which broadcasts the registered custom element name:
$('div').is(CustomComponentAspect)
//...then somewhere in html
`<span is=${CustomComponentAspect}></span>`
//... or even - accidental
`<custom-component-aspect></>`
The text was updated successfully, but these errors were encountered:
The .is has problems upgrading existing elements - basically, if existing els weren't created with is attribute (like document.createElement(tag, {is: extraTag})), they're not able to be upgraded safely. Best we can do here to provide safety - assign "fake" aspect, emulating that component, but that's not actual web-component.
We could, technically, create custom elements via .html`<div is=${foo}/>` , but in this case we're blocked by google/incremental-dom#419, we'd have to replace node in notifiers with new element, and bring content from old node, rebind listeners.
That's why for now
Emulate web-components via aspects, upgrade parts that are possible, like direct (not extended) custom element.
Should web-components have their own queue of effects or should they write to main rendering queue?
Calling is instantly in aspect constructor is meaningful for component init, that's weird to have ready element, not initialized as component, that contraversal to DOM custom elements. Same time, initializing unready component directly in HTML can create redundant interference.
Ideally, we'd create thread for each new component with own sandbox, queue.
Logic behind components mechanism.
It should be able to recognize real web-component classes as
Native custom elements mechanism runs custom element constructor automatically whenever new registered component is created, so for our purpose it's enough to define custom tag, and/or (worst-case), provide polyfill.
Possible problem - assigning custom element to a single selector, which broadcasts the registered custom element name:
The text was updated successfully, but these errors were encountered: