Switch component for charting basic component #24

kumarGayu · 2019-05-24T17:56:40Z

Added Calcite-Switch component as per #3

and as per design
https://esri.github.io/calcite-web/documentation/components/#switches

driskull

Looks good :)

driskull · 2019-05-24T18:01:51Z

src/components/calcite-switch/calcite-switch.tsx

+export class CalciteSwitch {
+  @Prop() checked = false;
+
+  @Prop() text = "";


maybe set to null by default?

for string empty makes sense than null so thought of initializing it to truthy empty value. But I am okay to change others also thinks that should be null

driskull · 2019-05-24T18:02:54Z

src/components/calcite-switch/calcite-switch.tsx

+    return (
+      <label class="toggle-switch">
+        {this.position === "right" && (
+          <span class="toggle-switch-label">{this.text}</span>


Maybe something for a larger discussion, but it would be nice to follow BEM naming for css classes. So this would be toggle-switch__label

driskull · 2019-05-24T18:03:23Z

src/components/calcite-switch/calcite-switch.tsx

+  @Event() switchChange: EventEmitter;
+
+  render() {
+    const checkedClass = this.switched ? "toggle-switch-input--checked" : "";


almost BEM naming :) toggle-switch__input--checked

driskull · 2019-05-24T18:03:48Z

src/components/calcite-switch/calcite-switch.tsx

+
+  toggle() {
+    this.switched = !this.switched;
+    console.log(this.switchChange);


remove console.log

Sorry I will remove it,

driskull · 2019-05-24T18:04:30Z

src/components/calcite-switch/calcite-switch.tsx

+          class={`toggle-switch-track toggle-switch-track--${this.position}`}
+        />
+        {this.position === "left" && (
+          <span class="toggle-switch-label">{this.text}</span>


would also be nice to have an CSS map object at the top of the file where all classnames are stored .

In this repository I have not seen that pattern so did not follow it :(

kumarGayu · 2019-05-24T19:49:48Z

If we decide to follow BEM, I can follow for this component as well.

macandcheese · 2019-05-24T20:43:18Z

Thanks for submitting! We'd like to preserve the "destructive" style for actions that we want to caution users about. The styles should be there already, perhaps just a "destructive" prop that can be passed to the switch?

patrickarlt · 2019-05-24T21:00:46Z

Thinking about how the integrates with browsers and frameworks a little more I did some digging at how Ionic's <ion-toggle> works.

The <ion-toggle> element shares most attributes with the standard <input type="checkbox> that we are trying to emulate.
<ion-toggle> emits a ionChange, ionFocus and ionBlur events.
Since these are custom events frameworks like React and Angular don't know how to process these things into actual events that can be bound to thing like Reacts onChange and Angulars [(ngModel)]. To solve this Ionic has separate packages that wrap all of this up. So you end up with React components for your React app and Angular components for your Angular app.

While I think Ionic's approach has merit (this is probably part of the Stencil DS offering) but I think we might be able to do something like this:

<calcite-switch> <!-- The custom component would hide the checkbox and present a custom UI -->
  <input type="checkbox"> <!-- Angular, ect... would interact with this for the values -->
</calcite-switch>

patrickarlt · 2019-05-24T21:09:07Z

@driskull I'm not 100% sure that we need to go full BEM on this. Since styles are scoped to components and then scoped by Shadow DOM (or its polyfills) that we shouldn't any any problems with style conflicts which seems to be the main purpose of BEM. We also don't really have that much CSS per component only ~130 lines of CSS for this component sans variables and utilities.

kumarGayu · 2019-05-24T21:37:07Z

@patrickarlt is there any way i can validate my slot to allow only input checkbox?

driskull · 2019-05-24T21:41:18Z

I was thinking BEM just for consistency but we can just do that for our other components.

kumarGayu · 2019-05-25T00:27:19Z

@driskull changed the classes to BEM style. @patrickarlt I have tried to get it working for both ways if there is slot you can listen on slots. if not you can listen to stencil event.

kumarGayu · 2019-05-28T19:40:13Z

@macandcheese I have included the destructive property and the styling is updated accordingly.

patrickarlt

@kumarGayu I can't help but feel that this component is trying to do too much, particularly with the text and position properties. I also feel like there are some missed opportunities to improve how this component will integrate with the DOM in general and frameworks.

There are also a few other things:

<calcite-switch> needs a :focus state for accessibility
<calcite-switch> should support a disabled state
We need a discussion around ARIA for the component, possibly just following https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/checkbox_role and applying display:none to the passed <input type="checkbox"> to hide it form the accessibility tree.

patrickarlt · 2019-05-31T14:52:53Z

src/components/calcite-switch/calcite-switch.tsx

+
+  @Prop() checked = false;
+
+  @Prop() text = "";


The text option feels a little superfulous here. Couldn't we simply say that the <calcite-switch> compoennts is JUST the switch and let users wrap their own text around it like so:

<label> Text Before <calcite-switch> <input type="checkbox" ...> </calcite-switch> Text After </label>

I agree, this is similar to how we'd like to do the checkbox component as well

patrickarlt · 2019-05-31T14:57:42Z

src/components/calcite-switch/calcite-switch.tsx

+
+  @Prop() text = "";
+
+  @Prop() position: "left" | "right" | "after" | "before" = "left";


Similar to text couldn't we just let users decide where they want to place this with a standard CSS layout?

<label> <p style="float: left;"></p> <calcite-switch style="float: right;"> <input type="checkbox" ...> </calcite-switch> </label>

Removing bothposition and text would greatly simplify the component implementation and actually give users more flexibility in how they layout <calcite-switch> relative to the label and surrounding text.

@patrickarlt I have decided text to be inside the component because

Switch component can not exist with out explaining what is the purpose of it.

Switch component wrapping in label element might not work as expected.

still if you think switch would stand alone do the purpose then making it all alone will end up making us having one more component which is widely used.

When we combine text and switch then position is required position the switch. else we can remove position property.

While I agree that from an "end-user UI" perspective, labels or descriptions should accompany switches, I think we should leave the positioning and text to the implementer to make the component as light as possible. Perhaps that's a place where we'll want to have some extra documentation about best practices.

patrickarlt · 2019-05-31T15:00:54Z

src/components/calcite-switch/calcite-switch.tsx

+
+  @Prop() position: "left" | "right" | "after" | "before" = "left";
+
+  @Prop() destructive = false;


destructive seems like an unclear property name. I think I would rather follow what @macandcheese did for <calcite-alert> and simply use color names and not prescribe meaning to them. I think @Prop() color:"red" |"blue" = "blue" would be a better way forward here and be more consistent with established components.

I ported that from calcite web 2.0. Also, Color would definitely confuse why red and why blue, may be intuitive property would help consumers. do you suggest any other property name than destructive?

Yeah, we had used "intent" instead of color in that particular case because we wanted to avoid folks just using red switches when the action wasn't inherently destructive. Probably a larger discussion since many components will have some type of accent / status color.

I think that trying to implement color themes though properties names like destructive is really confusing. When I saw this I thought this property might destroy the switch after I toggled it. For clarity to the developer consuming this I think this is best used as description of what it does rather then what we intent it to be used for. "This property turns the switch red" (clear) vs "this makes the switch destructive" (unclear).

The also works for other things like alerts. https://esri.github.io/calcite-web/documentation/components/#alerts instead of success, warning, info and error alerts we simply use red, blue, green and yellow and leave it up to the developer to give the basic colors meaning.

As a example should we (the Calcite Components team) decide what color the switch should be if we replaced the checkbox here:

Neither enabling or disabling delete prevention is "destructive" but disabling it MIGHT be. Should we really be deciding this for teams?

Hmmmm, I feel we are pushing the overhead of deciding to users(consumers). But for colors it looks fine, as this colors would mean different to different consumers. Therefore, using intent to describe our property may not be that great at this base level. Should this be followed at every components in this repo? we should use what it does for property names rather than what intent it is for.

Agreed... let's just use "color" here :)

patrickarlt · 2019-05-31T15:06:47Z

src/components/calcite-switch/calcite-switch.tsx

+
+  @State() switched = this.checked;
+
+  @Event() switchChange: EventEmitter;


Events names are part of the global DOM scope so this could potentially interfere with another 3rd party component which emits a switchChange event. This should probably be something like calciteChange.

I felt calciteChange is confusing name as calcite can be many thing. But I was thinking calciteSwitchChange but felt that this is long enough.

This is something I've been wondering about. Wouldn't we want to model this closely to the stock HTML element that it's using? Like just change. Almost every HTML element can emit a "click" event. I feel like the shared event name is a feature. Wouldn't the shared event name make integration with React easier?

I agree with Paul too, we are already have calcite in the name of the component so i would like that not to repeat in all event names

@paulcpederson @kumarGayu there are 2 problems with just having this event name be change.

change events are already defined in the HTML Living Standard as only being fired from form elements (also defined by the standard). Since <calcite-switch> isn't a form element (as defined in the standard) it shouldn't use change.

It is unclear how <calcite-switch> would play out in something like React which has its own synthetic event system that probably wraps standard browser events. But our change is different then a standard change event. There also isn't a guarantee that this wouldn't break in the future.

If we decide on a non-standard name (changed vs change) there isn't a guarantee that our event name wouldn't conflict with another event name possibly from another library in the future.

As an example, Ionic prefixes all their event names with ion to separate then from regular browser events.

If that is kind of only option left, I am okay in prefixing calciteChange

patrickarlt · 2019-05-31T15:41:37Z

src/components/calcite-switch/calcite-switch.tsx

+        {(this.position === "right" || this.position === "after") && (
+          <span class="toggle-switch__label">{this.text}</span>
+        )}
+        <input


I don't think this input should be present here. Looking at the Ionic impliment for <ion-switch> they render a hidden input on every call to render() https://github.com/ionic-team/ionic/blob/master/core/src/components/toggle/toggle.tsx#L210 and https://github.com/ionic-team/ionic/blob/3d656ac3127278a7c9d3d4808c2806fde71e5d2b/core/src/utils/helpers.ts#L25. They then sync that input with the state of the <ion-toggle>. This hidden input lives outside the ShadowDOM so it take part in interaction with <form> elements.

Given that we also want to allot users to pass a <input type="checkbox"> into the <slot> I think we should do the following:

Add lifecycle hooks for componentWillLoad() and componentWillUpdate() inside the hook we should:

Check if there is a checkbox input as a child of this.el.

Treat that checkbox as the "source of truth" and sync the name, disabled and value and checked
properties from it.

This should keep the state of <calcite-switch> in sync with the users <input type="checkbox">

On every render() do the following:

Check if there is an input as a child of this.el if there isn't one create a hidden input (like Ionic) and treat <calcite-switch> as the source of truth and sync the name, disabled and value and checked values down to it. This hidden input should be a child of the <calcite-switch> but not part of the ShadowDOM.

Inside the componentWillLoad() hook we should also setup and event listener on the <input type="checkbox"> if one was provided and updated the checked property of <calcite-switch> based on it.

To do this name, disabledandvaluewill all have to be added as properties of`.

Doing this will allow users to do the following:

Pass an <input type="checkbox"> that acts as the "source of truth" for the <calcite-switch>. This allows frameworks (like Angular, ect...) to interact using their standard tools with the checkbox like <input type="checkbox" [(ngModel)]="booleanPropInMyAngularComponent"> and have that drive the <calcite-switch>

If a user doesn't pass a <input type="checkbox"> then <calcite-switch> acts as the soruce of truth but maintains a hidden form element so that any <form> element will still appear to have a value for <calcite-switch>

So Basically, we should support anything set on slot should reflect on switch. but, now it is other way. Would not this be confusing?

Given that we also want to allot users to pass a <input type="checkbox"> into the <slot>

Is that a given?

One of these things (the switch or supplied checkbox) should "win"over the other if the settings are out of sync. For example what should that state of the checkbox be here:

<calcite-switch checked disabled name="bar" value="baz"> <input name="foo" value="woo">  </calcite-switch>

patrickarlt · 2019-05-31T15:45:34Z

src/components/calcite-switch/calcite-switch.tsx

+          class="toggle-switch__input"
+          checked={this.switched}
+          onChange={this.setInputSlot.bind(this)}
+          onKeyPress={(event: KeyboardEvent) => {


Since my above comment is all about removing this (or potentially replacing it with a hidden input outside the ShadowDOM) <calcite-switch> will need to have a tabindex on the <Host> element and listen for the keydown event like how <calcite-tab-title> does https://github.com/ArcGIS/calcite-components/blob/master/src/components/calcite-tab-title/calcite-tab-title.tsx#L67-L80.

paulcpederson · 2019-05-31T18:26:38Z

Looks pretty good, but this PR is definitely bringing up some questions we'll need to solve on the project as a whole:

What is our naming scheme for events? For elements, we're pretty settled on calcite-{x} but for events, how should we structure this?
When wrapping a "stock" element (existing HTML element) does the consuming developer pass that in, or do we construct and maintain that within the library? This will probably effect integration with other frameworks.

Ideally (and this is pie-in-the-sky land) our component would be pretty much a drop in replacement for what we're replacing, IMO. So as a developer, I previously had:

<input type="checkbox" checked disabled>

I should just be able to drop in:

<calcite-checkbox checked disabled>

And leave all of my event listeners/handling code as-is and it would just work. Is this even possible?

Also, I've moved the switch issue to "in progress" on the project board.

macandcheese · 2019-05-31T19:31:05Z

<calcite-switch> needs a :focus state for accessibility

It looks like the :focus states aren't being applied when the switch 'is-active' .... we at some point hope to have better focus styles across ALL components, but for now we should be able to use the existing focus and active styles in the CW component: https://esri.github.io/calcite-web/documentation/components/#switches

Note that it is grey for unchecked switches of any type, red for checked "destructive / red" and blue for checked default, to match the style of the checked item.

macandcheese

Looks good overall - some styling and class name things - thanks for being the guinea pig on this, most of these are framework-level decisions that have yet to be decided upon, and this gives us a venue for those conversations :)

macandcheese · 2019-05-31T19:41:01Z

src/components/calcite-switch/calcite-switch.tsx

+    return [
+      <label
+        class={
+          this.destructive ? "toggle-switch--destructive" : "toggle-switch"


This should probably be an additional modifier class: "toggle-switch toggle-switch--destructive".

Currently, "destructive" switches don't receive the "toggle-switch" class and therefore do not have cursor: pointer, or any other base toggle-switch styles.

It may also be a little cleaner to style via a prop, instead of a class, ie:

:host([color="red"]) { ... }

patrickarlt · 2019-05-31T23:26:57Z

What is our naming scheme for events? For elements, we're pretty settled on calcite-{x} but for events, how should we structure this?
@paulcpederson #24 (comment)

Since event names are part of the global name space I think we should prefix all event names with calcite so we don't conflict with other events from other custom elements.

When wrapping a "stock" element (existing HTML element) does the consuming developer pass that in, or do we construct and maintain that within the library? This will probably effect integration with other frameworks.
...
And leave all of my event listeners/handling code as-is and it would just work. Is this even possible?
@paulcpederson #24 (comment)

@paulcpederson I don't know. I don't think that we should also assume that it would be totally cross frameworks either due to different implimentations of event system ect...

What I have been advocating for is for either of these to be eqiviliant:

<calcite-checkbox checked disabled></calcite-checkbox>

and

<calcite-checkbox checked disabled>
  <input type="checkbox" checked disabled>
</calcite-checkbox>

<calcite-checkbox> can still emit a calciteChanged event but in order to interact with </calcite-checkbox> in something like Angular I still need a standard <input type="checkbox" checked disabled> for doing all of Angulars standard form interactions like this:

<calcite-checkbox checked disabled>
  <input type="checkbox" checked disabled [(ngModel)]="somePropInMyAngularComponent">
</calcite-checkbox>

Ionic gets around this by publishing seperate wrappers for @ionic/react, @ionic/angular and @ionic/vue. You can see how Ionic wraps Angulars CcntrolValueAccessor in https://github.com/ionic-team/ionic/blob/master/angular/src/directives/control-value-accessors/boolean-value-accessor.ts to hook up the ionChange event into Angular.

So there are 3 paths forward:

Mirror Ionic and publish an additional adaption layer as a separate package that warps the web components for each framework.
Allow each Calcite Component to wrap around a native element as I have suggested and and allow frameworks to hook into the wrapped element.
Do nothing and force framework users to write their own wrappers around Calcite Component

kumarGayu · 2019-06-01T00:10:01Z

Allow each Calcite Component to wrap around a native element as I have suggested and and allow frameworks to hook into the wrapped element.

there are 2 problems with this.

the styling applied on input is not honored as we are kind of hiding it. so we provide some functionality and not all HTML possibilities of slotted children.

for ex:

<calcite-switch>
<input class="cssClass"/>
</calcite-switch>

.cssClass{
  this styles may not work 100%.
}

We are not emitting or catching all possible event on input we do only few which is of common interest.

if I miss something please do correct me.

can still emit a calciteChanged event but in order to interact with in something like Angular I still need a standard

keeping both in sync if child is present is kind of duplicate effort in terms of memory and code. This patter adds dev efforts in many of the component we develop.

paulcpederson · 2019-06-01T17:16:54Z

Summarizing decisions from this thread (good discussion!):

Event names should be prefixed. These are custom events, so should not use default event names (as explained by @patrickarlt ). Event names should take the form of calcite${Component}${Event}, ie. calciteSwitchChange. We should probably develop guidelines for what our events look like (ie. include component as target, etc)
Variations on color should be declared via a color attribute ( color="red") rather than using prescriptive semantic terms like error or destructive.
Components wrapping form elements should work without any element passed in. If you're using a framework that doesn't play nice with custom event names, we should allow passing in an input via a slot. (The best way to do this will probably be to have a slot with a default input that the user can override?)
Where possible we should style on the :host selector. Nested elements/modifier classes inside the host should adhere to BEM for consistency (maybe overkill, but it's a known standard and will make names predictable).

Does all that sound reasonable to everybody?

macandcheese · 2019-06-01T19:33:51Z

@paulcpederson thanks for summarizing - that all LGTM. I'll update Alerts and the other components I have in progress to reflect these decisions.

We should also probably decide on a code format style / linter and then put together a quick readme for all these high level considerations. I have no opinion on that, as long as it's consistent. Maybe use Hound et al. for pull requests.

pr3tori4n · 2019-06-03T15:22:05Z

src/components/calcite-switch/calcite-switch.e2e.ts

+  await page.setContent('<calcite-switch text="Test switch"></calcite-switch>');
+  await page.waitForChanges();
+  element = await page.find('calcite-switch');
+  switchElement = await page.find('calcite-switch >>> label');


I agree with others that the label should not be baked into this component. In the event that decision changes, this should probably be named switchLabel to avoid confusion.

pr3tori4n

Mostly looks good. I have a couple recommendations though.

pr3tori4n · 2019-06-03T15:25:06Z

src/components/calcite-switch/calcite-switch.scss

+//  ↳ http: //esri.github.io/calcite-web/documentation/components/#switches
+//  ↳ components → _switches.md
+// variables
+$switch-width: 36px;


I'd suggest avoiding using sass variable for any values that are only used once in the CSS. The result will be less code, and you avoid having to do a lookup when you're trying to find what a CSS property is set to.
The first five sass variables here are only ever referenced once. Please do a pass on these.

I felt any absolute values or color values to be fed in by consumers if they want different sizes.

src/components/calcite-switch/calcite-switch.scss

pr3tori4n · 2019-06-03T15:33:49Z

src/components/calcite-switch/calcite-switch.scss

+
+// spacing for label
+.toggle-switch__label {
+  width: calc((100% - 3em) - .5em);


just subtract 3.5em?

src/components/calcite-switch/calcite-switch.scss

pr3tori4n · 2019-06-03T15:36:07Z

src/components/calcite-switch/calcite-switch.scss

+  @include visually-hidden;
+
+  // hover
+  &:hover + .toggle-switch__track {


Seems odd to hover over something visually hidden - perhaps the hover belongs on a visual element?

visually hidden is not display none instead it is 1 sq px in size.

Ok. But isn't it pretty impossible to get the mouse to hover over on that 1px?

pr3tori4n · 2019-06-03T15:39:06Z

src/components/calcite-switch/calcite-switch.scss

+  }
+}
+
+.toggle-switch--destructive {


I'd suggest you overload classes with modifiers (e.g. .toggle-switch.toggle-switch--destructive {}). A modifier is an override, so it makes sense to add specificity to the selector for when a modifier is present. This also prevents this modifier from being misused by limiting it's usage to override only the intended selector.

Also - seems like this selector should be renamed if the property is renamed. I'm also in favor of naming that describes behavior (which should be universally true) over intent (may/may not be true).

pr3tori4n · 2019-06-03T15:42:00Z

src/components/calcite-switch/calcite-switch.scss

+}
+
+.toggle-switch--destructive {
+  & .toggle-switch__input:hover + .toggle-switch__track:after { border-color: $handle-destructive-hover-border-color; }


Perhaps I'm missing something, but these ampersands are unnecessary aren't they?

pr3tori4n · 2019-06-03T15:51:18Z

src/components/calcite-switch/calcite-switch.tsx

+      input.checked = this.switched;
+      input.dispatchEvent(evt);
+    }
+    this.switchChange && this.switchChange.emit(this.switched);


I think it would be a little clearer to anyone attaching a listener if we passed them an object with a key rather than just a boolean. Maybe something like switchOn would be better nomenclature than checked for a consuming dev. But either would be a nice boon for readability.

Suggested change

this.switchChange && this.switchChange.emit(this.switched);

this.switchChange && this.switchChange.emit({switchOn: this.switched});

Lot of us are having difference of opinion in nomenclature. Initially we thought we will have it similar to HTML tag properties. but now we thought events would clash so thinking of calcite prefix, IMO, we should follow same for all different properties or events.

@macandcheese @patrickarlt @driskull

pr3tori4n · 2019-06-03T15:52:12Z

src/index.html

@@ -15,7 +15,11 @@
        padding: 1rem;
      }
    </style>
-
+    <script>
+      function sayHi(val) {


val not used on line 292. Might even be able to just hardcode console.log('hi') as the funciton passed to onChange to clean this up a bit.

pr3tori4n · 2019-06-03T15:57:25Z

@paulcpederson

Summarizing decisions from this thread (good discussion!):
...
2. Variations on color should be declared via a color attribute ( color="red") rather than using prescriptive semantic terms like error or destructive.

I think this applies to more than just colors. I think the general idea here is that our names of properties, methods, events, etc. should describe behavior rather than semantic intent. This makes it very simple for anyone utilizing the component to know what something is for (prop), what it does (method), or what it's doing (event). I support this idea.

paulcpederson · 2019-06-03T17:18:58Z

@pr3tori4n good review. A lot of the Sass comments are from the CW code, but this will be a good opportunity to clean up some of that Sass code as we're porting it over.

kumarGayu · 2019-06-03T17:59:50Z

After having all the discussions, this component now splits into 2 components,

<calcite-label>
  <slot name="text"><span></span></slot> // based on position
  <calcite-switch calcite-switch-change=()=>{} calcite-switch-focus=()=>{}>
    <input type="checkbox" > //optionally. and sync these properties back and forth from calcite-switch.
  </calcite-switch>
  <slot name="text"><span></span></slot> // based on position
</calcite-label>

I will start working on this 👍

but one question arose from @pr3tori4n discussion that should the properties be named based off the component name?
like switch-on instead of checked

paulcpederson · 2019-06-03T18:02:05Z

No I don't think we want a calcite-label component, IMO that would provide no benefit to the stock label element.

macandcheese · 2019-06-03T18:03:29Z

Hmm, I kind of feel like label should just be left as plain HTML and not a web component.

<label class="custom-class">
My description that I can style as I wish
<calcite-switch {...stuff}></calcite-switch>
</label>

For checked, that's also semantically standard, not sure if we'd want to change that...

kumarGayu · 2019-06-03T18:11:43Z

@paulcpederson / @macandcheese today it might not have any style or purpose. having that as a separate component can add values in future. As all component that we use is under one central code.

macandcheese · 2019-06-04T13:15:12Z

In a situation where Calcite Components is a more 1:1 re-creation of CW that includes non-functional components like buttons, and inputs (Ionic as an example does), I could see labels being appropriate to add, but with our current roadmap it seems a little out of scope since it's just recreating HTML with no interactivity. Neither Material, Carbon seem to use custom label components.

Perhaps in the future if CC moves towards Ionic in its structure, a custom label component might be more fitting and appropriate to add in at that time?

kumarGayu · 2019-06-04T15:58:52Z

@macandcheese I agree. but in that rewriting may be little more time than adding just now one component. if adding that as a component is not too much work then we can think of moving it now. I believe that when we have to rewrite then we will have that as a reason to not to have that new component. :(

kumarGayu · 2019-06-05T17:59:25Z

We can close this for now, as patrick has created conventions as readme and also we have a sample form component.

feature(tokens): Design Token Updates

kumarGayu added 4 commits May 23, 2019 17:39

Added basic switch component

2a9d597

Written test cases for calcite-switch

d73218a

corrected unwanted test cases

6e2beb7

Added calcite-switch with min test cases working

b1d02b7

kumarGayu requested review from patrickarlt, driskull and macandcheese May 24, 2019 17:56

driskull requested changes May 24, 2019

View reviewed changes

kumarGayu added 5 commits May 24, 2019 14:42

Added destructive and sample on indec.html

ab30547

Added slot and customer can read input

bc83ede

Added BEM and updated test cases.

390c6a3

emitting the change if no input from slot.

f25af5e

formatted the document.

7064cfd

Dispatch change event on a slotted input inside the label.

cc22059

kumarGayu added 2 commits May 28, 2019 13:42

Updated stencil config to include the calcite-switch

6709244

Updated Html to show switches as global navigation

6cbc398

kumarGayu requested a review from driskull May 28, 2019 21:44

keypress event on switch box.

3446c89

patrickarlt mentioned this pull request May 29, 2019

Component: Radio Group #5

Closed

kumarGayu added this to the 1.0.0 milestone May 30, 2019

patrickarlt reviewed May 31, 2019

View reviewed changes

macandcheese requested changes May 31, 2019

View reviewed changes

pr3tori4n reviewed Jun 3, 2019

View reviewed changes

pr3tori4n suggested changes Jun 3, 2019

View reviewed changes

paulcpederson mentioned this pull request Jun 3, 2019

Component: Checkbox #1

Closed

kumarGayu mentioned this pull request Jun 3, 2019

Component: Label #31

Closed

Added latest plan of moving this.

686f36c

patrickarlt mentioned this pull request Jun 4, 2019

Conventions #32

Merged

patrickarlt mentioned this pull request Jun 4, 2019

Calcite switch #33

Merged

sample calcite-switch

d8540bc

kumarGayu closed this Jun 5, 2019

kumarGayu deleted the Switch-component-for-charting-basic-component branch June 6, 2019 21:53

patrickarlt mentioned this pull request Jun 28, 2019

Calcite-switch won't switch if not wrapped in <label> #67

Closed

alisonailea pushed a commit that referenced this pull request Aug 29, 2023

Merge pull request #24 from Esri/designer/brunoaires

90b0f21

feature(tokens): Design Token Updates


		@Prop() text = "";

		@Prop() position: "left" \| "right" \| "after" \| "before" = "left";


		@Prop() position: "left" \| "right" \| "after" \| "before" = "left";

		@Prop() destructive = false;


		@State() switched = this.checked;

		@Event() switchChange: EventEmitter;

	this.switchChange && this.switchChange.emit(this.switched);
	this.switchChange && this.switchChange.emit({switchOn: this.switched});

Switch component for charting basic component #24

Switch component for charting basic component #24

Conversation

kumarGayu commented May 24, 2019

driskull left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kumarGayu commented May 24, 2019

macandcheese commented May 24, 2019

patrickarlt commented May 24, 2019 • edited

patrickarlt commented May 24, 2019

kumarGayu commented May 24, 2019

driskull commented May 24, 2019

kumarGayu commented May 25, 2019

kumarGayu commented May 28, 2019

patrickarlt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kumarGayu May 31, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulcpederson May 31, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulcpederson commented May 31, 2019 • edited

macandcheese commented May 31, 2019 • edited

macandcheese left a comment • edited

Choose a reason for hiding this comment

macandcheese May 31, 2019 • edited

Choose a reason for hiding this comment

patrickarlt commented May 31, 2019

kumarGayu commented Jun 1, 2019

paulcpederson commented Jun 1, 2019

macandcheese commented Jun 1, 2019

Choose a reason for hiding this comment

pr3tori4n left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pr3tori4n commented Jun 3, 2019 • edited

paulcpederson commented Jun 3, 2019

kumarGayu commented Jun 3, 2019

paulcpederson commented Jun 3, 2019

macandcheese commented Jun 3, 2019 • edited

kumarGayu commented Jun 3, 2019

macandcheese commented Jun 4, 2019 • edited

patrickarlt commented May 24, 2019 •

edited

kumarGayu May 31, 2019 •

edited

paulcpederson May 31, 2019 •

edited

paulcpederson commented May 31, 2019 •

edited

macandcheese commented May 31, 2019 •

edited

macandcheese left a comment •

edited

macandcheese May 31, 2019 •

edited

pr3tori4n commented Jun 3, 2019 •

edited

macandcheese commented Jun 3, 2019 •

edited

macandcheese commented Jun 4, 2019 •

edited