Textarea with static value-property does not set its value.

[bigmistqke]

Describe the bug

When setting the value of a textarea with a static string, it does not set the property, while if you set the value while calling a function it does get set.

function Counter() {
  const [signal] = createSignal("dynamic");
  return (
    <>
      {/* Does not set value */}
      <textarea
        value="static"
        ref={(element) => {
          console.log("1 static:", element.value);
          queueMicrotask(() => console.log("2 static:", element.value));
        }}
      />
      {/* Sets value */}
      <textarea
        value={signal()}
        ref={(element) => {
          console.log("1 dynamic:", element.value);
          queueMicrotask(() => console.log("2 dynamic:", element.value));
        }}
      />
      {/* Sets value too */}
      <textarea
        value={(() => "iife")()}
        ref={(element) => {
          console.log("1 iife:", element.value);
          queueMicrotask(() => console.log("2 iife:", element.value));
        }}
      />
    </>
  );
}

Your Example Website or App

https://playground.solidjs.com/anonymous/54d80eb1-0ae9-4016-8300-e8f058f975d9

Steps to Reproduce the Bug or Issue

<textarea value="static" />

Expected behavior

The value of the textarea to be "static", but instead it is "".

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

No response

[danieltroger]

Why not just do <textarea>static</textarea>?

[bigmistqke]

@danieltroger that is a good temporary solution, but preferably textarea.value would work with static values too, since it is a bit counterintuitive that it does not work + in case of props you can't know if it will be static or not and then (props) => <textarea value={props.value}>{props.value}</textarea> becomes a bit much.

[mdynnl]

this is one of those cases where attribute/property distinction causing different behaviors. textarea does not have value attribute unlike other form elements but does have value property and that's exactly what the playground uncovers. the solution/workaround is to either force prop:value or put it in children as daniel suggested.

[bigmistqke]

@mdynnl o that's interesting! i was not expecting that to be the cause. attribute/property is so messy...