Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Components mechanism #51

Closed
dy opened this issue Aug 7, 2019 · 2 comments
Closed

Components mechanism #51

dy opened this issue Aug 7, 2019 · 2 comments
Labels
research Decision-making, arguments, discussion, comparison, design

Comments

@dy
Copy link
Owner

dy commented Aug 7, 2019

Logic behind components mechanism.

$el.html`<${Popover}></>`
$el.html`<div is=${Popover}></>`

function Popover($el) {
}
  1. Since hydration is required, it must know how
<comp-popover></comp-popover>
...
$('comp-popover').is(Popover)
  1. Class vs Aspect

It should be able to recognize real web-component classes as

$('comp-popover').is(Popover)

class Popover {}
  1. It should be able to upgrade simple tags too
$('div').is(SuperDiv)
class SuperDiv // must be auto-extended
function SuperDiv
  1. Aspect is the same as main component
$el.use(Popover)
$el.is(Popover)
  1. 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.

  2. 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></>`
@dy
Copy link
Owner Author

dy commented Aug 8, 2019

  1. 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.

@dy
Copy link
Owner Author

dy commented Aug 9, 2019

Should web-components have their own queue of effects or should they write to main rendering queue?

  1. 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.

@dy dy closed this as completed Aug 29, 2019
@dy dy added the research Decision-making, arguments, discussion, comparison, design label Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
research Decision-making, arguments, discussion, comparison, design
Projects
None yet
Development

No branches or pull requests

1 participant