Сегодня я хочу поговорить о React, Angular 2 и Glimmer 2. Даже не о них, а о подходах к работе с мутациями DOM.
Есть две парадигмы работы с изменениями: императивный (описываем алгоритм) и декларативный (описываем результат, к которому нужно прийти).
Императивный подход эффективен, но сложность поддержки алгоритма растет нелинейно по мере роста бизнес логики.
Декларативный подход гораздо удобнее, но в наивной имплементации он совсем не эффективный.
Это было одной из selling point React. Вы описываете компоненты декларативно, React генерирует VirtualDOM и супер эффективно его применяет.
На самом деле проблемы все еще остаются. Сравнение двух деревьев очень затратная операция.
Одно из решений — shouldComponentUpdate. Костыль для исключения некоторых веток дерева из сравнения.
Этот костыль можно свести к унифицированной функции сравнения, используя immutable data, например ImmutableJS.
Проблема в ImmutableJS в том, что при изменении одного значения меняется хеш у всех родителей, что инициирует рендер с самого корня.
Второй рецепт — инициировать изменение как можно ниже в дереве компонент, но на это должна быть заточена архитектура приложения.
Почему костыли? Смешивание бизнес логики и хуков для оптимизации в одном юните ухудшает поддерживаемость.
Я считаю, что мы должны прийти к тому, что можно писать высокоэффективные приложения без знания и использования таких вещей.
К сожалению, я не успел посмотреть на то, как эта проблема решается в Angular 2, удалось найти только статью blog.thoughtram.io/angular/2016/0…