Зачем быстрая реактивность за пределами DOM: ответы на вопросы и знакомство с Raph

[DmitryKazakov8]

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

Но для остальных задач есть еще важные нюансы - DX выходит на первый план. То есть системы с .get(), .set(), .value, или просто функции value(), value(newValue) для чтения и установки значений часто неудобны: затрудняются миграции на другие подходы, возникают лишние ошибки при написании, увеличивается когнитивная нагрузка и т.п. Также возможны разночтения в плане какая операция будет мутабельной, а какая иммутабельной и сменит ссылку объекта / массива.

Тот же MobX максимально близок к нативному формату - для большинства случаев к нативным объектам и классам достаточно добавить makeAutoObservable, не меняя остальной код, то есть работают arr.slice, arr[0] = newItem, Object.assign, глубокие мутации obj.a.b = 1, легкая сериализация / десериализация в JSON.

В реальных проектах часто это намного важнее лишнего килобайта в бандле и дополнительной миллисекунды при расчете графа на 10к элементов (условно). Но для разработки конкретных сложных компонентов и библиотек действительно можно получше сбалансировать компромиссы и выбрать по целевым метрикам наиболее подходящую либу, благо через ИИ можно быстро это проверять, а количество библиотек реактивности на рынке огромное.