Calcite-components: calcite-radio-button: shows with both buttons unselected

[AdelheidF]

I have a new issue that I'm only seeing with @next. It works fine on devext, it's using beta.40 there. In both cases I use calciteRadioButtonGroupChange.

The first time I open the panel my correct radio button is selected. When I open the panel again, without making any changes, none of the radio buttons is selected.
<calcite-radio-button-group class={CSS.variableFieldRadio} name="variableType" scale="s" afterCreate={(node: HTMLElement) => { node.addEventListener("calciteRadioButtonGroupChange", (event: CustomEvent) => { this.handleTypeChange(event.detail); }); }} > <calcite-radio-button checked={isField} value="field"> {i18n.ui.field} </calcite-radio-button> <calcite-radio-button checked={!isField} value="date"> {i18n.ui.customDate} </calcite-radio-button> </calcite-radio-button-group>

I see this in both places (Age + Rotation) where I use radio buttons.

first time:

second time:

[eriklharper]

It looks like it is still that lingering issue where the component isn't initializing completely the second time around, evidenced by the lack of a calcite-label in the dom.

[AdelheidF]

I had marked this as high, but it didn't make it into Map Viewer Beta 10 tonight.

This workflow is working fine currently on production, but not on devext.

https://www.arcgis.com/apps/mapviewer/index.html?url=https://maps.iema.state.il.us/arcgis/rest/services/NPP/WIND/FeatureServer/1

https://devext.arcgis.com/apps/mapviewer/index.html?url=https://maps.iema.state.il.us/arcgis/rest/services/NPP/WIND/FeatureServer/1

Click on layer on left panel to select it then click Styles tool on right, click on Location tile, click on Rotation section. Notice one radio button is selected. Cancel out of panel and click Location tile and Rotation section again. No radio button is selected and some label styling is gone. If I click on a radio button now it does what it's supposed to do.

I'm OK for now if there is a workaround to this problem.

We definitely need this for beta 11 at the beginning of December.

[AdelheidF]

@eriklharper will this make it for our MVB December release? Or at least I need a work-around, this is broken on production MVB since beta 10. Thanks!

cc @jcfranco

[eriklharper]

I'll prioritize this. It's quite a hard issue to track down and I have not yet determined a root cause. There is another bug I've been diagnosing (#1245) that might be a clue as to what might also be causing this issue, so I'll look at these in tandem.

[AdelheidF]

re-opening. When using the latest 1.0.0-next.50 I have to add <span> around the labels otherwise the radio buttons don't show at all. This is a breaking change for all existing calcite-radio-groups so we better wait for the proper fix.

[eriklharper]

Just verified this bug is fixed without the wrapping <span> on the radio label text with Stencil's 2.4.0-1 pre-release version that includes the fix for the bug we reported to them!

[AdelheidF]

Note: 1.0.0-beta.48 needs the <span> workaround too. Otherwise the radio buttons and labels don't show at all.

[julio8a]

Can we close this or should we wait for next release?

[AdelheidF]

I don't think having to use the <span> is the correct solution.

[eriklharper]

Can we close this or should we wait for next release?

We need to wait until the aforementioned fix in Stencil 2.4.0-1 makes it out of pre-release (Stencil v2.4). Looks like they're currently on 2.4.0-3 pre-release, so hopefully it will make it out soon.

[julio8a]

Great, does this apply to #977?

Do we know a rough timeframe on their end?

[eriklharper]

There is also a new Stencil bug I reproduced and reported that still has yet to get some eyes on it https://github.com/ionic-team/stencil/issues/2801. This bug affects scoped components that use the default <slot /> tag (named slots excepted) like calcite-label, which radio-button uses. It is possible this new Stencil bug does negatively affect the behavior that is the subject of this ticket (haven't taken the time to verify it specifically in light of the discovery).

[eriklharper]

The original bug reported in #977 has definitely been resolved, so I think we can safely close #977 because a new related bug was later discovered after the fix made it in, which is also covered by other bugs like #1121 and #1317.

It is messy I know, but all of these issues stem from Stencil bugs that are failing to properly relocate slotted children in scoped: true components that use the default unnamed <slot /> tag, vis a vis https://github.com/ionic-team/stencil/issues/2801

[julio8a]

Thanks for the update @eriklharper.