One note: it looks like all of your examples rely upon defining observable wrappers around the various properties (disabled, value, etc) and this isn't shown anywhere. If they are already available in AbstractControl I do not think they are advertised as such by Angular, and in that case you would have to be careful to rely upon something which may change in a future release.
Also, creating additional observable streams like this (although handled well with the async pipe) likely leads to [small] additional overhead (performance, memory, etc) for the application for what amounts to a semantic redesign. If you have a very large form I imagine that could be something potentially worth weighing when deciding to use or not use.
A form control gets disabled by calling disable() on it, so this just automates that. For example, the form I was working on would disable an entire form group based on the value of a certain form control, so that disabled state was downstream from that form control's valueChanges observable.
If reactive programming is just a semantic redesign compared to imperative programming, then it happens to be an extremely valuable semantic redesign. Reactive programming prevents a lot of bugs. When I rewrote the form I was working on this way, most of the bugs went away. This form had 50+ form controls and I noticed no change in performance. It was fast and it stayed fast.
Programming in a reactive style and then working in imperative code feels like going from having a laundry basket to carrying by hand and constantly worrying about dropping socks. Most of the bugs are like, "oops, forgot to reset that value in this circumstance too." Observables let you reuse the consequences of events, which means those consequences only have to be defined in one place instead of being handled multiple times.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One note: it looks like all of your examples rely upon defining observable wrappers around the various properties (disabled, value, etc) and this isn't shown anywhere. If they are already available in AbstractControl I do not think they are advertised as such by Angular, and in that case you would have to be careful to rely upon something which may change in a future release.
Also, creating additional observable streams like this (although handled well with the async pipe) likely leads to [small] additional overhead (performance, memory, etc) for the application for what amounts to a semantic redesign. If you have a very large form I imagine that could be something potentially worth weighing when deciding to use or not use.
Still, a nice technique/idea.
A form control gets disabled by calling
disable()on it, so this just automates that. For example, the form I was working on would disable an entire form group based on the value of a certain form control, so that disabled state was downstream from that form control'svalueChangesobservable.If reactive programming is just a semantic redesign compared to imperative programming, then it happens to be an extremely valuable semantic redesign. Reactive programming prevents a lot of bugs. When I rewrote the form I was working on this way, most of the bugs went away. This form had 50+ form controls and I noticed no change in performance. It was fast and it stayed fast.
Programming in a reactive style and then working in imperative code feels like going from having a laundry basket to carrying by hand and constantly worrying about dropping socks. Most of the bugs are like, "oops, forgot to reset that value in this circumstance too." Observables let you reuse the consequences of events, which means those consequences only have to be defined in one place instead of being handled multiple times.