vwc-toggle-button

[YonatanKra]

Hi,
We're starting to think about the vwc-toggle-button component.
Somewhat like this:

Taken from here: https://material-ui.com/components/toggle-button/

Suggested API

Usage Template

<vwc-toggle-buttons-group activeindex="2">
 <vwc-button value="whatever"></vwc-button>
 <vwc-button value="whatever1"></vwc-button>
 <vwc-button value="whatever2"></vwc-button>
 <vwc-button value="whatever3"></vwc-button>
</vwc-toggle-button>

API

Properties/Attributes

Name	Type	Description
multiple	reflected	Allows for multiple selections
value	property	The value/values of the selected button/s. Will be bound to the buttons (clearing this will clear selected buttons in the view as well)
activeIndex	property	The indices list (array) of the currently toggled buttons

Events

Name	event.detail	Description
toggle	{state: []{ activeIndex, value, active }, toggled: {activeIndex, active} }	An object with the current state of the group as well as the toggled button index and state (active/inactive => true/false)

Design API

There will be a class set on the selected button/s that will change its look according to what will be decided in Figma.

[tveinfeld]

what would you say is the value offered here beyond what can be achieved using a group of vwc-buttons?

[yinonov]

this is part of the volta parity and seems like highly requested component

[tveinfeld]

got it.
should we deliver logic or simply design here?

[yinonov]

care to explain? I think the purpose of this discussion is to find out

[tveinfeld]

I meant, perhaps we can just provide the design for this group of buttons without managing state/mode (multiple and value)

[yinonov]

I feel it should eventually output value like in https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select_multiple

[yinonov]

Usage Template

<vwc-toggle-buttons>
 <vwc-button value="whatever"></vwc-button>
 <vwc-button value="whatever1"></vwc-button>
 <vwc-button value="whatever2"></vwc-button>
 <vwc-button value="whatever3"></vwc-button>
</vwc-toggle-button>

I would suggest keeping it synced with other components like tab-bar and a dedicated option element to not pollute the original button with more style variants or scoping

<vwc-toggle-button-bar>
  <vwc-toggle-button value="whatever"></vwc-toggle-button>
  <vwc-toggle-button value="whatever1"></vwc-toggle-button>
  <vwc-toggle-button value="whatever2"></vwc-toggle-button>
  <vwc-toggle-button value="whatever3"></vwc-toggle-button>
</vwc-toggle-butto-bar>
> ```

[yinonov]

common ppl upvote the latter! it's fantastish! 🦾

[gullerya]

2 vwc-toggle-button-bar

[tveinfeld]

2 vwc-toggle-button-bar.. If we're about to hold state, let's do it using state-holding buttons :)

[lagjamhero]

2 - although if this is for volta button-group parity, we also supported text buttons

[jshenkman]

Yes, we need to support text as well. VCC love this component

[YonatanKra]

Ok, the vote was case for:

<vwc-toggle-button-bar>
  <vwc-toggle-button value="whatever"></vwc-toggle-button>
  <vwc-toggle-button value="whatever1"></vwc-toggle-button>
  <vwc-toggle-button value="whatever2"></vwc-toggle-button>
  <vwc-toggle-button value="whatever3"></vwc-toggle-button>
</vwc-toggle-butto-bar>

Question about it: instead of building one thing, we need to build two new things (toggle-button-bar and toggle-button)?

I know some ppl think inheritance is an innocent and harmless tool, but I'm not one of them - so please let me know you are convinced we'd like to unnecessarily create another inheritance level.

[gullerya]

Last 2 cents for now: as the API candidate it is probably worthy to take the vwc-icon-button-toggle API:

• on property/attribute [boolean] to reflect the state
• change event when on is being changed

You'd then only need to require a value property/attribute so that the bar would be able to say which button is currently on. vwc-icon-button-toggle do not have value... so, well, need to think if we'd like to keep it fully open (and just say to the consumer "drop value attribute or property at runtime, we'll pick it up from there (+ define precedence)" or add value to our own vwc-icon-button-toggle.

Phase 2 (P1) you could do it fully customizable, allowing this:

<vwc-toggle-button-bar toggle-source="checked" value-source="someCustomProperty">
...
</vwc-toggle-button-bar>

[yinonov]

I'd drop my thoughts here on, as always, the matter of convention first and foremost. I mean, if other similar components are already defined in a certain sensible way, we better stick to that. I would even say let's align to the API naming of tabs.
furthermore I believe extending subsystem components is a good thing.

[yinonov]

not sure if that's rocking the boat here, but the select tag might share similar behavior to what we expect where multiple attribute is set https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select

[yinonov]

lastly, I think u'll find vwc-icon-button-toggle somewhat limiting. maybe only copy certain needed parts of it?

[yinonov]

There's already a <vwc-icon-button-toggle> component, perhaps we can use it?
I guess we're only dealing with icons, right?

requests from devs show more than only icons but text as well. @jshenkman?

[yinonov]

Screen.Recording.2021-04-06.at.22.37.29.mov

[yinonov]

follow progress at https://tmp.dev.vivid.vonage.com/753/index.html?path=/story/components-atoms-toggle-buttons-group--basic

[yinonov]

consider vertical layout to enable navbar usage.
another reason not to enforce wai-aria attributes on assigned slotted elements - consumer would might want to set navbar related values