Mixing signals and computed-signals disallowed?

[mindplay-dk]

With the following example:

const value = signal("foo");

const computed = signal($ => value($) + "!!!")();

core($ => console.log(/*"signal:", value(),*/ "computed:", computed($)))();

value("bar");

If I uncomment the bit that prints the signal value, I get an error Mixed rp|rs - and presumably, this is about signals and computed-signals being disallowed in the same context?

Is this "by design"?

With Sinuous (or S.js) and Dipole, you can mix signals and computed-signals. As far as subscriptions go, they both represent a "stream of values", so it's not clear to me why it would be necessary to restrict this.

I am concerned we lose some of the explainability - I like to use a spreadsheet example to explain these concepts, as it's the most well-understood "functional/reactive programming language" there is, and it does not have any restrictions like this.

Imagine you had to refactor a spreadsheet, and something that was a value changes to an expression - if spreadsheets had this limitation, you can imagine how difficult it would be to get it back into a working state.

I'm concerned the same kind of problems will be inherent with this limitation.

[tsugabloom]

No that's not by design, you're using it wrong. Absolutely not your fault; I have no docs. I'm doing #6 as part of this weekend 😄

The error you're seeing has nothing to do with computed signals. You're actually never creating a computed signal, sorry 😞. Computed signals are defined by writing a core into a signal, not a function. See PR #1 or the JSDoc comment if you hover on signal() in your editor.

This is part of the "explicitness" thing - I don't give functions any special treatment. This is also why DOM patching needs <p>to use {core(data.count)} in Haptic</p> meanwhile <p>in Sinuous {() => data.count} is fine</p> because every single function is auto-wrapped in a computed() in Sinuous (!!!)

I mention this in #5

I want people to be able to write a function as a value into a signal and not have anything odd happen; I have no interest in intercepting a random function. Just let it through. So if I need to introduce special behaviour it has to be with a data type I own - I only have signals and cores, and it's important that there's only one type of a signal to avoid confusion. Cores are computation engines, so it followed that passing a core into a signal creates a computed-signal.

I'll be sure to make it super super clear in the introduction/docs!

Here's your code with comments:

const value = signal("foo");

// This writes a function to the signal, then immediately reads it back out, and stores the function as `computed` 
const computed = signal($ => value($) + "!!!")();
// Equivalently:
// const computed = $ => value($) + "!!!";

core($ => console.log(
  // Reads value() and DOES NOT SUBSCRIBE since there's no $
  "signal:", value(),
  // Calls $ => value($) + "!!!"  which SUBSCRIBES
  "computed:", computed($)
))
// Run immediately, IIFE style. Throws error because `value()` and `value($)` are used on the same core.
();
// Unreachable code:
value("bar");

I think I got the consistency check idea from https://github.com/adamhaile/S in their README.md:

3. Not a bug but a feature: S will throw an exception if you try to set a data signal to two different values during the same update. I.e., it's not "last set wins." [...]

I wanted something similar for read vs read+subscribe. I just changed the error message to be more clear, thanks!

Here's a working version that uses a computed-signal

const value = signal("foo");
const computed = signal(core($ => value($) + "!!!"));

// Sometimes called an "effect" in other libraries...
core($ => console.log("signal:", value($), "computed:", computed($)))();

value("bar");

[tsugabloom]

Just started vacation from work today so resuming dev here. Thanks for being patient! I'll try to cut a release soon 🤞

[mindplay-dk]

This time I think I'll just remain on stand-by until you say so. 😄

[tsugabloom]

Published 0.10.0. There's a lot more docs now (still not enough) and at least I tested all the code that's in the docs :) That's a start. Note though that there have been some API changes, particularly to when() and signal.anon. Oh and I took you up on using wire instead of core; saw you use it a few times in our threads and it fits better as a verb.

[mindplay-dk]

Very cool! I will try to take a look over the weekend. 😀