Question: Is there a "pending" state for S.data computations? about s

[adamhaile]

Hi Grieb --
Surplus has a different methodology for computation lifecycle than mithril. So the short answer is no. For the particular case you show, you could get a similar effect just by setting the onchanges parameter to true:

const pending = S.data();
S.root(() => {
  S.on(pending, () => {
    console.log("should not have ran...");
  }, null, true);
});

That won't run until pending() is set. But that's not a 'true' pending computation for two reasons: 1) mithril would run the computation if the source stream had been previously set, whereas this will always wait until the next set, and 2) it doesn't generalize to multiple streams:

const pending1 = S.data(),
    pending2 = S.data();
S.root(() => {
  S.on([pending1, pending2], () => {
    console.log("should not have ran...");
  }, null, true);
});

The computation will run as soon as the first source is set, whereas mithril will wait until all have been set.

The main reason Surplus takes this path is that pending streams are incompatible with automatic dependency detection. We can't defer execution until all sources are active if we don't know what the sources are until we've run. In general, automatic dependencies, the kind you get with S(() => ...), are the core of S, because they enable synchronous declarative programming. S.on() is provided for cases where you are doing event-driven programming. There's nothing wrong with using it -- if you really are doing event driven programming, then it's the right tool -- but if that's not true, S() will often lead to easier-to-reason-about code. S.on() says "this runs when X happens." S() says "this is the way things are."

All that said, you can actually re-create the mithril behavior using two data signals per stream and a subclock for dependent computations. Mithril streams really carry two pieces of data: their state and their value, so you need two data signals, because in Surplus, a data signal only carries one piece of data. Then for dependent computations, you need a utility that a) declares dependencies explicitly, a la S.on(), and b) uses a subclock to defer computation until all the sources are active.

I was influenced a lot by mithril a couple years ago, when I was starting S and Surplus, but haven't followed it as much over the last year. Curious to hear how your translation goes. Feel free to share code if its useful.
-- Adam

[griebd]

Thanks for the explanation @adamhaile! A thoroughly answer really adds to your work, congratulations!!
I will keep studying it, but for my specific case now your solution is more than enough. It forces me to keep using S.on and not S() tough, right?
Grieb

[adamhaile]

Yeah, using S.on() when you want to run something on an event is fine, the intended way in fact.