Currently it's annoying to "merge" two refs together into one ref attribute. For example, if you want props.ref to be called and to set a local ref variable, you need to do something like this:
<div ref={(r) => props.ref(ref = r)}/>`
This is fairly short but not particularly intuitive or readable. Possible solutions:
We could make ref-1={ref} ref-2={props.ref} work, i.e., ref-NUMBER could work just like ref, but they stack like directives do. (Or perhaps ref:1={ref} ref:2={props.ref}, but see other suggestion for that syntax below.)
We could make ref={[ref, props.ref]} work (Fabio's proposal). Only inline arrays would be supported, just like event handlers already have special meaning for inline arrays.
In either case, we'd end up with a ref function like this (inlined for Element creation as in <div/>):
Sometimes a component wants to expose multiple DOM elements (or other data, e.g. API functionality) to the parent. Currently that needs to be done via callback functions, like so:
Inspired by @fabiospampinato's https://github.com/ryansolid/dom-expressions/issues/96#issuecomment-1179727981, here are some ideas for solving some current issues with
ref
:Multiple
ref
s on a common elementCurrently it's annoying to "merge" two
ref
s together into oneref
attribute. For example, if you wantprops.ref
to be called and to set a localref
variable, you need to do something like this:This is fairly short but not particularly intuitive or readable. Possible solutions:
ref-1={ref} ref-2={props.ref}
work, i.e.,ref-NUMBER
could work just likeref
, but they stack like directives do. (Or perhapsref:1={ref} ref:2={props.ref}
, but see other suggestion for that syntax below.)ref={[ref, props.ref]}
work (Fabio's proposal). Only inline arrays would be supported, just like event handlers already have special meaning for inline arrays.In either case, we'd end up with a
ref
function like this (inlined for Element creation as in<div/>
):Components that want to provide multiple
ref
sSometimes a component wants to expose multiple DOM elements (or other data, e.g. API functionality) to the parent. Currently that needs to be done via callback functions, like so:
Instead, we could imagine a
ref:
prefix that has the same syntactic sugar thatref
does:This would compile to:
So the component could be defined like this:
If
use:___
ends up being syntactic sugar forref
, we could add functionality for multipleref
s with syntax like this: