SolidJS•3mo ago

solid/reactivity with component ref

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)

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

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

17 Replies

zulu•3mo ago

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

SilenZOP•3mo ago

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

zulu•3mo ago

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 ref as a prop name has no special meaning the ref only has special meaning when used on an element

SilenZOP•3mo ago

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?

zulu•3mo ago

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

zulu•3mo ago

or this

zulu•3mo ago

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

SilenZOP•3mo ago

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} />

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} />

let componentRef!: ComponentRef;

return <Component ref={componentRef} />

works but Typescript complains, unless I cast.

zulu•3mo ago

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 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.

SilenZOP•3mo ago

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

zulu•3mo ago

I guess that will simplify things

SilenZOP•3mo ago

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

GitHub

eslint-plugin-solid/packages/eslint-plugin-solid/docs/reactivity.md...

Solid-specific linting rules for ESLint. Contribute to solidjs-community/eslint-plugin-solid development by creating an account on GitHub.

zulu•3mo ago

I use setter function most of the times 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.

SilenZOP•3mo ago

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

GitHub

solid/reactivity with custom component ref · Issue #187 · solidjs...

I tried using ref with custom component based on this example: solidjs/solid#564 (reply in thread) and it triggers solid/reactivity warning: https://playground.solidjs.com/anonymous/b30f1656-5be1-4...

zulu•3mo ago

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

mdynnl•3mo ago

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

zulu•3mo ago

found the docs too https://docs.solidjs.com/concepts/refs#forwarding-refs

Refs - Solid Docs

Documentation for SolidJS, the signals-powered UI framework

Gaming

Programming

solid/reactivity with component ref

Did you find this page helpful?