someRef.current not been "unset"
mcjazzyfunky opened this issue · comments
It's a great feature that uhtml supports React-like ref pseudo properties.
But I think they are not 100% working as expected as the ref is not "unset" by uhtml in case the corresponding element has been unconnected.
Please compare Reacts/Preact/Dyo's behavior (all working exactly the same):
https://codesandbox.io/s/ref-demo-b0kmw?file=/src/index.js
to uhtml's behavior:
https://codesandbox.io/s/ref-demo-forked-33vpl?file=/src/index.js
Nodes that leave the page do not cleanup references, as its the ref that knows the node, not vice-versa, and I have no intention to add live insertion/removal lifecycles to these nodes, as that will kill performance.
The difference here is that uhtml is runtime, it cannot do all optimizations JSX can do and it doesn't use vDOM, so since this use case is not really interesting, as the source of truth there is the state, not the ref, I don't think there's much to do for me.
What you could do if you care, as there are no even leaks as the reference gets updated when the new button is shown, is to use a callback instead, and react with it only when a new button is created.
@mcjazzyfunky btw, interesting project there (a mix between uce and uland) ... mind sharing why you didn't go for uhooks-dom as library? It actually offers elements lifecycle, so that you could use uhooks-fx behind the scene and recreate a similar library that cleans up references when the element disappears, same way it's done to drop effects: https://github.com/WebReflection/uhooks-dom/blob/main/esm/index.js
@WebReflection Thanks for the info about those libraries ... I will definitively have a look at them.
mind sharing why you didn't go for uhooks-dom as library?
Actually, the aim of this js-element R&D project was to evaluate a different approach for hook functions (the whole thing is based on a "factory-pattern" based component function - in the past there has been some discussion about mixing a factory pattern with something similar to React's hook functions, most folks didn't like that approach at all ... but yet nonconformist me tried to noodle around a bit with this approach 😉). That js-element was originally meant to be a tiny web component library without any external runtime dependencies (using a patched version of superfine internally). Having the type-safety of JSX was always a key feature for this js-element library. I've added support for lit-html and uhtml as alternative to JSX/vDOM just a couple of days ago ... not because it is really necessary, but because it's easily doable. I hoped, that lit-html and uhtml based webcomponents could be a bit faster compared to VDOM if there's a lot of partially static content. But as js-element is just a long-term R&D fun project, which is currently not meant to be used productively in near future, this may not matter that much 😄
I hoped, that lit-html and uhtml based webcomponents could be a bit faster compared to VDOM if there's a lot of partially static content.
uhtml is much faster than React in pretty much every benchmark, not sure where this claim comes from 🤔
uce is the library of its kind that scores the best too ... vDOM is slower and heavier on the memory, so I'd be happy to help out improving whatever benchmark you've seen, 'cause my libraries were born to satisfy emerging markets cheap mobile phones (low size, fast perf, low mem).
P.S. VDOM is an abstraction on top of DOM diffing ... it cannot really be faster than DOM itself, as it inevitably needs to apply changes in the DOM too. uhtml might be slower on bootstrap (JIT compiled templates) but when it comes to diffing, if you read that table, you see it's at pair with most other libraries, VDOM based, or not (including svelte). VEry curious to know when you had perf issues with uhtml so, if you have a link, please share, thanks 👋
@WebReflection Oh no, there has been a complete misunderstandig.
Seems that my sentence above was completely ambiguous.
I hoped, that lit-html and uhtml based webcomponents could be a bit faster compared to VDOM if there's a lot of partially static content.
Please let me rephrase this sentence: "I know that lit-html and uhtml based components are faster compared to VDOM, especially if there's a lot of partially static content ... so I gave it a try"
Nobody (that I know of) has ever claimed that vDOM is faster than uhtml (or svelte or solid or whatever).
I've seen uhtml in a webcomponent library called shoemaker the other day and thought "hey, that's awesome", that's why I've started to use it 😉
thanks for clarification and apologies for freaking out on that sentence ... my bad!
shoemaker looks good too, I'm a bit sad it's discontinued ... although uce does most of that out of the box.
btw, to answer the initial question, it's possible with uland to hook yourself into the element lifecycle, if needed:
WebReflection/uland#11 (comment)
but yeah, it doesn't come for free in uhtml