Angular Form Controls: The Bad Parts

The prior articles discuss the goodness of Form Controls, this post discusses the badness.

The Bane Of Immutability
On paper and in theory and as a solution for a weakly typed language such as Javascript. Immutability is the solution for changing a single property of a model, or a single record of an array.

The most logical reason this came about was that Javascript programming styles caused major deeply rooted issues. One particular implementation would go like this:

let person ={
   lastName:'Peterson',
   fistName:'Jon'
}
//then later in some other module

let person={
 lastName:'Peterson',
 firstName:'John',
 ssn:'111223333',
}
//has an added ssn field

Not a problem in and of itself; however, if either of the modules had a person as an input parameter; which one is the correct one? Answer: There's no way to know except the context of how it's used. What if the keys were not spelled the same? What if the datatypes were different?

This is a major potential problem with cohersion! This bug will only show up when a routine that relies on a property finds it to be undefined or null, when in fact it was a dependency. It's a runtime error which may lay dormant for a long time. If there are 1,000 places in code that are creating on the fly person objects it will take a while to find it.

What does that have to do with Immutability?

Let's create a rule that says there's only two times we can set an object's true value. 1) At the start and 2) Just before the save, update, delete on the backend. Never mind the fact that there could be 20 steps in between and seconds or even minutes which lapse in between (half baked states).

But there are no half-baked states, so we have to make another rule that says each minor change can only be done on a new object. In essence we have to deep clone the object and only change one property at a time.

This is a pattern created due to an inferior language implementation. It's the very same argument Javascript purists make about OOP patterns (created due to the handicapped nature of strong typing).

No Two Way Binding

We've documented the Angular directive of we no longer support two-way binding when using form controls. Indeed it's all true as our tests in Angular 10 have proved.

The DOM Allows Two-Way Binding

The most profound realization of this step backwards is that no such restriction appears within the DOM itself. Any HTMLElement in the DOM immediately changes value any time an input is changed. It doesn't matter how many properties are there because each element doesn't recognize the concept of binding multiple properties. Each element is an atomic value wholly contained and independent of any other element.

Angular becomes Opinionated Again

The demise of AngularJS was that it hijacked Javascript to favor it's own extreme opinion of how things should work.

It appears that they are starting to do the opinionated thing again in certain parts of their framework.

This time it may not be as bad as before because they did not hijack the language itself, just the way we are expected to use the language.

Summary

We may need to reject FormControls for it's lack of two-way binding. Yes we can make it work, but the effort is odd. The main question being "Why do we have to change our view of what a model really is all about, just because you decided the better way?" "What can the DOM do it be we can't?"

BTW, I purchased Crockford's massive Javascript book when it first came out. Of all the programming books I've purchased over the years, his was one of the worst in my opinion. It rambled, it rolled, it rattled, it jumped the tracks. It was a train wreck to me, but I was forced to ride it. I never used it as a desk reference except in the very early days. I threw it away about 5 years ago as it was taking up space.

JWP2020