solid/reactivity with component ref

[charred patrol]

Hi. I enabled the solid eslint plugin and going through warnings I came across this case:
https://playground.solidjs.com/anonymous/b30f1656-5be1-4dd2-9d22-11cbf4067c6b

Warning is this:

The reactive variable 'props.ref' should be used within JSX, a tracked scope (like createEffect), or inside an event handler function, or else changes will be ignored.
eslint(solid/reactivity)

Is this a false positive?

Or am I using component ref incorrectly? I couldn't find any documentation except this GH discussion:
https://github.com/solidjs/solid/discussions/564#discussioncomment-4594092

[forest jewel]

you will get this for any property of the props you access

[charred patrol]

I get that, but shouldn't props.ref be special cased or something?

[forest jewel]

the main reason for this warning is

"or else changes will be ignored"

this is mostly used as a heads up for developers to know that you are calling it in
a non tracked scope

[forest jewel]

ref as a prop name has no special meaning

the ref only has special meaning when used on an element

[charred patrol]

And do you think there is any problem with using ref like this? Can I just use //eslint-disable-next-line and be done with it?

[forest jewel]

actually I was wrong a bit, but it is unrelated to your issue.
ref on Component is kind of broken.

first: yes, I think you can ignore this warning.
the rule is if your prop does not have "reactivity" you can ignore that warning

[forest jewel]

or this

it does have a minor overhead , but it is more explicit

[charred patrol]

Broken in what sense?

I hit an issue with typescript types, where it's better for the ref to always be a function like this:

const [componentRef, setComponentRef] = createSignal(null)

return <Component ref={setComponentRef} />

otherwise I won't be able to call it in Component to assign it

let componentRef!: ComponentRef;

return <Component ref={componentRef} />

works but Typescript complains, unless I cast.

[forest jewel]

broken in the sense of my initial "assumption"
that it has no special meaning when used on a Component
and only has special meaning for html element.

so I assumed that
<Component ref={variable}/>
or
<Component ref={"some value"}/>
will be just passed as value
but in reality it only pass function an ignore the variable or the string

[forest jewel]

so you basically pass a setter function to the component
this sort of make sense, because Components are functions
you can't really get a reference to them.

[charred patrol]

from what I understood in #next thats going to be the only way to do refs in 2.0 anyway

[forest jewel]

I guess that will simplify things

[charred patrol]

Also do you think its worthwhile adding this as exception to solid/reactivity rule? It already has exceptions for these cases:
https://github.com/solidjs-community/eslint-plugin-solid/blob/main/packages/eslint-plugin-solid/docs/reactivity.md#initializing-state-from-props

https://github.com/solidjs-community/eslint-plugin-solid/blob/main/packages/eslint-plugin-solid/docs/reactivity.md#static-props

[forest jewel]

I use setter function most of the times

[forest jewel]

for now only function are transferable, but a function might have reactivity and someone might use that function not as a ref setter and hit what the rules was meant to warn about.

[charred patrol]

I also asked this on the eslint plugin GH https://github.com/solidjs-community/eslint-plugin-solid/issues/187

[forest jewel]

I think ref is actually "reserved" for components too
due to special handling being applied for variable or a function
and the fact that it ignore other values like "string"

but technically any function passed from parent might have reactivity
which you can track. so the rule is correct to warn.

but may be noise as most usage expect a setter without any getter associated to it

so I am now 50%/50% on changing the ref eslint rule

[ripe siren]

Yes, ref is reserved.

when used in native element, it's compiled to call the variable as a functionif it is with untrack otherwise assign it if the expression is assignable just after the element is created

for component, it's also compiled similarly but without the untrack (should be though), and it's up to the component to call props.ref function however it sees fit
simply props.ref({}) top level is also correct

for general users, this might suffice and I might already be leaking too much implementation details rather than user expectation