Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#4,008 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
28/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
html, javascript, typescript
領域
frontend, full-stack

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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?

主要言語
TypeScript
スター
36.1k
フォーク
1.1k
平均マージ
10時間 42分
マージ済み PR（30日）
361

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。