Props as direct effects about spect

[dy]

Imagine some plugin interferes with effect name. Having prop accidentally overlap with effect would set that plugin. If plugin was enabled somewhere up dep chain, the user code can unexpectedly create collision, hard to debug.

But logically effects are on the same level as props <div html=${} foo bar=baz/>.

That's a bit weird though - <div use=${( $el => $el.css )} css=${123} /> - is $el.css prop here or effect? Seems that we have to display warning in case of collision.

Some external plugin cannot break code - but it can create errors for some existing code. Not really good.

[dy]

Some attrs are linked to props already, href for example, and back.
Therefore $a.attr.href === $a.prop.href.

If we provide direct props as $el.someProp - should that forward all other props like $el.innerHTML? That is more serious threat to namespace conflict. Also that contaminates the whole props concept - exposing meaningful wrappers to main domains.

Can we subset exposed props via html? <a is=${NavA} href=/ foo=bar />? So only props rendered via html are exposed, or set directly on element $a.foo = 'bar'. But should that then be reflected on DOM elements? $a.foo = 'bar' - that's unexpected to assign that to all underneath elements. $a.prop.foo = 'bar' is ok.

But

$a.html`<${NavLink} foo=bar route=/ ></>`

function NavLink({prop: {foo, route}}) {
// isn't 100% elegant
}

Should custom element function be a special aspect, receiving not wrapped element, but props?
No, because aspects may need to receive props as well.

Although, mb exposing domains like that is actually useful.

function SomeComponent ({ data: {foo, bar}, attr: {href}, prop: {route}, css: { width }}) {}
// vs
function SomeComponent ({ foo, bar, href, route, widht }) {}

it makes clear which domain a prop has come from.

Ok, sufficient proof for

Use domain-namespaced props, not direct props - that's easier to implement, less conflicts and more apparent to users.