I have a question about the difference between Angular 2 two-way and one-way data binding. As I understand, one-way data binding is used for data that flows from parent to child. However, if the source of the binding is a reference to an object, the modifications made by the child are reflected on the parent (through the reference). So how is this different from two-way data binding? Or do I misuse one-way binding, and should use two-way when the child modifies the data?
Thanks
Two way Data binding is Between View and Controller ...
In Simple Words
Two Way
Changes made in view will reflect in Controller
Changes made in Controller will reflect in View
One Way
Once you set the value it will not affect the View or Controller for further changes
You start to have issues with one way bindings when you bind to collections or objects. As you have said, one way binding to a reference doesnt project you from modifying the referenced object as the binding is only shallow, and reflects the value of the reference.
The solution to this is to attempt to use immutable types. As changes to immutable types produce a new reference, this will make one way bindings update every time your object changes.
There are a number of ways to acheive this, from building your own immutable types, using immutable-js, or trying to follow the flux pattern (or using something like redux)
Related
I know this is an old and 100 times-answered question, but things are getting more complex with the latest releases, thus causing me a lot of confusion.
I'd like to know what is the difference between the four currently available ways to declare a data binding for an attribute in a directive.
Specifically:
# Text binding
= Two-way binding
& Method binding (although some call it one-way binding)
< One-way binding
I'm interested in particular in the difference between the last two, given that they seem to have overlapping functionalities and I really can't tell the difference and the advantages of one against the other.
# Text binding:
This is used if we want to provide any static text to each instance of our directive. For e.g., any title or specific style/property component that needs to be passed to custom directive that is used to create a dialog.
= Two-way binding:
This is our normal angular two way data binding. For e.g., any live data update in a dialog or any user input (checkbox, radio etc.) can be achieved using this.
& Method binding:
As the name suggests this is primarily used for calling methods defined in the parent controller from the directive. It can also be used to evaluate a expression and bind the result to the directives scope. Typical usage might be responding to user events like when the user closes the dialog.
< One-way binding:
This I guess was introduced for higher performance situations, where we need not any updates from the directives scope to reflect on the parents scope. Typical usage scenario may be when we need to pass title, style, dialog configuration (modal/non modal, etc.) via a variable defined in the parent scope. Since such data are mostly not changed in the scope of the custom directive (our case dialog), one way binding would have a higher performance than a double binding. This is because angular watch cycle needs to monitor only the parents scope variables and not the directives one-way binded variables.
Note: I am not a expert in AngularJS and the answers above are best to my knowledge. They might be wrong in the view of a experienced Angular guy. Please pardon and correct me if there are any mistakes.
Official docs: https://docs.angularjs.org/api/ng/service/$compile#-scope-
Here is some information on the new one-way binding for isolate scope.
From GitHub:1
feat($compile):
add one-way binding to the isolate scope definition
This change allows the developer to bind an isolate scope / controller property
to an expression, using a < binding, in such a way that if the value of the
expression changes, the scope/controller property is updated but not the
converse.
The binding is implemented as a single simple watch, which can also provide
performance benefits over two way bindings.
Closes #13928
Closes #13854
Closes #12835
Closes #13900
Loosely said, the various components in a MVVM pattern are
Model: this represents the data send by the server and sent back to the server. this contains no state related to display of the UI
ViewModel: this is constructed from one or models. this contains state meant for UI manipulation (is the button enabled or disabled). all logic meant for UI manipulation is stored here. this layer has no dependency on any UI framework (no jQuery calls)
View: this has tight coupling with the UI framework/underlying UI controls. One view observes one and only one view model. A view model can be observed by one or more views. The view is responsible for doing two-binding with the view model.
A presenter/coordinator: While not a part of the traditional implementation, in its absence the view model ends up with way too much responsibility. This guy helps coordinate making ajax calls (get/post), listening to events on the global event aggregator etc
Standalone Backbone has no concept of view models and data binding. In that scenario, the data returned by the server can be modelled as Backbone.Model objects. The bindings are done manually and a POJO can be used for view-model syncing.
If I wish to use Stickit for data binding, it appears that the view model needs to be an instance of Backbone.Model. Chiefly because the bindings work within the context of a Backbone.View and a Backbone.View expects a Backbone.Model object to be present as a property of the view. Also, a Backbone.Model raises change events and what not. I assume it will be difficult to observe a POJO. Again, this is my understanding from reading the Stickit docs. Please correct me if I am wrong.
A Backbone.Model has other methods on it that don't make sense from the point of view of a view model, like save, fetch etc. I was reading up on another mvvm library, Knockback. It can transform a Backbone.Model into a Knockout.js view model. Instead of passing in a full fledged Backbone.Model, it can also accept any POJO that has get/set methods and raises change events when the properties have changed.
Does Stickit have a similar contract wherein I can pass in a POJO that has get/set methods and raises change events? What is the recommended usage?
There's nothing in the source of Backbone.Stickit that requires that the model actually be an instance of Backbone.Model. So, it does appear that Stickit just needs some object that supports the contract provided by Backbone.Model--the various applications of set(), get() and on() are all I think you need.
Take a look at Stickit's test suite. If you wrote your own model API that passed that those tests (by replacing Backbone.Model with your own implementation in testScaffolding.js--and presuming the tests are thorough--then you should be able to use that model with Stickit.
EDIT: I may not have directly addressed the question. Stickit only requires that you use it in a Backbone.View, and that that view has either a model, or some other object specified by the optionalModel parameter you can pass to the stickit() function, that meets the contract provided by Backbone.Model.
I have a parent view with parent model, and a child view.
I would like to pass a reference to part of the model (a collection) to the child model, so the child model can monitor this for changes and react accordingly.
I'm not sure about the best way to do this - possibly one of these approaches?
Pass whole model : I don't want to do this, as the model contains a
bunch of stuff that the child shouldn't know about.
Pass part of the model : I don't think this is possible... if I use
this.model.get('thesubpart'), I think I will be passing a value, not
a reference.
Bind the child event in the parent view : is this the way to go? I'm
not sure how I would go about doing this.
Your question is a little bit confusing, but I think you want a child model to react to something happening in a parent model, though I'm not sure if the parent is a collection or a single model itself.
The preferred way to do this is through events (i.e. parent.on('change', child.handleParentChange), where handleParentChange is a function defined on the child model. Since you seem to be interested in only a specific attribute change, you could bind to the more specific "change:thesubpart" event.
There are different ways to do this, such as an event aggregator, but the general idea is the same. Be careful of zombies, though. If the parent outlives the child, it will keep the child in memory because of the binding (an advantage of the event aggregator, if implemented correctly).
In my WPF app, I am using MVVM. I am reading from an XML file, deserialize it to an object model and keeping it in memory.
XML File->BusinessObjectModel(Model)->ViewModel
Whenever the viewmodel needs the model I will provide it from the memory.My problem is when I use the model elements in the views it is updating the model in memory(obviously!). I dont want to do that, I want the model updated only when the user clicks OK in the view(or dialog). How is it usually achieved? Should I only provide the viewmodel a clone of the model and not the original reference?
Editing a clone of the model object would solve the problem, as you suggested.
Another approach would be to have the property bindings use an UpdateSourceTrigger of Explicit. Upon clicking Save, you would programmaticcally call UpdateSource on each binding expression. This requires some extra code, which would belong in the View's code-behind since it is code that manipulates UI elements.
Also consider having a property on your VM for each property exposed in the View, where the backing field of the VM property is not the wrapped Model object's corresponding property. When the user clicks Save, you could then assign each property from the VM to the Model object. Naturally the controls in the View would be bound to the VM properties, not the Model properties. This is effectively like having a clone, without the extra baggage of supporting cloning in the Model layer.
I'm not suggesting that any of these options are better or worse. It all depends on the context in which they are used.
Problem Statement
I'm writing a very basic WPF application to alter the contents of a configuration file. The data format is an XML file with a schema. I want to use it as a learning project for MVVM, so I have duly divided the code into
Model: C# classes auto-generated from xsd.exe
View-Model: View-friendly representation of the Model.
View: Xaml and empty code behind
I understand how the View-Model can make View-binding a breeze. However, doesn't that leave the View-Model <-> Model semantics very awkward? Xsd.exe generates C# classes with arrays for multiple XML elements. However, at the V-VM level you need Observable Collections.
Questions:
Does this really mean I have to keep two completely different collection types representing the same data in coherence?
What are the best practices for maintaining coherence between the Model and the View-Model?
I'm not a big expert, but I think that is the case yes. The general idea is indeed to propagate change between the view and the viewModel via Binding, and then between the ViewModel and the Model via events (in the Model -> ViewModel direction) or dependency (in the other direction).
I don't know how standard that is, but my understanding of MVVM is that the ViewModel should hold a reference to the model so that when the user modifies the view, the ViewModel should call the appropriate code on the model. The other way round, the Model should raise events when modified, and the ViewModel should update itself accordingly (the ViewModel being an observer to the model).
#Does this really mean I have to keep two completely different collection types representing the same data in coherence?
I think yes. It's pretty boring, but it works quite well. Hopefully, in the future we will have also a code generator to create the ViewModel part.
Karl is working on that: http://karlshifflett.wordpress.com/mvvm/
You need clearly ObservableCollections at the viewmodel so, yes, you will need two
completely different collection types in the model and in the viewmodel.
I have done an article about doing undo / redo in MVVM where you can find a possible solution to this. It uses what I call the MirrorCollection: an ObservableCollection derived class witch automatically obtains his items from a List (the list of the model).
I think it is an interesting solution, you can find the articles here
Part 1: Using the Viewmodel pattern to provide Undo / Redo in WPF
Part 2: Viewmodelling lists (here is the MirrorCollection definition)
Expose Events or delegates in Model and hook to the same in ViewModel, when ever values in the model changes notify to viewmodel via event or delegates and from Viewmodle you can update the UI.
If you want to update it from view model to model as simple as that just call some method pass the new values