Multiselect header/footer

[Bohdan]

Hi Telerik Team,

How can I force on header/footer click to not to close a dropdown?
I want "Select All" to be a part of header, not to be a part of list of items as mentioned here:
https://stackblitz.com/edit/kendo-react-multiselect-checkboxes-hfkoyn?file=app%2Fmain.jsx

Btw, this (if all dependencies updated) doesn't work anymore:
https://stackblitz.com/edit/react-7vxshz-mo7jrl?file=app/main.jsx

Regards,
Bohdan

[Yanko]

Hi, Bohdan,

Yes, you can keep the KendoReact MultiSelect dropdown open when clicking a custom header or footer element (such as a "Select All" button). You need to stop the propagation of the click event of the KendoReact Button. This ensures the dropdown does not blur and close when the button is clicked. I prepared an example to demonstrate this solution:

• https://stackblitz.com/edit/react-dpgwnkor?file=app%2Fapp.jsx 

You mentioned that the linked StackBlitz does not work with updated dependencies. This is due to a version mismatch between KendoReact(v4.4.0)  and Kendo Themes(latest). Here is the fixed version:

• https://stackblitz.com/edit/react-7vxshz-ryazvgx6?file=index.html,app%2Fmain.jsx 

Please do not hesitate to ask if I can further help.

Regards,
Yanko
Progress Telerik

[Bohdan]

Hi Yanko,
thank you for the provided examples.

I have a couple of follow-up questions regarding the MultiSelect architecture:

    1. Why are the header and footer not treated as part of the dropdown “user interaction area”?
From what I see, any focusable element (input, textarea, etc.) placed in the header or footer will inevitably cause the popup to close due to the blur logic. This effectively means that header/footer can only contain non-focusable controls (like buttons), which does not fit our design and UX requirements.

    2. This behavior makes it impossible to place interactive, focusable UI (e.g. a search input) inside the header or footer. From our perspective, this looks like a limitation of the MultiSelect’s extensibility rather than a misuse of the component.

In your opinion:
-Is this behavior intentional and unlikely to change due to multiselect component's architecture?

-Or is there a chance that header/footer could be treated as part of the interactive popup area in the future?

-Otherwise, would you recommend recreating MultiSelect-like functionality using Popup / lower-level components for such use cases where we want to have a field with dropdown component like this https://www.telerik.com/kendo-react-ui/components/grid/filtering/advanced-filtering
?
(the popup of grid's filtering)

I’d appreciate your honest take on whether this is a supported scenario or something we should explicitly avoid with the current MultiSelect.

Best regards,
Bohdan

[Yanko]

Hi, Bohdan,

The behaviour where clicking anywhere in the header closes the popup is actually a bug, and I have logged it in our public repo, but it is not related to the architectural design of the component, and when it is fixed, it will still not allow adding interactive elements inside the popup:

• https://github.com/telerik/kendo-react/issues/3526 

When a focusable element within the popup receives focus, the MultiSelect blur logic triggers and closes the popup. This design is intentional: the dropdown popup is closed when focus leaves the MultiSelect input element. As a result, only non-focusable controls (such as buttons with event handlers that prevent default blur behaviour) can be used reliably inside the MultiSelect.

This is a known limitation and is by design in the current architecture. The MultiSelect is not built to support focusable interactive elements inside its Popup. There is an open feature request on our feedback portal for supporting custom search components within the MultiSelect dropdown header. This request captures the need for treating the header/footer as part of the interactive popup area. I have added your vote to it:

• https://feedback.telerik.com//kendo-react-ui/1568624-custom-search-component-in-multiselect

While user feedback is being considered, there are currently no public plans or timelines for changing this architectural behaviour. For now, it is safest to consider this scenario unsupported with the current MultiSelect and implement a custom component that precisely matches your requirements using lower-level components.

If you have more questions, let me know.

Regards,
Yanko
Progress Telerik

[Bohdan]

Ok, thank you for your answer!