Declined
Last Updated: 06 May 2020 10:03 by ADMIN
qw
Created on: 04 Jul 2019 03:20
Category: UI for Blazor
Type: Feature Request
28
Support arbitrary attributes

It would be great if the controls supported arbitrary attributes. Similar to how it is done in the native form editing controls in Blazor framework.

ASP.NET Core Blazor forms and validation

"All of the input components, including EditForm, support arbitrary attributes. Any attribute that doesn't match a component parameter is added to the rendered HTML element."
11 comments
ADMIN
Marin Bratanov
Posted on: 06 May 2020 10:03

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

Progress is here for your business, like always. Read more about the measures we are taking to ensure business continuity and help fight the COVID-19 pandemic.
Our thoughts here at Progress are with those affected by the outbreak.
Josep Ramon
Posted on: 06 May 2020 08:26

Hi Marin,

 

they are news about this? Some comments to your last post:

 

"What is the goal of having arbitrary attributes rendered in the DOM?"

Self explanatory with this two samples:

  • input type="password"
  • input maxlength="10"

I mean, how can I write an input password text box with password behavior ( save to password manager, etc ) with Telerik TextBox ?

"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"

How to add maxlenght parameter to a Telerik TextBox  wrapped in a custom component?

Also, to use a TelerikTextBox inside a custom component means to deal with EditContext, I can do it via [Parameter] public Expression<Func<string>> but is weird.

 

 

 

ADMIN
Marin Bratanov
Posted on: 28 Apr 2020 16:18

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

Progress is here for your business, like always. Read more about the measures we are taking to ensure business continuity and help fight the COVID-19 pandemic.
Our thoughts here at Progress are with those affected by the outbreak.
ADMIN
Marin Bratanov
Posted on: 10 Feb 2020 11:32

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

 UI for Blazor
ADMIN
Marin Bratanov
Posted on: 13 Oct 2019 13:11

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

 UI for Blazor
Robert
Posted on: 13 Oct 2019 12:33
Any update on this?
ADMIN
Marin Bratanov
Posted on: 29 Jul 2019 08:13
Hello,

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.


Regards,
Marin Bratanov
Progress Telerik UI for Blazor
qw
Posted on: 29 Jul 2019 06:03
Hi Marin,
I tried this new feature (Attribute splatting and arbitrary parameters), and out of box it does not work. Obviously, it must be explicitly implemented inside component, something like this:
<input id="useAttributesDict"
...
       @attributes="InputAttributes" />

@code {
    [Parameter(CaptureUnmatchedValues = true)]
    private Dictionary<string, object> InputAttributes { get; set; }
}

So, what your plans in this way?
ADMIN
Marin Bratanov
Posted on: 04 Jul 2019 10:43
Hi,

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.


Regards,
Marin Bratanov
Progress Telerik UI for Blazor
qw
Posted on: 04 Jul 2019 08:59

Maybe for complex controls, such as Grid, DropDownList, arbitrary attributes are not so relevant.
In my case, I needed the "form" attribute for the submit button, which is outside the form. In the EditForm control, I can to add an arbitrary attribute "id", but in TelerikButton I could not add an arbitrary attribute "form". So, as workaround, I had to use the HTML <button> with the styles generated by TelerikButton.

<TelerikButton
IconClass="oi oi-check"
Primary="true"
Class="k-flat"
OnClick="@Save"
Enabled="@CanSave"
form="???"/>

<button
class="k-flat k-button k-primary @(CanSave ? null : "k-state-disabled")"
disabled="@(!CanSave)"
type="submit"
form="item-card-form">
<span class="oi oi-check"></span>
</button>


Arbitrary attributes can be useful in other cases, for example, the "autofocus" attribute on editing elements. Also in the TelerikDropDownList "id" attribute would be useful so that you can use <label for>.

ADMIN
Marin Bratanov
Posted on: 04 Jul 2019 05:37
Hello,

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.


Regards,
Marin Bratanov
Progress Telerik UI for Blazor