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's bothered me for a while how .scope returns a new ComponentRef even though it isn't making a new component. This was good enough for the problem at the time, but reflecting now I think $ might be conflating two independent concepts:
Interacting with the component lifecycle - $.lifecycle, $.effect, ...
Interacting with elements - $.query, $.hydrate, $.read, ...
Hypothesis: Decoupling these two concepts would create a more intuitive developer experience.
Consider an alternative:
$ refers to the "component" and its associated functionality.
ElementRef is a new class to encapsulate an element with a hydration-friendly DX.
$.host gives an ElementRef to the host element of a component.
ElementRef.prototype.query performs a query on one element to get another.
With these together we could write an API like this:
const[count,setCount]=$.host.query('span').live();$.host.query('button').listen('click',()=>{setCount(count()+1);});constid=$.host.read(attr('id'),String);constinner=$.host.query('inner-counter').hydrate({ id });
One side benefit to this is being able to reuse .query without repeating that functionality for every method.
ElementRef would need some kind of .native to get a reference to the real underlying DOM node. I'm also a little worried this might be too verbose, but I suspect the intuitiveness improvements might offset that cost.
The text was updated successfully, but these errors were encountered:
It's bothered me for a while how
.scope
returns a newComponentRef
even though it isn't making a new component. This was good enough for the problem at the time, but reflecting now I think$
might be conflating two independent concepts:$.lifecycle
,$.effect
, ...$.query
,$.hydrate
,$.read
, ...Hypothesis: Decoupling these two concepts would create a more intuitive developer experience.
Consider an alternative:
$
refers to the "component" and its associated functionality.ElementRef
is a new class to encapsulate an element with a hydration-friendly DX.$.host
gives anElementRef
to the host element of a component.ElementRef.prototype.query
performs a query on one element to get another.With these together we could write an API like this:
One side benefit to this is being able to reuse
.query
without repeating that functionality for every method.ElementRef
would need some kind of.native
to get a reference to the real underlying DOM node. I'm also a little worried this might be too verbose, but I suspect the intuitiveness improvements might offset that cost.The text was updated successfully, but these errors were encountered: