Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#4,008 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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
平均合并
11 小时 49 分钟
30 天内合并 PR
346

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

solidjs/solid 的其他 Issue

查看 solidjs/solid 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。