SelectButton: SelectItem[] TypeScript Def

[AntonyGarand]

There is no guarantee in receiving an immediate response in GitHub Issue Tracker, If you'd like to secure our response, you may consider PrimeReact PRO Support where support is provided within 4 business hours

I'm submitting a ... (check one with "x")

• feature request

I'm requesting a feature to be able to style the splitbuttons!

Current behavior
Hey!

At the moment, a split button is wrapper above few buttons, but we can not style the underlying buttons natively, even though buttons have a variety of available styles.
The most obvious missing feature is changing the color, from primary to secondary/warning/any other of the available styles, but other features such as having it be an outlined/raised/rounded buttons are also relevant.

The only way to style buttons at the moment is via CSS, which means duplicating the style we want instead of using the existing class.

Expected behavior
Being able to style the buttons via one of these methods:

• Passing a buttonClassName like Fix #1939/#1882: SplitButton buttonClassName, menuButtonClassName #2461, which would add classes to the child buttons
• Passing a prop with the desired style, which would apply the adequate classes automatically: <SelectButton buttonStyle={{color: "secondary", style:"raised"}}

[melloware]

I will take this one.

[melloware]

@AntonyGarand it looks like you can already do this on the options but setting className on each option.

So if you make your options like...

const citySelectItems = [
    {label: 'New York', value: 'NY', className: 'my-class-name`},
    {label: 'Rome', value: 'RM', className: 'my-class-name`},
    {label: 'London', value: 'LDN', className: 'my-class-name`},
    {label: 'Istanbul', value: 'IST', className: 'my-class-name`},
    {label: 'Paris', value: 'PRS', className: 'my-class-name`}
];

here is the source where its creating each button.

 const createItems = () => {
        if (props.options && props.options.length) {
            return props.options.map((option, index) => {
                const isDisabled = props.disabled || isOptionDisabled(option);
                const optionLabel = getOptionLabel(option);
                const tabIndex = isDisabled ? null : 0;
                const selected = isSelected(option);
                const key = optionLabel + '_' + index;

                return <SelectButtonItem key={key} label={optionLabel} className={option.className} option={option} onClick={onOptionClick} template={props.itemTemplate}
                    selected={selected} tabIndex={tabIndex} disabled={isDisabled} ariaLabelledBy={props.ariaLabelledBy} />
            });
        }

        return null;
    }

Can you try it and verify?

[melloware]

here is the TypeScript def for SelectItem

export interface SelectItem {
    label?: string;
    value?: any;
    className?: string;
    icon?: IconType<SelectItem>;
    title?: string;
    disabled?: boolean;
}

[AntonyGarand]

It does indeed work!
Looks like the SelectButtonProps options does not specify a SelectItem type, using any[] instead.
Since it's not documented on the docs either, I assumed it didn't support it, oops!

Thanks for the quick answer!

export interface SelectButtonProps {
    id?: string;
    value?: any;
    options?: any[];
    // ...

Not sure if I should leave this open and change it to a feedback to update the docs / ts or close it though.

[melloware]

Let me ask @mertsincan should I change the TS definition from any[] to SelectItem[] ??

[AntonyGarand]

I believe it should be a mix of both: It can have more properties than SelectItem, especially if using a template for the items, but should at least have partial support for SelectItem.
Perhaps something like SelectItem & any to be as generic as possible

[melloware]

I submitted a PR not sure if it is correct or not though!

[1EDExg0ffyXfTEqdIUAYNZGnCeajIxMWd2vaQeP]

SelectItem[] | any[] provides literally no benefit over any[] with regards to typechecking, as described in dtslint. The type SelectItem already included the case that it may have more properties, so there's no need to use a union type here.

[melloware]

Feel free to submit a PR!

[AntonyGarand]

It might not have any difference in regards to typechecking, but it does help the humans figure out the expected types, which caused this issue overall.
I'd vote to keep it with the union type for this purpose: No downsides into keeping it as-is either.

[1EDExg0ffyXfTEqdIUAYNZGnCeajIxMWd2vaQeP]

But is there any reason one wouldn't pass a SelectItem[]?