Better form developer experience

[ogix]

Feature request type

Enhance forms

Component name

No response

What should be done?

This is very nice UI framework but it lacks good developer experience for forms.

For example, currently form components like Textbox or Select are responsible for displaying labels, their position and error messages. This design introduces these limitations:

• Each form component needs to have same repetitve properties as Label, LabelPlacement, ErrorMessage, Description, etc
• It's harder to create new custom form components. This is very important as any framework should allow to create custom form components with same styling.
• Since components accept ErrorMessage property, form validation with DataAnnotationsValidator becomes as not a trivial task.
• Probably harder to ensure consistent field styling for all components

Instead I suggest to have some kind of reusable FormField wrapper component that would be responsible for displaying labels, description as other frameworks do. Regarding validation errors, it could have a placeholder to use either Blazor's ValidationMessage component or any custom message.

If it had better form DX and more form controls (DatePicker, TextArea), it would be my number 1 choice for new Blazor projects!

Pull Request

• I would like to do a Pull Request

[desmondinho]

Hey @ogix,

Thank you for the feedback -- this is a valuable discussion.

1. Label placement, descriptions, and error handling
   A future Form (or similar) component could indeed cascade things like LabelPlacement and potentially error display behavior down to inputs via cascading parameters. That part is feasible and aligns with the direction I am considering.
   However, labels and descriptions are not purely behavioral concerns -- they are structural UI elements. Centralizing them entirely in a wrapper limits flexibility in certain layouts, which is why they currently live with the input components themselves. I am not sure I understand how they could be centralized in a reasonable way.

2. Creating custom form components
   There is already an InputFieldBase abstract component that custom form controls can inherit from. This base encapsulates shared logic and conventions, specifically to make custom components consistent with built-in ones. That said, the documentation around this can certainly be improved.

3. EditContext / DataAnnotations integration
   You are correct here. Full integration with Blazor’s EditContext and DataAnnotationsValidator was intentionally skipped in the initial iterations to keep the surface area small. In hindsight, this is an important piece of developer experience for real-world forms, and I agree it should be addressed.

4. Consistent field styling
   I’m not entirely sure I understand this concern as stated. All form components share the same slots and internal structure, so consistent styling is already achieved by reusing the same style definitions. If a different concern was meant here, I would appreciate clarification.

Finally, regarding “as other frameworks do” -- could you provide concrete examples or references? It would be helpful to understand which frameworks and patterns you are specifically referring to, so the comparison can be evaluated more precisely.

Also noted on missing components like DatePicker and TextArea. These are on the roadmap, and feedback like this helps prioritize them.

Thanks again for the thoughtful input.

[ogix]

Hi, sorry for late response.

Actually after looking at the source code once more time I found the current implementation very interesting. And now I think that it is ok that components itself have Label, Description, LabelPlacement parameters. But for custom form components they will probably inherit from LumexInputBase (as LumexInputFieldBase renders input element) that don't have those properties and they will need to render Label, Description and error messages themselves. So that is the biggest concern for me because if custom components render those properties themself it means that they will not follow the same pattern and it will be harder to maintain in the future when things will change in the framework.

That being said, I still think that some reusable component that renders label, description and maybe error messages would solve this problem. For Chechbox and Radio cases it could have Orientation parameter.
And it could be used not outside the component as I initially suggested but inside the component. Then we need to ensure every component (custom and not custom) has those properties - probably move some properties like Label, Description properties from LumexInputFieldBase down to LumexInputBase?

Regarding other frameworks, for example MudBlazor has MudField wrapper that allows to wrap any form control: https://mudblazor.com/components/field

I am glad that some things are already on the roadmap! If you need any help - just let me know.

[ogix]

I've created this PR that should solve custom components issues: #271
Let me know what do you think.

Also it would be great to have EditContext integration with automatic validation. I can also try creating a new PR after this will be merged.

[desmondinho]

Hey @ogix,

I am sorry for the lat response.

But for custom form components they will probably inherit from LumexInputBase (as LumexInputFieldBase renders input element) that don't have those properties and they will need to render Label, Description and error messages themselves.

I am not sure I understand this. I am not sure I understand the problem we are trying to solve. Why do we need to inherit from LumexInputBase if we can inherit from LumexInputFieldBase that contains all necessary parameters (e.g., Label, Description, ErrorMessage)?

That being said, I still think that some reusable component that renders label, description and maybe error messages would solve this problem.

This is what LumexInputFieldBase was made for.

For Chechbox and Radio cases it could have Orientation parameter.

This is something I don't really want to introduce as this will break the API consistency. I am not going to introduce common parameters that are tightly coupled to only 1-2 specific components.

probably move some properties like Label, Description properties from LumexInputFieldBase down to LumexInputBase

This one needs investigation, because there are components like checkbox, radio, and switch that are derived from LumexInputBase already.

[ogix]

I am not sure I understand this. I am not sure I understand the problem we are trying to solve. Why do we need to inherit from LumexInputBase if we can inherit from LumexInputFieldBase that contains all necessary parameters (e.g., Label, Description, ErrorMessage)?

As I see currently LumexInputFieldBase is designed only for input elements. Custom components can inherit from it and use custom razor template but here are the problems that I mentioned earlier:

• Custom components must render Label, Description themself meaning that they can render in any way
• There are many properties that only make sense only to input elements: StartContent, EndContent, Variant, Radius, LabelPlacement, Placeholder. For example I want to create rating component that allows to select stars from 1 to 5. These properties do not make sense to this component so they won't be event used and only introduce confusion.

That is why I am saying that custom components (not input-based) should inherit from LumexInputBase.

For Chechbox and Radio cases it could have Orientation parameter.

This is something I don't really want to introduce as this will break the API consistency. I am not going to introduce common parameters that are tightly coupled to only 1-2 specific components.

I am talking about the new wrapper component FormField that I implemented in this PR. You can see usage here.

Have a look at refactored LumexRadioGroup. Now it does not render Label, Description, ErrorMessage but delegates this to FormField.

This is the idea I propose also for custom components.
I hope it's more clear what problem I am trying to solve :)

[desmondinho]

Hey @ogix,

Thank you for the detailed answer!
Could you also provide an example which custom non-input-based components you're referring to?

[ogix]

Basically any that lumex does not have: Rating, Range (slider), ButtonGroup..
But in more complex projects usually you want to create custom components to encapsulate complex logic. And for that reason framework should provide building block that allows to have consistent structure (label, description, etc..).