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); });
const id = $.host.read(attr('id'), String);
const inner = $.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.
It's bothered me for a while how
.scopereturns a newComponentRefeven 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.ElementRefis a new class to encapsulate an element with a hydration-friendly DX.$.hostgives anElementRefto the host element of a component.ElementRef.prototype.queryperforms 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
.querywithout repeating that functionality for every method.ElementRefwould need some kind of.nativeto 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.