What is "opting out of two-way databinding"?

Question

JavaScript

I don't know if this is offtopic for Toaster or not.
Actually, Sergei Protko (Fesor) often uses this phrase, and I have seen it on many forums. What does it mean? Isn't two-way binding the joy of all existing frameworks, a la Angular?

Answer 1

there is databinding, an observable relationship between one component and another. For example:

var model = {
    title: 'Some Title'
};

function view(container) {
    var el = container.querySelector('[data-bind="title"]');
    // следим за изменениями
    Object.observe(model, (changes) => {
        if ('title' === changes.name) {
            // обновляем при изменении связанное значение у другого компонента
            el.innerHtml = model.title;
        }
    }, ['update'])
}

In this case, if by some miracle our element suddenly changes the content (well, what if?), then the value inside the model will not change, it does not depend on another component.
In the case of two-way databinding, changes occur on both sides. Roughly speaking, there are observers on both sides that change values. And this tells us that changes, the data flow, go both ways, because this type of binding is called two-way.
Bindings themselves are cool, and this is what makes modern frameworks so cool - they allow you to react to data changes and update, for example, the application view, without having to write huge pieces of code to track changes - the framework does everything for us.
The problem with two-way data binding is very simple - a system built with active use of two-way data binding is extremely difficult to debug. I will give a simple example. Suppose we have component A and component B. Component A has a foo property that contains some string, component B contains a bar property , and we have a two-way binding between these two properties.
The framework guarantees us that if one of these fields changes, it will change the other, so it A.foowill always beB.bar. But this creates such a problem, now both components must take into account that the value of foo and bar can change at any time, and it is not clear who initiated the changes. You can safely enter a state when A changes state, B synchronizes and reacts and changes state again, then A reacts, and maybe some other related components appear. That is, we can quickly and simply grab the recursion. If you have business logic built on this basis, then it will be extremely difficult for you to maintain this system later, debug its hell.
Roughly speaking, in addition to the fact that it becomes difficult to debug this system, we have an implicit dependency between A and B, they need to know that they can change each other. And everything implicit is not very good.
What you can do is decompose the two-way communication into its components. One-way binding from A to B and hang events if one of the components changes something. In this case, you can always put a break and you will know exactly who changed what. Maintaining such a system is much easier.