Implemented STACKED orientation

[theshoeshiner]

Really liked your toggle button add-on. Added a small feature that I needed and figured id send it along for your consideration as it was a very small change and potentially helpful.

Implemented a STACKED orientation. Using this orientation, only a single button is visible at any time (as if they were stacked on top of one another) and clicking the button iterates through the values. I've found it very useful in exactly the same scenarios as your toggle button.

Implementation is pretty tiny, with really only 3 changes (only applied when in STACKED orientation)

• CSS class and style to hide all but the primary button
• Automatically iterating to the next value when a button is clicked
• Automatically setting the value to the first item. This seemed appropriate since the STACKED orientation implies that one value is always selected.

Added an example of it to the demo view as well.

[taefi]

Hi @theshoeshiner, thank for the contribution! I'll take a look as soon as possible.

[taefi]

@theshoeshiner I've looked at the proposed STACKED orientation, and I'm still giving myself some time to digest whether this is comprehensive for the end users to see what are the available options before they start to interact with the component or not. TBH, the stacked orientation feels like Select or a Single Select ComboBox that the user only see the selected option, but with the difference that if they want to select another option, they should explore almost all the options and also change their selection by clicking the button multiple times.

At the same time, I was thinking that to achieve the purpose of what proposed here as the STACKED orientation, I myself would go for a separate component rather than changing the toggle button group, since the whole implementation would be more compact and clearer and also more maintainable for future improvements.

[theshoeshiner]

Thanks for the response!

Yea really it's just UI sugar, since it doesn't do much more than Check/Combo Box. It's also practically limited to probably 2-4 states, since more than that is cumbersome to click through. In my use case, the thought is that after encountering the form a couple times, the user will be well-acquainted with the possible options, and will not need to click through to see the available ones. In addition, the form field text could indicate the options when they are concise enough: eg "Yes/No/Maybe". (That may defeat the purpose though, just depends on the rest of the UI).

Assuming the user knows the options, the main benefit is that the "flip" nature of it is almost always faster - e.g. when compared to a drop down, which has 2 clicks at a minimum, and always requires mouse movement - this stacked implementation requires often just 1 click, and never any mouse movement. It's also easier on mobile, since there would be no popup.

It could definitely be a separate component, and I almost implemented it as such, but realized that it would share quite a few features with, and could benefit if/when more features are added to the ToggleButtonGroup in the future. In that sense it would essentially be "tagging along" to this component, so I understand if it doesn't provide enough value to be worth maintaining.

The only advantage I saw in implementing a separate component for this logic is that a separate component could create a single Button and change it's text, rather than using CSS to display only the selected stacked button. However this carries the disadvantage that customizing specific value buttons then requires a more complex implementation to manage all the customizations separately and apply/unapply based on the value. So in reality I would probably implement a separate component in much the same fashion as this.

[taefi]

Another advantage of separating the STACKED orientation as a separate component would be that when the multi-select feature is going to be added to toggle-button-group, the STACKED orientation is not going hang in there looking alike an abandoned child just because it does not fit into the picture... Otherwise, It would create some unwanted complications to exclude it when it comes to allow multi-select, for example.