Make @bind-value easier to setup in non-razor syntax

[linkdotnet]

Motivation

Components, especially form-based controls like InputText, InputDate, ... are often used like this:

<InputText @bind-Value="_myparam"></InputText>

For a test we have to setup the following 3 properties to make it work:

• Value
• ValueChanged
• ValueExpression

If a user uses the razor syntax it will work out of the box like this: Render(@<InputText @bind-Value="myProp"></InputText>); but it will not work with "plain old csharp syntax". We have to do the following:

string value = "";
RenderComponent<InputText>(p => p
    .Add(s => s.Value, value)
    .Add(s => s.ValueChanged, s => value = s)
    .Add(s => s.ValueExpression, () => value));

Possible solution

So we will introduce a new helper function which will setup all the 3 calls in one operation:

string value = "";
RenderComponent(p => p.AddTwoWayBinding(value));

There is no selector as we only support Value as valid binding property name (see more under out of scope).

There might be a Value but no ValueExpression and or ValueChanged hence we throw an exception. The new API is really limited to the default use of @bind-Value.

Remarks

With that @bind is included as well as is a simplification of @bind-Value. What is out of scope is to support other events like this:

@bind-value="userName" @bind-value:event="onblur"

Out of scope

Instead of the change event the blur event is taken. As this is anyway the minority of cases the user has to fallback to setting up all of the 3 required properties/methods him or herself (see the motivation in the beginning).

Also more abstract you can have bind-{SomeName} which translates to {SomeName}, {SomeName}Changed and {SomeName} Expression but to be honest I would not address that.

Another point would be "native" HTML controls which support "bind-value" with lowercase v in value.This is anyway something we don't have to support. The user can't just render native HTML elements.

[egil]

A few thoughts:

1. I would probably just call the method Bind, e.g. RenderComponent<InputText>(p => p.Bind(p => p.Value, value));. The term is familiar to Blazor devs, so I find it expressive enough.
2. Can we get two way binding working similar to how it is in the razor case. In razor code, the razor compiler generates a lambda that subscribes to the ValueChanged property and sets the field. Could the Bind method take an lambda as input that enables this? E.g. RenderComponent<InputText>(p => p.Bind(p => p.Value, value, updated => value = updated));
3. Bind could also have 3rd parameter that corresponds to the ValueExpression parameter.
4. Bind could use reflection to detect if there is both a Value, ValueChanged and ValueExpression parameters, and give correct guidance accordingly.

With all that in mind, are we actually saving the user from typing things?

Is this better:

string value = "";
RenderComponent<InputText>(ps => ps
  .Bind(
    selector: p => p.Value, 
    value: value, 
    valueChanged: updated => value = updated, 
    valueExpression: () => value));

Or is this actually good enough:

string value = "";
RenderComponent<InputText>(p => p
    .Add(s => s.Value, value)
    .Add(s => s.ValueChanged, s => value = s)
    .Add(s => s.ValueExpression, () => value));

[linkdotnet]

Your "good enough" is better for sure.

Can we get two way binding working similar to how it is in the razor case. In razor code, the razor compiler generates a lambda that subscribes to the ValueChanged property and sets the field. Could the Bind method take an lambda as input that enables this? E.g. RenderComponent(p => p.Bind(p => p.Value, value, updated => value = updated));

I would not go with a 2nd or even 3rd parameter as it defeats the purpose. We can always derive from p.Value that there are these 3 objects involved (Value, ValueExpression and ValueChanged).

But maybe you are right and it is totally enough to extend the documentation how to setup two-way bindings.
Then we don't have to think around all the corner cases there are.

[egil]

I would not go with a 2nd or even 3rd parameter as it defeats the purpose. We can always derive from p.Value that there are these 3 objects involved (Value, ValueExpression and ValueChanged).

Not sure I understand. How would we derive what the base parameter is in a pair/treble (e.g. Value, ValueChanged)? A component could easily have multiple sets of these, e.g. ValueFoo and ValueBar that each have their sibling ValueFooChanged and ValueBarChanged.

But maybe you are right and it is totally enough to extend the documentation how to setup two-way bindings. Then we don't have to think around all the corner cases there are.

I think that is probably a good first step 🙂. Also perhaps a section/recipe on how to test InputXXX components from the Blazor team. What section to place these in I am not sure, Perhaps a "Recipes" sections?

[linkdotnet]

Not sure I understand. How would we derive what the base parameter is in a pair/treble (e.g. Value, ValueChanged)? A component could easily have multiple sets of these, e.g. ValueFoo and ValueBar that each have their sibling ValueFooChanged and ValueBarChanged.

Yeah sorry we need 2 parameters. The Expression and the initial value.

If a user does the following:

RenderComponent<Foo>(p => p.Bind(s => s.Bar, someValue));

We know to do this internally (of course via Reflection):

var someValue = "Test";
RenderComponent<Foo>(p => p
 .Add(s => s.Bar, someValue )
 .Add(s => s.BarChanged, c => someValue  = c)
 .Add(s => s.BarExpression, () => someValue);

Of course we would have to throw an exception in this case: RenderComponent<Foo>(p => p.Bind(s => s.Bar, "const")); because constant expression don't make sense.

The user has multiple @bind's? No problemo:

RenderComponent<Foo>(p => p
.Bind(s => s.Bar, someValue)
.Bind(s => s.Value, anotherValue));

They will follow the same rules as above. I hope I could make my point clear. From a user point of view I want to have the same amount of effort as in the real code so it feels natural. Of course you could argue to use the razor syntax then in the first place, but some IDE's have trouble with that.

[egil]

We know to do this internally (of course via Reflection):

Is that possible? I would love to see a prototype of it.

[linkdotnet]

I will give it a shot

[linkdotnet]

I fiddled around and have a first idea.

The usage would be as follows:

[Fact]
public void GivenTwoWayBindingWhenUpdatingComponentPassedVariableShouldAlsoBeUpdated()
{
	var bindTarget = "target";
	var cut = RenderComponent<InputText>(
		p => p.Bind(i => i.Value, () => bindTarget));
	cut.Find("input").Change("test");
	
	bindTarget.ShouldBe("test");
}

Here the rough implementation:

public ComponentParameterCollectionBuilder<TComponent> Bind<TValue>(
	Expression<Func<TComponent, TValue>> parameterSelector,
	Expression<Func<TValue>> valueSelector)
{
	var (parameterName, _, _) = GetParameterInfo(parameterSelector);
	
	if (valueSelector.Body is ConstantExpression)
		throw new ArgumentException("Can't use a two-way binding with a constant value", nameof(valueSelector));

	var changedName = $"{parameterName}Changed";
	var expressionName = $"{parameterName}Expression";

	if (!HasPublicParameterProperty(changedName))
		throw new InvalidOperationException($"Could not find a public parameter with the name {changedName} which is required for the bind directive.");

	var valueFunc = valueSelector.Compile();
        var underlyingValue = valueFunc.Invoke();
	var parameter = AddParameter(parameterName, underlyingValue);	

	var eventCallback = EventCallback.Factory.Create<TValue>(this, v => underlyingValue = v);
	parameter.AddParameter(changedName, eventCallback);

	return !HasPublicParameterProperty(expressionName)
		? parameter 
		: parameter.AddParameter(expressionName, valueSelector);

	static bool HasPublicParameterProperty(string parameterName)
	{
		var type = typeof(TComponent);
		var property = type.GetProperty(parameterName);

		return property != null && property.GetCustomAttributes(inherit: true).Any(a => a is ParameterAttribute);
	}
}

The problem is when passing in primitive / immutable types like string, int, ... as I can't capture the reference via a lambda from an Expression<Func<TValue> I don't have a chance to easily modify them.
So the test fails reporting that bindTarget is still "target" instead of "test".
I also can see that the ValueChanged event is triggerd. Hopefully I can make that work but that would be roughly my idea to tackle the @bind directive.

[egil]

The problem is when passing in primitive / immutable types like string, int, ... as I can't capture the reference via a lambda from an Expression\u003CFunc\u003CTValue> I don't have a chance to easily modify them.

Yeah, I think you will see that issue with all pass-by-value types.

Still think the best we can do is something like this:

string value = "";
RenderComponent<InputText>(ps => ps
  .Bind(
    p => p.Value, 
    value, 
    updated => value = updated));

Ps. this is also similar to the code the razor compiler generates when we use @bind in a .razor file.

[linkdotnet]

Okay I see. I made it work with that implementation:

public ComponentParameterCollectionBuilder<TComponent> Bind<TValue>(
	Expression<Func<TComponent, TValue>> parameterSelector,
	TValue initialValue,
	Action<TValue> changedAction)
{
	var (parameterName, _, _) = GetParameterInfo(parameterSelector);

	var changedName = $"{parameterName}Changed";
	var expressionName = $"{parameterName}Expression";

	if (!HasPublicParameterProperty(changedName))
		throw new InvalidOperationException($"Could not find a public parameter with the name {changedName} which is required for the bind directive.");
	
	var parameter = AddParameter(parameterName, initialValue);

	var eventCallback = EventCallback.Factory.Create(this, changedAction);
	parameter.AddParameter(changedName, eventCallback);

	Expression<Func<TValue>> expressionFunc = () => initialValue;

	return !HasPublicParameterProperty(expressionName)
		? parameter 
		: parameter.AddParameter(expressionName, expressionFunc);

	static bool HasPublicParameterProperty(string parameterName)
	{
		var type = typeof(TComponent);
		var property = type.GetProperty(parameterName);

		return property != null && property.GetCustomAttributes(inherit: true).Any(a => a is ParameterAttribute);
	}
}

A test would look as this:

public void GivenTwoWayBindingWhenUpdatingComponentPassedVariableShouldAlsoBeUpdated()
{
	var bindTarget = "target";
	var cut = RenderComponent<InputText>(p => p.Bind(
		i => i.Value, 
		bindTarget,
		s => bindTarget = s));
	cut.Find("input").Change("test");
	
	bindTarget.ShouldBe("test");
}

So there are two cases:

• We have at least Value and ValueChanged - these are the bare minimum for @bind-Value. Then Bind is just convenient because it "forces" at least something.
• Optional one can provide ValueExpression - here Bind can really help. Basically ValueExpression tells the Blazor component which type Value has in case it is null.

If you still think it would be worth it, I'll go ahead and make a PR and polish the edges a bit.
PS: You can also assign me if I should go ahead with a PR, documentation etc...