What Are Signals?

What Are Signals?
signia.tldraw.dev

To discuss more specifically TLDraw’s Signia library, I think the ability to do manual diff tracking & incremental updates for computed stores is an interesting “escape hatch”. Docs here: https://signia.tldraw.dev/docs/incremental

Most signal libraries I’ve seen try to lean hard into magic auto-tracking of dependencies which means they make it really easy for the developer to correctly observe a lot of dependencies, cool on correctness, but then have a very limited set of tools to deal with the performance implication of some computation needing to re-run a whole bunch. The differential tracking here means that if you see such a hotspot, you can get really manual optimization of recomputation without needing to squeeze into the libraries pre-packaged observable collection API.

Downside of this API is it seems quite easy to get it wrong.

Another thing I like about Signia is the use of logical time. I saw this first in Jotai internals, then in Starbeam. I haven’t dug into the source of the library yet but I think logical time is a good approach and makes inspecting internals make a bit more sense than inspecting systems (like Notion’s) that rely purely on update notification listeners.

I've seen so many projects get bogged down in props hell, then gobs of context api and performance problems when too many things react at once.

Mobx has been solving these problems for a long time now!

(a) A thing that happens (or might happen but ultimately doesn’t) and is associated with a value of some sort, such as the mouse coordinates of first left-button click the program sees;

(b) A list of the above with monotonically increasing times, such as all the left-button click coordinates in order;

(c) The above plus an initial value, representing a piecewise constant function of time, such as the state of a toggle;

(d) A (conceptually) piecewise continuous function of time, such as the position of an animated object.

[To avoid “time leaks”, i.e. accidentally retaining all change history from the beginning of time, you also need

(e) A computation that reads the current time, such as the mouse coordinates of the next left-button click the program will see;

but that’s not supposed to be obvious—it took more than a decade to figure out.]

Possible names include: event occurrence [for (a)], event stream [for (b)], event [either (a) or (b)]; behaviour [(c) or (d)—the library may not distinguish them in the API or only provide (d)]; reactive [Conal Elliot’s name for (c) as opposed to (d)]; signal [(b), (c), or both]. All of these make sense in isolation. I don’t think you can win here.

[Perhaps the worst word to use is “stream“, because people start trying to fit streams with backpressure in there. FRP only makes sense as far as you can assume any recalculations happen instantaneously, meaning at the very least before the next input change happens. If you forget that, you get Rx instead of FRP, and that’s not amenable to human comprehension—or indeed sanity.]

This is a good thread about their drawbacks [2]. Apparently, both the below examples actually do different things:

    function One(props) {
      const doubleCount = props.count * 2;
      return Count: {doubleCount}
    }


    function Two(props) {
      return Count: {props.count * 2}
    }

[0] https://twitter.com/jordwalke/status/1629663133039214593

[1] https://twitter.com/dan_abramov/status/1629539600489119744

[2] https://twitter.com/devongovett/status/1629540226589663233