Порядок выполнения реактивных реакций имеет свои особенности, которые часто оставляют на волю случая. Однако давайте рассмотрим все возможные варианты…
📰 Subscribe: По времени подписки
🧨 Event: По времени возникновения события
📶 Deep: По глубине зависимости
👨💻 Code: По позиции в программе
📰 Subscribe: По времени подписки
Та реакция, которая появилась раньше, срабатывает раньше. В любом нетривиальном приложении список реакций меняется со временем, а значит, они могут расположиться практически в любом порядке.
В результате получается скрытое состояние, которое влияет на работу приложения через разный порядок побочных эффектов, что может приводить к различным взаимным помехам. Мы получаем нестабильное поведение, что усложняет отладку и тестирование.
Это типичная проблема большинства библиотек.
🧨 Event: По времени возникновения события
Предположим, нам удалось зафиксировать порядок подписок тем или иным способом. Однако есть еще один источник нестабильности — порядок действий.
Явно или неявно изменяя состояния в разном порядке, мы снова можем получить разные порядки реакций. К сожалению, большинство библиотек подвержены и этой проблеме.
📶 Deep: По глубине зависимости
Некоторые библиотеки используют так называемую топологическую сортировку графа, чтобы пересчитывать инварианты в оптимальном порядке — от менее зависимых к более зависимым.
В этом примере Post изменяется на тот, к которому у нас нет доступа. Сначала обновится содержимое страницы, что не только приведет к ненужным пересчетам, но и может вызвать ошибки или просто мусор в виде побочных эффектов. И только затем, при вычислении Page, выяснится, что PostPage должен быть полностью уничтожен, а вместо него должно отображаться сообщение об ошибке доступа Forbidden.
Обратите внимание, что существование Title и Body зависит от значения Page. Но сами значения Title и Body уже не зависят от значения Page. И наоборот, значение Page не зависит от значений Title и Body. То есть связь между ними не реактивна. Но она есть. И это уже связь между владельцем и имуществом. То есть значение Page владеет реактивными состояниями Title и Body и, следовательно, контролирует их жизненный цикл.
Эту проблему нельзя решить, анализируя только реактивный граф. Если только не дополнить его графом владения. Но это потребует еще большей сложности в логике выполнения. И я не уверен, что топологическая сортировка такого двойного графа может быть выполнена с приемлемой алгоритмической сложностью. Иначе вся наша борьба за эффективность будет работать медленнее, чем гораздо более простая, но глупая архитектура.
👨💻 Code: По позиции в программе
Предпочтительно, чтобы реакции всегда обрабатывались в порядке, соответствующем порядку инициализации. Это гарантирует, что владелец обновится раньше всего, чем он владеет.
Здесь сначала обновится Allow, затем Page, что приведет к потере PostPage и, как следствие, к уничтожению PostPage со всеми внутренними состояниями без их вычисления.
🐵 Стабильность порядка вычислений
После изменения состояния результат должен быть таким же, как если бы начать с нуля в том же состоянии. В противном случае фактическое поведение у пользователя может отличаться от того, на котором разработчик ведет отладку.
Это кажется очевидным, но вы будете в ужасе, когда узнаете, что стабильность поведения почти никогда не гарантируется. В результате возможна ситуация, когда программист взял тот же код, открыл те же окна, ввел те же значения… но у пользователя возникает ошибка, а программист не может ее воспроизвести. И тогда начинается веселая отладка.
Поэтому в $mol_wire уделено особое внимание не только корректности, но и предсказуемости порядка вычислений. Это позволяет не бояться побочных эффектов даже в сильно динамичных приложениях, не теряя согласованности состояний. При этом код остаётся простым и элегантным:
class App extends Object {
@mem Post( next?: Post ) { return next } // mutable state
@mem PostPage() { // object factory
return PostPage.make({
Post => this.Post()
})
}
@mem Forbidden() { // object factory
return Forbidden.make({})
}
@mem Allow() { // derived state
return Guard( this.Post() )
}
@mem render() { // recursive side effect
if( this.Allow() ) this.PostPage().render()
else this.Forbidden().render()
}
}Тут метод render всегда выполнится раньше рендера вложенных страниц, какие бы у них ни были зависимости. Но выполнится он только если значение Allow поменяется. Как это работает под капотом поговорим в другой раз.
А пока, подписывайтесь на что-нибудь, вступайте во что-то там, и держите руку на пульсе вот этого вот.