Реактивность может значительно упростить реализацию надежных программ. Давайте рассмотрим, что нам нужно для её реализации…

📦 Состояния
🎬 Действия
💨 Реакции
💫 Инварианты
🌉 Каскад
🧙‍♂️ Рантайм

📦 Реактивные состояния

Прежде всего, нам нужны состояния — контейнеры, которые хранят некоторые значения.

🎬 Реактивные экшены

Сами по себе состояния бесполезны, пока мы не можем с ними взаимодействовать. Поэтому нам нужны действия для их изменения.

💨 Реактивные реакции

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

💫 Реактивные инварианты

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

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

🌉 Реактивный каскад

Красота и мощь инвариантов в том, что мы можем связать все состояния приложения в единый граф.

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

🧙 Реактивный рантайм

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

Если вы не понимаете, как это работает, реактивность покажется вам магией. Но как только вы разберётесь, это станет ещё одной технологией в вашем арсенале.

Направления реактивности

Несмотря на то, что все начинается с того, что кто-то что-то изменил, окончательное решение о том, пересчитывать ли тот или иной инвариант, может принимать как зависимость, так и зависимое состояние.

🥌 Push: проталкивание в зависимых
🚂 Pull: затягивание из зависимостей

🥌 Push: Проталкивание в зависимых

Когда зависимость изменяется, безусловно запускается реакция, которые вычисляет новые значения и записывает его в зависимые состояния. Так, например, работают RxJS, Effector и другие процедурные/функциональные библиотеки/фреймворки.

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

То есть наш граф инвариантов должен иметь возможность изменяться в процессе пересчета этих инвариантов. Это значит, что при работе по принципу push мы часто оказываемся в ситуациях, когда мы долго-долго вычисляли какое-то значение, но в итоге оно никому не понадобилось, потому что потребитель был уничтожен.

🚂 Pull: Затягивание из зависимостей

При доступе к зависимому состоянию вычисляется инвариант, который тянет значения из зависимостей (подписываясь на новые зависимости от отписываясь от старых) и возвращает текущее значение. Так работают $mol_wire, CellX, MobX и Vue.

Здесь, чисто логически, мы всегда знаем, что если вычисление произошло, значит кому-то нужен его результат. А если он не нужен, то и вычисление не произойдет. Поэтому подход с отложенным ленивым вычислением видится более практичным.

Детектирование изменений

Как среда выполнения может узнать об изменениях?

🔎 Polling: Опрос состояний
🎇 Events: Реакция на события
🤝 Links: Список зависимых

🔎 Polling: Опрос состояний

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

// иногда
if( state !== state_prev ) reactions()

Так работают, например, Angular, Svelte и React. Проблема этого подхода в том, что при каждом чихе выполняется много работы, чтобы выяснить, что почти ничего не изменилось.

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

🎇 Events: Реакция на события

Каждое состояние дополнительно хранит список функций-обработчиков изменений. При каждом изменении состояния вызываются все подписчики.

// при изменении
for( const reaction of this.reactions ) {
    reaction()
}

Это можно инициировать вручную, через сеттер или прокси. Но в любом случае состояние ничего не знает о соседних состояниях, и взаимодействие всегда одностороннее. Это сильно ограничивает возможные алгоритмы оптимизации. Также усложняет отладку, потому что выяснить, кто от кого и как зависит — целый квест.

И самое печальное, что хранение массива замыканий занимает много памяти. И с этим ничего не поделать.

🤝 Links: Список зависимых

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

// при изменении мастера
for( const slave of this.slaves ) {
    slave.obsolete()
}


// при завершении слейва
for( const master of this.masters ) {
    master.finalize()
}

В первом примере видно, что при изменении одного состояния мы сообщаем всем зависимым, что они устарели. Во втором — когда вычисление одного состояния завершено, мы сообщаем всем зависимостям, что вычисление окончено, и кэши, которые они могли хранить для повторного доступа, можно освободить. Взаимодействий может быть много, что даёт максимальную гибкость в используемых алгоритмах.

Кроме того, при отладке гораздо проще следить за прямыми ссылками между объектами, чем извлекать нужную информацию из контекстов, захваченных замыканиями.

Реактивные парадигмы

Условно существует 4 подхода к написанию кода.

🧐 Proc: Процедурный
🤯 Func: Функциональный
😵 Cell: Ячеистый
🤓 Obj: Объектный

Разные библиотеки могут смешивать их в разных пропорциях, но, как правило, есть явная склонность к одному из них.

🧐Proc: Процедурная парадигма

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

let Name = 'Jin'
let Count
let Short

setInterval( ()=> Count = Name.length )
setInterval( ()=> Short = Count < 4 )

let Short_last
setInterval( ()=> {
    if( Short === Short_last ) return
    console.log( Short )
    Short_last = Short
} )

Name = 'John'
// выводит false

Инварианты описываются примерно таким образом, например, в Meteor и Angular по умолчанию. Конечно, они не запускают пересчёт каждую миллисекунду, а более оптимально, но это не меняет общей сути: рантайм периодически перезапускает инварианты, не зная, какие состояния могут быть ими изменены. Но фактические значения этих состояний могут быть нам неинтересны, однако они всё равно будут вычислены. Поэтому этот подход всё ещё не очень эффективен.

🤯 Func: Функциональная парадигма

В разгар хайпа многие сосредотачиваются на чистых функциях, превращая свой код в головоломку…

const Name = new BehaviorSubject( 'Jin' )

const Count = Name.pipe(
    map( Name => Name.length ),
    distinctUntilChanged(),
    debounceTime(0),
    shareReplay(),
)

const Short = Count.pipe(
    map( Count => Count < 4 ),
    distinctUntilChanged(),
    debounceTime(0),
    shareReplay(),
)

Short.subscribe( short => console.log( short ) )
// выводит true

Name.next( 'John' )
// выводит false

Даже опытный стример не сразу поймёт, что делает этот код на RxJS и зачем. Но это самый простой пример, далекий от реального.

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

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

Кроме того, обилие замыканий, присущее функциональному коду, ведёт к увеличенному потреблению памяти.

😵 Cell: Ячеистая парадигма

Некоторым компромиссом между функциональным и процедурным подходом является подход с реактивными ячейками (атомами, сигналами) — изменяемыми контейнерами для одного значения, связанными друг с другом через замкнутые функции.

const Name = observable( 'Jin' )
const Count = computed( ()=> Name().length )
const Short = computed( ()=> Count() < 4 )

const Autorun = autorun( ()=> console.log( Short() ) )
// выводит true

Name.next( 'John' )
// выводит false

Обратите внимание, что реактивные инварианты не обязаны быть чистыми функциями, но обязаны быть идемпотентными. То есть они могут зависеть от изменяемого состояния, но только если оно реактивно.

Большинство современных реактивных систем построены на этом подходе. Известные представители: CellX, MobX, WhatsUp.

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

🤓 Obj: Объектная парадигма

Вопрос декомпозиции и исследуемости рантайма хорошо решается объектной парадигмой, где программа состоит из множества объектов с состояниями, связанными инвариантами в единый граф. Код в этом стиле выглядит как обычный ООП-код, но с добавлением реактивных мемоизаторов.

class Profile {

    @mem Name( next = 'Jin' ) {
        return next
    }

    @mem Count() {
        return this.Name().length
    }

    @mem Short() {
        return this.Count() < 4
    }

}

class App {

    @mem User() {
        return new Profile
    }

    @mem Logging() {
        console.log( this.User().Short() )
    }

}

const app = new App
app.Logging()
// выводит true

app.User().Name( 'John' )
// выводит false

Многие, наверное, слышали утверждение, что «инвалидация кэша — одна из самых сложных задач в программировании». В реактивном рантайме такой вопрос вообще не возникает, так что мемоизацией пользоваться легко и просто.

Этот подход кажется мне наиболее оптимальным, так как он хорошо сочетается с тем, как думает человек (а он привык взаимодействовать с объектами) и с тем, как работает компьютер (объект — это просто изменяемая структура в памяти). Рантайм чётко понимает, какой метод вычисляет какое состояние. А объектная декомпозиция облегчает масштабирование. Вот почему именно объектный стиль используется в $mol_wire как основной. И это далеко не все его достоинства, но об остальных мы поговорим в другой раз.

А пока, подписывайтесь на что-нибудь, вступайте во что-то там, и держите руку на пульсе вот этого вот.

Проголосовали 40 пользователей. Воздержались 8 пользователей.