What are the exact demerits of two way data binding?
Functional programming and libraries like React recommend unidirectional data flow. My question is what are the exact demerits of two way binding and why should one always use unidirectional binding?
The problem in two way data binding (MVVM) and MVC is that they have many to many dependency between models and views . A model can update a view which can update a model which can update another model and there can be a infinite loop of cascading updates.
In a talk Jing Chen ( Creater of flux ) said - "There is just an explosion of command flows, and it is hard to tell if there is any infinite loop that might be causing a cascading effect."
In unidirectional data flow action updates stores which updates views . So if there is a error it would be easy to track which action caused it . Unidirectional data flow is more predictable .
Basically what Mayank said. I have nothing more to add on that level just want to give a concrete example with Angular. Angular became super-popular exactly because of it's two-way binding. However it brings a lot of performance problems.
When you think about it for a bit. How can a framework know that a value has changed? Really it boils down to 2 ways. You can do it through a setter, which is already half-way towards unidirectional data flow...or you can do dirty checking. Dirty checking means constant checking if the value has changed at any point when it could have changed. That's a ton of work all the time and most of it is pointless.
This is why Angular apps start becoming sluggish when you hit ~ 2000 bindings on a page. This sounds like a huge number but it doesn't take much to get there. Almost any medium sized app will easily hit 2000.
On my very minimal setup I have one of the servers replicating only downstream and that serves as the backup.
Works on my basic setup of three replica sets.