Reading about the issue people encountered with Knockout and also thinking about how to deal with a property whose value depends on the mutated value of several other properties, I am wondering if the current implementation doesn't allow glitches, i.e. the equivalent of torn reads.

Let's entertain the following scenario: D depends on B and C which themsevles both depend on A (A, B, C, D are value holders)

         D
B                 C
         A

When A is updated, it is going to update B, whcioh is going to update D with the value d` Then it is going to update C which is going to update D with the final value d.

d` might not be an interesting value but a purely transactional one. In whihc case, it shouldn't really count perhaps. In which case, it really shouldn't be a cause for a UI update. If it does make sense somehow, then it is fine, however?

Beyond that question, should these diamond dependency data graph be even written in the first place?

Said otherwise, should d' be considered an impossible state in the UI state machine? Maybe A should depend somehow on A being updated directly and pull the values of B and C:

B              C             D

               A

But not sure it is realisable in a general manner. And automatically deriving the code dependencies to flatten graphs seem prohibitively complex.

Concrete plausible example

Let's say I change the global theme of a UI and colors are being recomputed based on a formula for each (foreground and background or background and text color). It would make sense for the UI to only apply the update after all the colors have been recomputed. Question is then, how to model this behavior with our current semantics that eagerly respond to property change?

The current solution would be that instead of reacting for each property change by watching them as independent mutable properties, one should observe the theme change event and react after the theme change has been completed by using AfterEvent (instead of WatchEvent which eagrely starts as soon as the mutation event has been detected).

In basic terms,it says: "After the theme change has been completed, update the UI". It would take into accoun all the intermediary property change suhc as the foreground, background, and text colors.

So it is not possible to enforce glitch-free code?

Well, what we provide seems to be lower level and require some clarity about how the UI updates. It's not really that it allows for glitchy code so much but rather that any semantic glitch would be caused by the coder not fully understanding the meaning of what they wrote.

If one want to avoid reacting for every variable change, they need to watch the updating event itself and react after it has occured, pulling the reauired updated values only after the event has been processed. In principle, it would require for the theme change event to issue a change completed event that the UI updating code would wait for.

In our example, D waits for AfterEvent(A) to Get(B) and Get(C) and recompute its value. As such, it only gets valid values.

And if B can be mutated in response to a whole other, unrelated event?

Well, it just means, if we keep our previous concrete example, that the background can be changed independently of the theme for instance. In that case, it just means that D will watch B directly as well. No biggie.

Conclusion

Our implementation is glitch free. No issue. On the user-side, there might be a need to pay attention to evaluation order as shown in our diamond example but it should be tractable in most cases.

Reference

https://en.wikipedia.org/wiki/Reactive_programming#Glitches

atdiar / particleui

diamond update problem: are those glitches and is this a problem? #14

Concrete plausible example

So it is not possible to enforce glitch-free code?

And if B can be mutated in response to a whole other, unrelated event?

Conclusion

Reference