Compile ref to getter and setter?

[otonashixav]

Doing so would allow props.ref = something to work as if it were props.ref(something), e.g.

let ref;
<Comp ref={ref} />
// currently
createComponent(Counter, {
  ref(r$) {
    const _ref$ = ref;
    typeof _ref$ === "function" ? _ref$(r$) : ref = r$;
  }
})
// proposed
createComponent(Counter, {
  get ref() { return (r$) => this.ref = r$; },
  set ref(r$) {
    const _ref$ = ref;
    typeof _ref$ === "function" ? _ref$(r$) : ref = r$;
  }
})

Not sure if this breaks anything. This would help with typescript (somewhat, types would still be awkward since props.ref can't be different types inside and outside the component to match the compiled output) since currently we have to either typecast or do redundant checks to narrow the ref type to a function, and it also allows setting the ref without checking that the ref actually exists:

function Comp(props: { ref?: HTMLDivElement | ((el: HTMLDivElement) => void) }) {
  let localRef: HTMLDivElement;
  return <div ref={el => { localRef = el; typeof props.ref === "function" && props.ref(el) }} />;
  // with change:
  return <div ref={el => props.ref = localRef = el} />
};

[ryansolid]

This is an interesting idea. I didn't think of it because well writing to props generally isn't good but this an example where that is what you want. Using the getter has the benefit of being able to use the ref locally as well. As in skip even having localRef just read from props.ref.

You could just do this if I'm thinking about this right:

function Comp(props: { ref?: HTMLDivElement }) {
  onMount(() => fn(props.ref));
  return <div ref={props.ref} />
};

I think it is breaking though, because anyone expecting to call it as a function can't. Still I think is probably better in general. I'd love to move this way for 2.0. It won't break the common case so I think that it will be fine to change. But it will drastically simplify the rest.

[otonashixav]

So is it not possible to add the setter while returning a setter function from the getter as suggested above in the meantime? Like I would think that would stop it from breaking current usages, though be very unexpected as props.ref would not contain what you set it to.

[ryansolid]

Oh I missed that. I see.. hmm... That's interesting. So that wouldn't be broken. But only carry half the benefit. The unfortunate part is that assuming we went all the way eventually, end user code would change again.

Benefits of this is the ref is both a function and assignable.

Well actually is what I proposed even feasible. If the user passes a callback we have no way of reading the latest value anyway. And we can't cater to what they pass in since the child needs accept either. So unless we got rid of the callback form there is nothing we could do here.

Hmm... unless we stored a location ourselves. like a props._$ref. Then we could store the value and call any callbacks.

createComponent(Counter, {
  get ref() { return this._$ref },
  set ref(r$) {
    this._$ref = r$;
    const _ref$ = ref;
    typeof _ref$ === "function" ? _ref$(r$) : ref = r$;
  }
})

Code is exploding a bit but I suppose that does the trick.