[2.0.0-rc6] Variable ref inside a ref array is never assigned

[Azravos]

Describe the bug

Doesn't work at all, elementRef never becomes assigned. But this is fully allowed by the type system and compiles

const MyComp = () =>
{
    let elementRef: HTMLDivElement | undefined
    
    return (
       <div ref={[
           elementRef
        ]}>
       </div>
    )
}

Works as intended

const MyComp = () =>
{
    let elementRef: HTMLDivElement | undefined
    
    return (
       <div ref={[
           el => elementRef = el
        ]}>
       </div>
    )
}

So I'm guessing either this is a bug or it simply shouldn't compile if it's not meant to be supported.

Your Example Website or App

See description

Steps to Reproduce the Bug or Issue

Just put a ref variable inside the ref array like ref={[myRef]} and it will never be assigned.

Expected behavior

Either a compile error if this isn't intended or the ref element to be successfully assigned

Screenshots or Videos

No response

Platform

• OS: [Windows]
• Browser: Chrome
• Version: [152]

Additional context

No response

[javascript-unsafe]

Reproduced with solid-js@2.0.0-rc.6, vite-plugin-solid@3.0.0-next.27, Vitest + jsdom:

let el;
render(() => <div ref={[el]} />, document.body);
console.log(el); // undefined

The callback form works:

render(() => <div ref={[(node) => (el = node)]} />, document.body);

Root cause: ref={el} is compiled into an assignment callback, but ref={[el]} passed the array through unchanged. The runtime only calls array entries; el evaluates to undefined and is skipped, so it is never assigned.

The fix is compiler-side: convert bare mutable variables and member expressions inside ref arrays into assignment callbacks. PR: #3288.

[ryansolid]

Thanks for the clear report — this is by design, and the docs didn't say so plainly. Fixed that.

ref={el} on a bare variable is a compile-time rewrite of the single ref value: the compiler sees the binding and emits "call it if it's a function, otherwise assign the element to it." Ref arrays are a different thing — a composition list of callbacks. At runtime the array is flattened and each entry is called with the element (applyRef in @solidjs/web). A bare let el inside evaluates to undefined at mount, so it's skipped, and nothing assigns it.

We considered extending the rewrite into array literals (#3288) and decided against it. Arrays don't have to be inlined — const refs = [el]; <div ref={refs} /> is the same type and the compiler can't see inside it — so a literal-only rewrite would make the same code behave differently depending on whether you inlined the array. The type can't close the gap either: Ref<T> has to admit T so callers can write <Child ref={el} />, and the same type is what the child forwards with ref={[props.ref, …]}, so excluding T from array elements would break the forwarding pattern that arrays exist for.

So the rule is: array entries are callbacks. Use ref={[node => (el = node), other]}, or keep the bare variable in the single form ref={el}. documentation/solid-2.0/07-dom.md now states this explicitly. A "bare let inside a ref array" check is a good fit for eslint-plugin-solid, which already has the scope analysis — worth a request there.

— Claude via Cursor