@microf

Что такое «отказ от двустороннего датабиндинга»?

Я не знаю, оффтоп это для Тостера или нет.
Собственно, Сергей Протько (Fesor) часто употребляет эту фразу, да и на многих форумах это встречал. Что это значит? Разве двухсторонний биндинг и не есть радость от всех существующих фреймворков, а-ля Angular?
  • Вопрос задан
  • 1230 просмотров
Пригласить эксперта
Ответы на вопрос 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
есть датабиндинг, observable отношение между одним компонентом и другим. Например:

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'])
}


В этом случае если каким-то чудом наш элемент вдруг поменяет содержимое (ну а вдруг?) то значение внутри модели не поменяется, оно не зависит от другого компонента.

В случае же с двусторонним датабиндингом изменения происходят с двух сторон. Грубо говоря с двух сторон стоят обзерверы которые меняют значения. И это говорит нам о том что изменения, поток данных, идут в обе стороны, потому этот вид биндингов называется двусторонним.

Сами по себе биндинги это круто, и это то что делает современные фреймворки такими крутыми - позволяют реагировать на изменение данных и обновлять к примеру view приложения, без необходимости писать огромные куски кода отслеживающие изменения - все за нас делает фреймворк.

Проблема с двусторонним дата биндингом очень простая - систему построенную с активным применением двустороннего биндинга крайне тежело отлаживать. Приведу простой пример. Предположим что у нас есть компонент A и компонент B. У компонента A есть свойство foo которое содержит какую-то строку, компонент B содержит свойство bar и у нас установлено двустороннее связывание между этими двумя свойствами.

Фреймворк гарантирует нам то, что если одно из этих полей поменяется, он поменяет другое, так что A.foo всегда будет равно B.bar. Вот только это создает такую проблему, теперь оба компонента должны учитывать что значение foo и bar могут поменяться в любой момент, и не понятно кто инициировал изменения. Спокойно можно войти в состояние когда A меняет состояние, B синхронизируется и реагирует и снова меняет состояние, тогда реагирует A, и может быть появляется какие-то другие связанные компоненты. То есть мы можем быстро и просто схватить рекурсию. Если у вас на этой основе построена бизнес логика - то вам будет крайне сложно потом поддерживать эту систему, дебажить ее ад.

Грубо говоря помимо того что дебажить эту систему становится тяжело, у нас появляется неявная зависимость между A и B, им нужно знать что они могут поменять друг дружку. А все неявное это не очень хорошо.

Что можно сделать, можно разложить двустороннюю связь на составляющие. Односторонний биндинг из A в B и навесить ивенты если один из компонентов что-то меняет. В этом случае вы всегда можете поставить бряку и точно будете знать кто что поменял. Поддерживать такую систему куда проще.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
25 нояб. 2024, в 21:54
20000 руб./за проект
25 нояб. 2024, в 21:39
3000 руб./за проект
25 нояб. 2024, в 21:34
7000 руб./за проект