Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[2.0 rc.14 / next] Nullish checkbox and radio values submit an empty string on the client

Chiusa
  • Qualcosa non va?
#4,008 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
28/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
html, javascript, typescript
Ambito
frontend, full-stack

Direzione di ricerca

Start with packages/web/src/client.ts, where the issue identifies setProperty and the spread assignment path that normalize nullish values for inputs. Review the regression reproduction and tests mentioned in the proposed PR; verify checked checkbox and radio inputs submit "on" for nullish values while explicit empty strings and text fields retain their stated behavior. The report notes that Babel and native compiler paths remain a separate scope, so clarify which paths the contribution should cover.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Describe the bug

The client runtime writes value="" when a checkbox or radio receives a nullish value. A checked input then submits "" instead of the native default "on". Clearing defaultValue has the same effect because it reflects the value attribute.

This is reproducible on next at 84dada774d35ff79256e24b5e2feadea4b1dec22. Both setProperty and the spread assignment path in packages/web/src/client.ts use value ?? "" for every input type.

Your Example Website or App

The reproduction is included in the steps below.

Steps to Reproduce the Bug or Issue
import { render, spread } from "@solidjs/web";

const form = document.createElement("form");
document.body.appendChild(form);

render(() => {
  const input = document.createElement("input");
  spread(input, {
    type: "checkbox",
    name: "choice",
    checked: true,
    value: undefined
  });
  return input;
}, form);

console.log(new FormData(form).get("choice")); // "", expected "on"

spread is the same runtime path that a JSX spread like <input type="checkbox" checked {...props} /> goes through.

  1. Run the example in a client-rendered page, without hydration.
  2. Inspect the submitted value and the input's value attribute. Both are empty strings.
  3. Replace checkbox with radio, or undefined with null, to see the same result. Removing a previously defined value key from a reactive spread also writes an empty value.
Expected behavior

A nullish value should remove the value attribute so a checked checkbox or radio submits "on". An explicit value="" should still submit an empty string. Text inputs and textareas should keep clearing to "" for nullish values.

The HTML Standard's default/on mode returns "on" when the attribute is absent; assigning the property writes the attribute.

Screenshots or Videos

Not applicable; the difference is visible in FormData.

Platform
  • Solid: @solidjs/web 2.0.0-rc.14, next at the commit above.
  • Local reproduction: macOS 27.0.1, Node 24.21.0, jsdom 25.0.1.
  • Browser: not tested; reproduced in jsdom.
Additional context

The nullish normalization addressed text fields in #2957. This case needs to retain the distinction between an absent attribute and an explicitly empty one.

I'd like to remove the attribute for nullish value and defaultValue on checkbox/radio inputs in the two runtime paths. The type check would run only for a nullish input value. I opened a PR with that patch and regression tests.

The non-hydratable inline paths still need a separate change: Babel's DOM assignment and the native compiler's DOM assignment emit el.value = v ?? "". The proposed runtime patch leaves those packages unchanged. When rendered on the client, <input type="checkbox" name="choice" checked value={v()} /> with a nullish v() would submit "on" in a hydratable build, which calls setProperty, but still submit "" in a non-hydratable build.

The check uses the input's current type. On a new input, assign(input, { defaultValue: null, type: "checkbox" }, true, {}) still creates an empty value attribute; reversing those keys removes it. Radio inputs have the same limitation. Handling that order is outside this patch.

Submit and reset inputs also receive value="" from this normalization. Under the button label rules, an empty attribute produces an empty label instead of the browser's default label. They are outside this checkbox/radio proposal and could be handled separately.

Would you take the runtime change on its own, or prefer to align the inline compiler paths in the same contribution?

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
11h 32m
PR unite (30g)
356

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solidjs/solid

Tutte le issue di solidjs/solid

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.