Reactive Computing Order
Tags: webdev, javascript, architecture, reactivity
Published: 2024-02-01 16:33:00

The order of execution of reactions has its own peculiarities, which are often left to random. However, let's look at all the possible options...

> 📰 Subscribe: By subscription time
> 🧨 Event: By time of event occurrence
> 📶 Deep: According to the depth of dependence
> 👨‍💻 Code: By position in the program

# 📰 Subscribe

Whichever reaction appeared earlier is triggered earlier. In any non-trivial application, the list of reactions changes over time, which means they can be arranged in almost any order.

![](https://raw.githubusercontent.com/nin-jin/slides/master/reactivity/reactivity-order-subscribe.svg)

The result is a hidden state that affects the operation of the application through a different order of side effects, which can give various mutual interferences. We get unstable behavior, which complicates debugging and testing.

This is a typical problem with most libraries.

# 🧨Event

Let's assume we managed to fix the order of subscriptions in one way or another. However, there is another source of instability - the order of actions.

![](https://raw.githubusercontent.com/nin-jin/slides/master/reactivity/reactivity-order-event.svg)

By explicitly or implicitly changing states in different orders, we can again get different orders of reactions. Unfortunately, most libraries are susceptible to this problem.

# 📶Deep

Some libraries use so-called *topological graph sorting* to recalculate invariants in an optimal order from less dependent to more dependent.

![](https://raw.githubusercontent.com/nin-jin/slides/master/reactivity/reactivity-order-deep.svg)

In this example, `Post` is changed to one that we do not have access to. First, the contents of this page will be updated, which will not only lead to unnecessary recalculations, but they may also result in errors or just garbage as side effects. And only then, when calculating `Page`, it will be found out that `PostPage` should be completely destroyed, and instead a `Forbidden` access error message should be displayed.

Note that the existence of `Title` and `Body` depends on the value of `Page`. But the `Title` and `Body` values themselves no longer depend on the `Page` value. Conversely, the value of `Page` is independent of the value of `Title` and `Body`. That is, the connection between them is non-reactive. But it is there. And this is already a connection between owner and property. That is, the `Page` value owns the `Title` and `Body` reactive states, and therefore controls their lifetime.

This problem cannot be solved by analyzing the reactive graph alone. Unless you can supplement it with a possession graph. But this will require even more complexity in the runtime logic. And I'm not sure that topological sorting of such a double graph can be done with acceptable algorithmic complexity. Otherwise, our whole struggle for efficiency will work slower than a much dumber but simpler architecture.

# 👨‍💻 Code

It is preferable that reactions are processed in the order that is explicitly specified in the code. This ensures that the owner is updated before everything he owns.

![](https://raw.githubusercontent.com/nin-jin/slides/master/reactivity/reactivity-order-code.svg)

Here, `Allow` will be updated first, then `Page`, which will lead to the loss of `PostPage` and, as a result, the destruction of `PostPage` with all the states inside, without calculating them.