Hello Lou,

I agree that attribute spatting can provide flexibility in certain scenarios. I am also sorry if our components are giving you a hard time by not having this feature.

Here is a recent forum thread that describes one more point of view for our decision to not support attribute splatting. See Joana's last comment from March 3. In short, it boils down to performance, clean API and source code, and parameter conflict avoidance.

On a side note, I see that you have used our support service only once in the last 3+ years. If you ever hit a roadblock, consider checking with us - we may be able to help you.

Regards,
Dimo
Progress Telerik

Hello Josep,

Said shortly - the status of the item is "Declined" which means we will not implement arbitrary attributes (attribute splatting). You can find a legend of the statuses here: https://feedback.telerik.com/blazor/status-info

The password type of the textbox will be implemented through the other item I linked: https://feedback.telerik.com/blazor/1416922-add-to-teleriktextbox-more-parameters-such-as-type-autocomplete-required-readonly. I've added your Vote for it and you can click the Follow button to get email notifications.

MaxLength is a validation that is up to a form and is already available: https://docs.telerik.com/blazor-ui/common-features/input-validation. If you want to implement custom logic without a form, the TextBox events will let you receive the user input, check its length or other specifics and either alter it, or avoid setting it to the model field altogether.

Using our component in a custom (wrapping) component does not necessarily require an expression or an EditContext, it depends on the implementation. For example, exposing a Value+ValueChanged EventCallback from your custom component will let you do two-way binding directly in a form. Adding layers of wrapping will always bring some extra complexity, this would happen if you want to wrap a simple <input /> in a custom component - you'd have to take care of some plumbing.

Regards,
Marin Bratanov
Progress Telerik

Hello everyone,

The requests for this have so far centered around features in the <TelerikTextBox>. This is something we will do with dedicated parameters in the following item: https://feedback.telerik.com/blazor/1416922-add-to-teleriktextbox-more-parameters-such-as-type-autocomplete-required-readonly. The few requests for features on the button are available too (class, type, enabled).

For more complex components, such a feature does not make sense as it is ambiguous and undefined. At the same time, attribute splatting has a performance cost that we should not ignore.

Ultimately, this is a feature suitable for direct HTML handling, but not suitable for a component vendor like us.

With all that said, this feature is now marked as "declined" and we will not be implementing it.

Regards,
Marin Bratanov
Progress Telerik

Hi all,

As a first enhancement in this regard, our 2.8.0 release will provide Id parameters for all input type components (Textbox, NumericTexbox, DropDownList, and so on) so you can easily attach labels to them (<label for="theIdParamString">lorem ipsum</label>).

Regards,
Marin Bratanov
Progress Telerik

Hello,

If you click the Follow button at the top of the page, you will get email notifications when there is an update on this task.

Regards,
Marin Bratanov
Progress Telerik

Attribute splatting/arbitrary attributes must be implemented explicitly in a component in order to work. We don't know yet how/if this will be done in our components. The MSDN sample has very simple markup - just one tag. In our case, we have a much more complex HTML structure, and some attributes will need to go one one element, others - to another. Considering this, we will need to collect more feedback and consider this in detail before jumping to a decision.

I have just found the following feature that will ship with Preview 7: https://github.com/aspnet/AspNetCore/issues/5071 which may allow such arbitrary attributes without any need for implementation on our side. We should wait to see and evaluate its behavior when it ships, so we can determine whether it will make sense for some/all components, or we would have to implement some of those attribute explicitly. Until then, I am keeping this item on "under review" because we can't say for the time being what the approach will be. Perhaps you would be able to define those attributes immediately, or perhaps we would have to implement Parameters for them in the end.

The components from the article map directly to one DOM element, and as such their rendering is extremely simplified. Our components, on the other hand, have a much more complex structure in the DOM and arbitrary attributes are ambiguous - some make sense for the wrapping element (like something like data-*, however bad a practice that would be in Blazor), others make sense for an actual <input> (like autocomplete, type); and yet others would probably be even more difficult to determine for more complex components.

I suspect this is the reason that, at least for the time being, such a built-in feature of a Blazor component is not really offered out of the box by the framework, but is left for custom implementation through SetParameters in each individual component: https://github.com/aspnet/Blazor/issues/735. This implies that the component needs to know how to map each arbitrary attribute to the DOM (which is, obviously, relatively easy for single-element components like the native validation components). 

So, while we could theoretically rewrite our code to adopt a similar approach, how should we know where to render each attribute the developer provides - we don't have control over your application code to know what attributes may come in and what sense they make, and you don't have control over our components code to determine rendering?

That said, I think that the most important questions is - What is the goal of having arbitrary attributes rendered in the DOM? An actual component feature would require a real, targetted Parameter so it would not be arbitrary anymore. We should also consider that you are not advised to tamper with the DOM in Blazor because the framework does the DOM changes. 

For the time being I could suggest you implement your own custom attribute rendering in a component for its wrapping element, and inside that element you could use our components as with a regular component. Would this let you render the desired content in the DOM and still use our tools?

All that sid, I can suggest you Follow and perhaps add your Vote for this other feature request where the common input attributes are to be exposed: https://feedback.telerik.com/blazor/1416922-add-to-teleriktextbox-more-parameters-such-as-type-autocomplete-required-readonly. At the moment, I can't really think of another component that needs such attributes.