Blazor: One-way binding with automatic expression

[mrpmorris]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

@bind-Value=Expression will automatically set Value, ValueChanged, and ValueExpression. This is a nice shortcut.

I like to use input controls for readonly data. (Reasons in Additional Context section). So, I would typically do this:

<InputText readonly @bind-Value=Model.FamilyName/>

This is fine, but when I want to display a derived property

public int Age => (Calculate age from date of birth)

I cannot use @bind because the property cannot be set. The next thing to try would be

<InputText readonly Value=@Model.Age/>

But that gives the exception

InvalidOperationException: Microsoft.AspNetCore.Components.Forms.InputText requires a value for the 'ValueExpression' parameter. Normally this is provided automatically when using 'bind-Value'.
Microsoft.AspNetCore.Components.Forms.InputBase.SetParametersAsync(ParameterView parameters)

So, finally I end up with

<InputText readonly Value=@Model.Age ValueExpression=@(() => Model.Age)/>

But this is repetitive, and when your model has many properties with similar names it is easy to bind to a different property to the one being passed as an expression. This is likely in some domains where property names are very similar (Fld102, Fld201).

And the expression is needed because, even though the property is readonly, it might have validation associated with it that must be displayed to the user...

[Range(18, int.MaxValue, ErrorMessage = "Age must be at least 18")]

Describe the solution you'd like

Add a oneway or readonly directive for @bind-

<InputText readonly @bind-Value=@Model.Age @bind-Value:oneway />

<InputText readonly @bind-Value=@Model.Age @bind-Value:readonly />

The code generator wouldn't generate code to set the value, but it would set Value and ValueExpression.

Additional context

Reasons to use readonly input controls.

1. Easily discoverable for screen readers.
2. User can tab to them.
3. Easy to select-all and copy to clipboard.
4. They truncate long content, whilst still allowing the user to scroll through and read it.

[javiercn]

@mrpmorris thanks for contacting us.

We could look into relaxing the condition to not pass/provide an expression. But I don't think this is worth a language feature like you propose and I also don't believe @bind should be used for 1 way setups. @bind is syntatic sugar over Property + Change handler and that's not a concept we want to extend further.

[mrpmorris]

@javiercn Don't make it so ValueExpression is not required, the request explains why it is still needed. i.e. models can still require validation on readonly properties (you must be 18).

The problem here isn't that ValueExpression is required - that is definitely the correct behaviour!

We all love the benefits of @bind-Value setting 3 properties all at once. I would like it to have the option to set only 2 of those properties so I can use it in readonly scenarios to save me from the repetition of setting Value and ValueExpression. Both of these should always be set and should always be the same.

The problem is that it is currently not only repetitive but can result in accidentally setting them different.

<InputText readonly Value=@Model.Fld192 ValueExpression=@(() => Model.Fld912/>
// vs
<InputText readonly @bind-Value=@Model.Fld192 @bind-Value:readonly/>

Not only is the former more typing, and repetitive, but it has an error (did you spot it?)

Could you please discuss this with the team?

[javiercn]

@mrpmorris thanks for the clarification.

Would it work if there was some way of automatically filling ValueExpression when you only provide Value? Would that address it?

[mrpmorris]

Would it work if there was some way of automatically filling ValueExpression when you only provide Value? Would that address it?

I don't think it can be done that way because someone might do this

<InputText readonly Value=@(X * 100 / y)/>

It's not good practice, but it is possible and perfectly legitimate - the problem being that ValueExpression needs to be an expression to a named identifier in order to determine its name and create FieldIdentifier instances to register validation errors against.

See FieldIdentifier.ParseAccessor

The only option I see is for the user to indicate that they want one-way or readonly binding so that Blazor knows not to generate code to set the property.