Expose the string prefix from Editor<T> so that other components can consume it (title updated to reflect context)

[akorchev]

Background and Motivation

I am one of the developers of the Radzen.Blazor component library and would like to use HtmlFieldPrefix and ExpressionFormatter in some of the components that we maintain.

Proposed API

I propose making HtmlFieldPrefix and ExpressionFormatter public classes in order to use them in custom Blazor components that don't inherit from InputBase. The reason for not inheriting from InputBase is that it requires a ValueExpression to be set and throws exception otherwise. It would be a breaking change for our users.

Usage Examples

We would use HtmlPrefix and ExpressionFormatter similar to InputBase for custom components in the Radzen.Blazor component library. Other vendors could use the API as well.

Alternative Designs

The alternative is to copy the implementation of ExpressionFormatter to our source code. However I don't see a workaround for a cascading parameter of type HtmlFieldPrefix which would probably lead to a different behavior than InputBase.

Risks

Not sure if making those classes public would lead to any risk.

[javiercn]

@akorchev thanks for contacting us.

Those are utility classes that contain implementation details that we don't plan to expose publicly, if you need similar functionality, you can grab the implementation from our codebase or create your own.

ExpressionFormatter is not something we plan to expose, neither is HtmlFieldPrefix. We will be open at exposing the current context from the Editor<T> (that is, the prefix string) so that it can be reused, but the rest is an implementation detail from the framework.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[akorchev]

Hi @javiercn,

Do you recommend we copy the implementation of ExpressionFormatter to our codebase? Any other alternatives to support the same logic for generating the name attribute?

[chrischu]

I would like something similar: #56019