Approach to glitches

[zyla]

When a node (A) occurs multiple times as a dependency of another node (B), B will fire many times for each firing of A, and some of the firings will have wrong value.

The following test case illustrates the problem:

    it("handles diamond dependencies without glitches", () => {
      const source = sinkBehavior(0);
      const b = lift((a, b) => a + b, source, source);
      const spy = subscribeSpy(b);
      assert.deepEqual(at(b), 0);
      source.push(1);
      assert.deepEqual(at(b), 2);
      assert.deepEqual(spy.args, [[0], [2]]);
    });

It fails with:

  1) behavior
       applicative
         handles diamond dependencies without glitches:

      AssertionError: expected [ [ 0 ], [ 1 ], [ 2 ] ] to deeply equal [ [ 0 ], [ 2 ] ]

The presence of value 1 indicates that the framework let the application observe inconsistent values for source (0 and 1 in this case).

Is this the expected behavior? If not, are there plans to fix it?

[paldepind]

Hello @zyla. Thank you for asking such a great question.

Hareactive is purely functional FRP library and it is primarily intended to be used in a pure setting. Glitches have the effect that some functions end up being invoked more often than they should. But, if the function is pure and doesn't have any side-effects then this is not a big problem. It's not ideal but it's not a big deal. Therefore fixing it is not a huge priority right now.

That being said, we do definitely intend to fix this at some point in time. We'll probably end up doing a topological sort of the dependency graph to eliminate glitches. But, as of right now we are making large refactors of the implementation to improve performance and code clarity.

[paldepind]

Btw, another part of the reason why we haven't eliminated glitches yet is that we want to do it with the smallest performance overhead as possible. We've discussed implementing the topological sort such that the topological order computed while the dependency tree is being constructed and updated when new dependencies are added/removed. This will make maintaining the topological sort cheaper. But we need to get other internal features in place before we can do that.

[dakom]

Sorry for the naive question - but is the test case above from this API, I don't see those functions listed?

Also, feel free to correct me if I'm wrong - but I believe glitches are an indication that something is off in the semantics or the implementation is buggy. For example, here's a live demo similar to the one above via RxJS (which is not FRP proper): https://codepen.io/dakom/pen/yoqyEK (change the html to switch between v4 and v5, the glitch actually manifests in different ways which is kinda scary)

More info from the book Functional Reactive Programming:

because Rx isn’t based on denotational semantics, it isn’t
truly compositional, and this is one of the requirements of FRP. One way in which this
manifests is the area of glitches. A true FRP system should be glitch-free.

[zyla]

Sorry for the naive question - but is the test case above from this API, I don't see those functions listed?

@dakom This test is not included in the hareactive test suite. To see the effect, paste it into test/behavior.ts in the describe block.

(edited: messed up formatting)