should 2-way binding a non-L-value be an error?

[trinarytree]

this is a request for discussion, not a bug where i am certain that the current behavior is incorrect. suppose that component c 2-way binds attribute foo:

@Component(
  selector: 'c',
  map: const {'foo': '<=>bar'},
  ...
)
class C {...}

and in some template, someone tries to pass a non-L-value for foo:

<c foo="true">

currently, angular will allow this, and if, inside C, the variable bar changes, then angular will detect that the value passed is not assignable and silently ignore. but is it better to ignore or throw an exception? (and assuming the latter, probably the exception should be thrown much earlier, like when the binding first happens, not when the mutation is requested.)

advantages of ignoring: it gives a convenient way to pass an initial value without having to create a variable solely for the purpose of giving a spot for c to dump its value that we don't care about. in such a case, you may wonder why we don't just change c to make foo 1-way bound. the answer is (a) maybe someone else does care, and (b) we might not get to control the definition of c. so in this discussion we should operate under the assumption that whether foo is 2-way bound is beyond our control.

advantages of throwing: programming languages don't usually permit assignment to non-L-values, e.g.

1 = 10;  // error, in most languages

so this looks surprising. furthermore, maybe passing the non-L-value was an accident and we are silently ignoring it, e.g.

<c foo="bar()">

oops, we meant bar, but wrote bar() by accident. so seeing the error would be welcome.

there is some precedent for the "ignore" choice: when you create a checkbox in html, you might say

<input type="checkbox" checked="true">

this doesn't mean that the checkbox is always checked, just that it's initially checked. but then again, html is stupid and perhaps should not be emulated :-)

anyway, i wanted to get others' opinions on this issue.

[youssefgh]

I've been there.

I accidentally binded a literal String using Ng*Way instead of using NgAttr, result was confusing and it takes time to figure out the problem.

And some how it worked with boolean values.

I think it could be nice to see an error thrown in this case.

BTW we could use NgAttr if we don't want to use an extra var.

So much thinks for sharing :+1:

[mhevery]

We are going to redo the Form binding, and we will take this into consideration. Thanks for the write up. My initial guess is that we will change syntax so that you will not be able to express things which can not be bound to.