Calcite switch

[patrickarlt]

In an attempt to get <calcite-switch> (#24) merged I spent some time this morning to refactor it and open a new PR.

This PR incorporates as much feedback as I could gather from #24 and we can use it as a base for a new review.

[vcolavin]

If the user passes in a checkbox to the slot, how does this behave from an a11y perspective? The rendered DOM would be something like:

<calcite-switch role='checkbox' tabindex='0'>
  <div class='toggle-switch__track toggle-switch__track--blue'}>
    <div class="toggle-switch__handle" />
   </div>
  <input type='checkbox' />
<calcite-switch/>

Which semantically has a checkbox input inside of a checkbox input.

We may need additional logic in setupProxyInput like ionic uses in its renderHiddenInput helper to ensure there's always one "real" hidden checkbox.

[patrickarlt]

The input passed into the <slot> is hidden by https://github.com/ArcGIS/calcite-components/pull/33/files#diff-ef2ae6405313ac1fd653283d6be2050aR1 so it won't appear in the accessibility tree.

[patrickarlt]

We may need additional logic in setupProxyInput like ionic uses in its renderHiddenInput helper to ensure there's always one "real" hidden checkbox.

Thinking about this we probably do.

[patrickarlt]

This would probaly make sure stuff like this worked:

<label>
  Clicking the label should toggle the switch
  <calcite-switch checked></calcite-switch>
</label>

[kumarGayu]

both the blocks are similar, and are we not supporting this focus and active?

[patrickarlt]

If the switch is contained within a <label> and the switch is clicked there are actually 2 click events fired. 1 on the checkbox and one on the switch. If there is no passed input there is only 1 click event fired. I might be able to resolve this be adding a default checkbox like Ionic https://github.com/ArcGIS/calcite-components/pull/33/files/128c553fdb5ce060eab1b62a429270819e73e4d6#r290499524

[kumarGayu]

@patrickarlt thanks for getting us this demo component. 👍 Looks good but we need some extra functionalities as well.

[patrickarlt]

@kumarGayu @vcolavin I've added some more code to this. In cases where a user does not pass an input a hidden <input type="checkbox"> is created for them so we can still maintain interactions with <form> and <label> this also means adding a name and value prop to <calcite-switch> that get synced down the input.

I do feel like this needs a disabled state now...

[kumarGayu]

this.name = this.inputProxy.name this.value = this.inputProxy.value isn't it required? for syncing up to calcite-switch, I feel both of calcite-switch and input have sync'ed values.

[patrickarlt]

@kumarGayu My is that <calcite-switch> should support all the basic checkbox properties. So value, disabled, switched (syncs with checked) and name. Syncing name and value down from <calcite-switch> isn't strictly required but it makes everything show up nice when you do things like:

<form>
  <calcite-switch name="enableThing" value="true"></calcite-switch>
</form>

Will cause the form to submit with enableThing=true and for a enableThing input to appear in form.elements.

[kumarGayu]

Sure make sense 👍

[kumarGayu]

I feel we have to document this way of sending <input /> as child Appropriately with a mention all the properties should send to children <input /> than <calcite-switch />

This works fine

<calcite-switch>
  <input id="proxySwitchCheckbox" type="checkbox" checked/> // as checked is in side
</calcite-switch>

** this may not work correct me if I miss something **

<calcite-switch id="basicSwitch" switched="true">
   <input id="proxySwitchCheckbox" type="checkbox" />// input is not checked even though switched = true
</calcite-switch>