Bug: react's rendering is breaking radio group state

[yannikmesserli]

When the re-rendering of a CalciteRadioGroup is delayed to update the checked value, it leaves the underlying calcite component in a double checked state:

Repro sample

This does not happen in blank calcite, check this out.

[benelan]

This is a known issue described in the Frameworks Gotcha's section:
https://developers.arcgis.com/calcite-design-system/frameworks/#boolean-attributes

Here is a working version of your sample
https://codesandbox.io/s/ccr-boolean-gotcha-0464ie

Closing this issue, but if you have further questions feel free to continue the discussion

[yannikmesserli]

Hi @benelan, thanks for the reply. I can still see the described bug in your " working version". If you click once on "Apple" and then, after it re-renders, back on "Orange", you can still see both checkbox being checked at once.

[benelan]

The delay was due to the setTimeout you had in the codesandbox. I removed it from mine, are you still seeing an issue?

[benelan]

Oh okay I see what you mean now. What is the use case for delaying the responsiveness of the UI? It looks like React's synthetic events are behaving differently

[yannikmesserli]

Ok, I see, I wasn't clear enough about the encountered bug. The bug I am reporting here is that the component, when clicked, turns his UI to the "checked" mode without respecting the actual "checked" property (or its absence). So, you end up with BOTH items being checked in the example:

Since this is not happening in plain calcite, this is probably due to the react rendering setting the checked value onclick.

[benelan]

Yeah now I see the difference you're talking about. But what is the use case for adding the delay? React's rendering or synthetic events may execute in a different order, but without the delay the difference isn't noticable.

[yannikmesserli]

But what is the use case for adding the delay?

In our app, the delay is caused by posting to the server and waiting for the result. Here, I am just adding the timeout to exhibit the bug.

[benelan]

Why do you need to interact with the server to change the radio group UI state? In general creating UI lag isn't the best approach for indicating that something needs to load. Could the the radio group state change without delay, and then if the app needs something from a server it could display a loader or progress bar until it gets a response?

I'll reopen the issue and investigate after the v1 release because I can reproduce. But I think there can be some UI optimization in the app as well. Thanks for reporting by the way, and sorry for closing so quickly. We get a lot of issues/questions posted due to the Gotcha I linked, and I jumped the gun a bit because it looked similar.

[eriklharper]

This seems to happen with React 18 using createRoot to render the app instead of ReactDOM.render(). Seems to work fine on React < 18 or when using React 18 with ReactDOM to render the app.