fix(calcite-radio-button): fixing issue where input isn't properly initialized in some cases

[eriklharper]

Related Issue: #977

I tested this on a local running instance of arcgis-webviewer-app without the workarounds that @kevindoshier was using as a temporary fix and I could not reproduce the bug, which consisted of unrendered input tags that correspond to each radio the second (and all subsequent) time(s) that the Map properties time slider options panel was opened.

Kevin wasn't able to verify these fixes on his local copy, but despite that these fixes make sense to commit anyway because it makes radio and checkbox more consistent with how all other calcite components create input elements. We'll see once this makes it into a release and the webviewer can update calcite to see if this truly fixes the problem.

[jcfranco]

Is this intentional? Seems like the hidden input will get appended twice if the checkbox is removed and added back.

[eriklharper]

yes this is intentional. When the component disconnects from the DOM, because the input is a child, it also gets destroyed.

[jcfranco]

We already discussed in Teams, but posting for posterity:

it also gets destroyed.

It shouldn't be. You can see this in the following example:

import { Component, Element, h } from "@stencil/core";
@Component({
  tag: "calcite-example",
  shadow: true
})
export class CalciteExample {
  @Element()
  el: HTMLCalciteExampleElement;
  someEl: HTMLElement = null;
  connectedCallback(): void {
    this.someEl = document.createElement("div");
    this.el.appendChild(this.someEl);
  }
}

let example = document.createElement("calcite-example");
setInterval(() => {
  document.body.append(example);
  console.log("current element children", example.children.length);
  example.remove();
}, 1000);

[jcfranco]

Just had a concern regarding the cleanup of the checkbox's internal input. Once this is addressed, this is good to merge!