I've searched around but couldn't find answers to my questions. It may seem stupid but I just want to clarify something that may happen behind the scenes.
I know how to use data binding and Observable
s in Angular. For asynchronous data we have to use Observable
s so we can subscribe
and do something with the data, if we do that with one way binding it does not work.
My questions are:
Aren't HTML inputs also asynchronous data? And if they use one way binding... does that mean that events are wrapped in
Observable
s? Are they subscribed when data comes and we affect the value to the variable?Are also functions like
setTimeout
in relation withObservable
s?
CodePudding user response:
The one-way binding in your question regarding user inputs is actually a part of the Angular two-way binding.
From the official Angular docs:
https://angular.io/guide/two-way-binding
TWO-WAY BINDING IN FORMS
Because no built-in HTML element follows the x value and xChange event pattern, two-way binding with form elements requires NgModel. For more information on how to use two-way binding in forms, see Angular NgModel.
https://angular.io/guide/built-in-directives#ngModel
To customize your configuration, write the expanded form, which separates the property and event binding. Use property binding to set the property and event binding to respond to changes.
The NgModel directive works for an element supported by a ControlValueAccessor. Angular provides value accessors for all of the basic HTML form elements. For more information, see Forms.
https://angular.io/api/forms/ControlValueAccessor
To apply [(ngModel)] to a non-form built-in element or a third-party custom component, you have to write a value accessor. For more information, see the API documentation on DefaultValueAccessor.
The part which I guess you are interested in works by events. If the user's changing the input in the UI, an event is getting sent and another part is listening to this event and changes the value in the model. You may listen to those events too and also make the value change yourself if you want to. So you can take part in this process. If you're using Observable
s or not, it's your decision.
setTimeout()
is one of few things in modern browsers, that creates real asynchronousness. Therefore it has something to do with asynchronous calls, but not necessarily with Observable
s.
Observable
s are just a neat technique to handle asynchronous processing.