Feasibility of Splitting Radzen Blazor DropDown Component into Multiple Components

[frankstallone]

ur team is developing a design system that leverages Radzen for our Blazor component library and Radix/shadcn for our React component library. To maintain consistency across both frameworks, we've adopted naming conventions inspired by Radix/shadcn. This approach has led us to consider restructuring some components in our Blazor library to align more closely with their React counterparts.

Specifically, we're examining the Radzen Blazor DropDown component. In our React library, similar functionality is divided into distinct components like Combobox and Select. We believe that decomposing the DropDown into multiple components could enhance modularity and reusability in our Blazor application, especially since our design system serves multiple internal teams who will consume these components.

Given our team's stronger background in React and relative inexperience with Blazor, we have several questions:

1. Feasibility: How practical is it to split the existing Radzen Blazor DropDown component into multiple, more specialized components? Are there inherent limitations or considerations we should be aware of?
2. Implementation Guidance: Could you provide pointers or best practices for our team to begin experimenting with this restructuring? Any specific documentation or resources would be greatly appreciated.
3. Testing Strategies: What testing methodologies are recommended to ensure that, after restructuring, we haven't inadvertently lost any core functionality? Are there particular tools or frameworks suited for testing Blazor components?
4. Additional Advice: As a team eager to learn but new to Blazor, do you have any other recommendations or insights regarding building custom front-end frameworks in Blazor?

We value the expertise of this community and look forward to your guidance. Thank you in advance! Feel free to ask me any clarifying questions.

[korchev]

Hi @frankstallone,

@frankstallone

How practical is it to split the existing Radzen Blazor DropDown component into multiple, more specialized components?

I don't think this is a practical idea. You would need to maintain two components on your own and perhaps port any upstream changes we introduce in the future.

@frankstallone

Could you provide pointers or best practices for our team to begin experimenting with this restructuring?

RadzenDropdown is mostly a "Select" component rather than "ComboBox". The editable dropdown demo customizes the ValueTemplate to achieve the "combobox" behavior so it isn't a novel functionality that can be restructured into a new component.

@frankstallone

What testing methodologies are recommended to ensure that, after restructuring, we haven't inadvertently lost any core functionality?

If you do the restructuring you will definitely lose functionality As far as I understand you want to deliberately split the component (not sure what features you would like to remove though).

@frankstallone

Additional Advice: As a team eager to learn but new to Blazor, do you have any other recommendations or insights regarding building custom front-end frameworks in Blazor?

I would advise against building a custom front-end framework unless none of the existing ones meet your requirements. This is a very challenging task and that's why so many frameworks exist.

[frankstallone]

Thanks for the quick response!

I don't think this is a practical idea. You would need to maintain two components on your own and perhaps port any upstream changes we introduce in the future.

This is literally what I've done at every Design System in my entire life. Customized component libraries to fill the unique needs of our consumers.

At ADP we originally maintained 4 front-end frameworks before slowly getting down to one. Mostly custom, before design systems was even a phrase.

If you do the restructuring you will definitely lose functionality As far as I understand you want to deliberately split the component (not sure what features you would like to remove though).

We would want to keep parity with Select and Combobox from shadcn.

I would advise against building a custom front-end framework unless none of the existing ones meet your requirements. This is a very challenging task and that's why so many frameworks exist.

Just to be clear, we're standing on the shoulders of giants. In the past I've been part of groups that created their own UI components from scratch but sometimes we would lean on open source software and modify it to make it work for our unique needs.

[frankstallone]

Anyone else have any thoughts?