Radio Button Ignores "defaultChecked" Property on First Render

[sam-hieken]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Home
    Binaries:
      Node: 18.15.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.8-canary.8
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5
    Next.js Config:
      output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

https://github.com/sam-hieken/nextjs-reproduce-radio

To Reproduce

1. Run with npm run dev
2. Navigate to the home page (http://localhost:3000) to observe the issue

Describe the Bug

If a client component contains radio buttons (I have not tried reproducing with checkboxes), the defaultChecked property will be ignored upon the first render.

The radio button still has a checked attribute however; it just won't be filled in upon the first render. On a side note, the result of this is that the :checked pseudo class has no effect on the first render, but using the attribute selector [checked] works as expected.

Expected Behavior

The radio button marked as defaultChecked should display itself as a checked radio button upon the first render of the page.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[brvnonascimento]

Experiencing the same issue here

[brvnonascimento]

This only happens on the dev environment though

[emkr]

Experiencing the same issue here.

[fernandojbf]

Experiencing the same issue here using dev

[gianicolajara]

same here, this happens only in dev mode, in production mode everything is fine

[debel27]

I have the same problem in control mode.

A radio button with the checked attribute does appear checked at first. But shortly after, it gets unchecked.

Interestingly enough, this behavior can be observed in the devtools: the checked attribute happens to change place when the bug occurs.

I though about a hydration issue at first, but this also happens in server components.

[b0hdn4333]

Related issue, contains some temporary workarounds: #49499

[christianjuth]

I opened #49499 . As I mentioned in my issue, none of these workarounds really get at the underling issue. From what I can tell, this bug was introduced 9 months ago in next v13.0.1. I don't understand how something like this could go unnoticed for 9 months since it breaks one of the html primitives in React.

I love all the innovation happening in React right now around server components and app directory, but it's unacceptable imo to introduce bugs like this in the name of new React features. Especially when those bugs go unfixed for 9 months.

So now I'm forced to use next <v13.0.1. However, I've already gone all in on the app directory for a large scale project, and I would really like to get bug fixes for those new features. But I'm worried about the stability of basic react features like this. So I'm left deciding between lagging many Next.js releases behind or updating and hoping I don't run into this issue. Kinda feels like a lose-lose.

[sam-hieken]

@christianjuth Very well said, especially considering how long radio buttons have existed. I really hate critiquing an open source project (especially if I'm not a contributor), but this is a pretty big oversight. HTML semantics / accessibility don't seem to be priorities for Next.

[christianjuth]

@sam-hieken 100% agree. I'm sorry, I also don't want to sound ungrateful. I can't imagine how annoying it is to deal with people complaining as an open source maintainer. I just wish all these features weren't being shipped with such haste. Also a little surprised Next.js doesn't have tests written to check things like radio buttons.

[MwSpaceLLC]

For Info, the bug not present in prod mode, only in dev mode...

possible refresh causes dev stat

[christianjuth]

React team has a fix for this. See my original issue #49499 and Facebook's PRs:

• Update tracked value after resetting radio group facebook/react#27394
• Fix checkbox and radio hydration facebook/react#27401

[sophiebits]

On behalf of the React team, my apologies about this bug. We aspire for React's canary release channel that Next uses to be as bug-free as the versioned releases but clearly did not succeed here. Looking to get a fix merged soon.

[christianjuth]

@sophiebits no worries! Thank you so much for everything you, React, and the Next.js team do to keep our projects running smoothly!

[sam-hieken]

@sophiebits I second that, thanks for all the work you guys do on the best frontend library!

[sophiebits]

Should be fixed in v13.5.6-canary.1 via 0a80017

[alexhollender]

For the past month or so I was no longer experiencing this in dev mode, but now it is happening again (still only in dev mode) 😭

"next": "^13.5.2",
"npm": "^10.1.0",
"react": "18.2.0",
"react-dom": "18.2.0",

[sophiebits]

@alexhollender Please try with Next 13.5.6-canary.1 or newer and if it still happens, file a new issue with a repro case (feel free to CC me).

[alexhollender]

@sophiebits thanks for responding. Apologies for my lack of experience here. I've updated next and eslint-config-next to 13.5.6-canary.1. I am still having the same issue, though perhaps there are other packages I have to update as well.

"eslint-config-next": "^13.5.6-canary.1",
"next": "^13.5.6-canary.1",
"npm": "^10.1.0",
"react": "18.2.0",
"react-dom": "18.2.0",

[cphoover]

So I have to use a canary release in order to use radio groups in next.js??

That's whack... I'm using 13.5.5...

Is there anyway I can monkey patch this so I don't have to upgrade our app to use a canary release?

Some of my peer dependencies aren't compatible with with this canary version, and are yelling on npm i

[sophiebits]

Every change to Next.js (including new React versions) is released first as a canary build then in a stable release shortly after once it has been fully tested in canary. Feel free to wait for the 13.5.6 release. (For comparison, it was about 2 weeks between the 13.5.4 and 13.5.5 releases, though it may be more or less time until the next one.)

[sam-hieken]

Thank you! Can confirm it's working from my end now in next 14.0.1

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.