Reactive Computing Order

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.

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.

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.

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.

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.