Throw an error when templating braces are used to pass attribute values

Hi!

I’ve been using Angular for a few years now, and I regularly come across projects where previous developers used the templating braces to pass attribute values, doing awful sins such as:

<img src="{{myPicture}}" />

Instead of

<img [src]="myPicture" />

I’m starting to seriously pull my hair off by having to fix a ton of occurrences of the error described above, and for this reason I think it’d be really neat if Angular was just throwing an error at build time, runtime or both, preventing inexperienced developer to misuse templating braces.

Thanks!

[Airblader]

The problem here is that we inherit projects developed by other teams from other companies, and so they’re not my coworkers, we just get the codebases as is and have to deal with it.

That’s just a universal fact of software development, and I promise you – it won’t change no matter what. There’s more to quality than a framework can enforce. 😃

having templates written this way doesn’t help with code readability

This is entirely subjective. The very people who write the code like this probably think it’s easier to read (based on my, also subjective, experience). Especially when there’s some concatenation going on like in the following example:

<foo bar="hello-{{ worldName }}"></foo>
<foo [bar]="'hello-' + worldName"></foo>

Yes, I also still prefer the second version, but I find it hard to argue that one is truly more readable than the other.

having templates written this way doesn’t help with code […] maintainability

I fail to see how either one is more or less maintainable than the other(?)

A nice codebase (by my standard) is usually made of functions which aren’t longer than 25 lines and 80 chars long.

This is again just opinion, and in fact a controversial topic. Other people see 80 characters as a relict of software development from two decades ago. If you have these standards, enforce them in your projects. Other people, teams and companies have other standards or focuses (such as easy for newcomers, fast iterations and prototyping, …).

You could also write a simple tslint autofixer that you run on the projects you inherit. 😃

You save 4 chars with the second option by avoid using excessive braces.

Oh, the humanity… 😃

^{In an AoT build this is not even code that will be shipped down the wire.}

Of course you could set this inside your TS class, but some developers prefer setting this in there HTML template which I respect.

Why? By my standard, this is a bad practice, so why should this be allowed? 😉

To be honest, I wonder if using the templating braces to bind inputs could result into security issues, I’d have to dig a little more into that to tell for sure.

I see no reason why it would, a lot of the underlying process is still the same. I won’t count “security” as an argument unless there’s an actual example – and even then, it could (and should) be fixed without dropping interpolation support.

---

Personally, I would do a cost versus benefit consideration. So far I haven’t heard any objective benefit to dropping interpolation support. On the other hand, the cost is extremely high: it’s a breaking change which, according to your own statements, would affect a lot of code. To be fair, this could likely be automigrated; but I doubt the wider development community would understand the necessity of the change.

[JoostK]

This would be something for a tslint rule, not the framework itself. From a framework perspective, the given syntax is perfectly valid, it’s even documented like that. The thing is, img#src is supposed to be a string attribute so using interpolation to bind a string seems fine to me.

Feel free to elaborate on why you feel it is “awful” to use this syntax. FWIW, I do share your preference regarding brackets vs. interpolation, but to me it’s entirely subjective.