# Michel Weststrate: Signal Goals Survey

## What projects related to signals do you work on?

MobX and its integration into React

## How do you imagine standard signals integrating with that project?

- Implementing the core reactive change propogation of atoms (signals), derivations and side effects as currently found in https://github.com/mobxjs/mobx/blob/main/packages/mobx/src/core/
- Improve interoperability with existing libraries e.g.:
- useSignal in React
- Even further: React (and by extension any other UI library) could treat the component concept as being a DerivedSignal
- ORM / data fetching libraries expose their objects as signals, or basically anything that accumelates a value over time (e.g. Date.now() itself can have a Signal equivalent)

## Should developers use standard signals directly, or are they more of a primitive for libraries/frameworks?

Both, I think they are in that sense fairly similar to Promises.
Effects however should primarily be managed by libraries

## How would you design an MVP standard signal API? Use concrete code samples, and just sketch out your initial thoughts; it doesn't have to be perfect.

Extremely drafty:

const number = new Signal(7)
const doubler = new DerivedSignal(() => number * 2)
const tripler = new DerivedSignal(() => doubler + number) //signals automatically unwrap when coerced to a primitive?

// Effect is typically used by libraries, to support more convenient ways to set up side effects,
// e.g. https://github.com/mobxjs/mobx/blob/main/packages/mobx/src/core/reaction.ts 
// might be a better design, but at least the following captures the
// intended hopefully more clearly:
// In MobX `when`, `reaction`, `autorun` and `observer` are all built on top of the above abstraction
const loggerSignal = new Effect(
    /*signal to track, usually but not necessariliy a DerivedSignal */ 
    tripler, 
    /*on become dirty handler*/ 
    (pull) => {
        // pull grabs the current value of the tracked signal,
        // and, after doing so the effect can be scheduled again
        // if the tracked signal changes
        queueMicrotask(() => {
            console.log("Tripled: " + pull())
        })
    }
)

number.set(8)
// marks doubler, tripler, loggerSignal dirty
number.set(9)

// ...later
// (microtasks)
// (loggerSignal pulls tripler, pulls doubler, pulls number)
// Tripled: 27

// ...later

loggerSignal.dispose() // stop tracking

## What requirements do you have on how computed/effect dependencies are tracked? How should this be divided between the standard and libraries/frameworks?

* Possibility to perform up untracked reads
* Glitch free, topological derivation execution
* Either support for batching + synchronous effect execution, or microtask based effect execution (MobX strongly opionates on the former, but that latter is practically a lot simpler and might be sufficent if synchronous DerivedSignal reads are supported).
* Pull semantics: signals propagate "dirtyness" through the dependency graph, effects pull in values

See also https://hackernoon.com/becoming-fully-reactive-an-in-depth-explanation-of-mobservable-55995262a254 and https://hackernoon.com/the-fundamental-principles-behind-mobx-7a725f71f3e8 for fundamentals of signals in MobX (in MobX they are goals atoms as they are avant-la-lettre, but they're the same thing imho)

## What requirements do you have on scheduling execution of computed/effect? How should this be divided between the standard and libraries/frameworks?

computeds and effects are fundamentally different things. For the timing of effects, see above. For computeds, they are executed immediately if someone requests their value, and their dependencies are dirty. Otherwise they return a memoized value.

## There is a lot of discussion about "push-based" vs "pull-based" mechanisms, as well as the notion of signals being "lossy" (meaning they don't necessarily deliver every value to their computations/effects, only the last value). What are your thoughts on these areas?

Strongly opinionated on pull based. Dirty state however is pushed, so strictly speaking it is more of a push/pull model.
Whether values are or aren't lost purely depends on the scheduling strategy of the Effect as shown above

## Do you have any opinions on the various different graph algorithms for handling signals?

Topographical distribution of dirty state, as defined in https://hackernoon.com/becoming-fully-reactive-an-in-depth-explanation-of-mobservable-55995262a254, so that
execution is both glitchfree and derivations don't run more often then strictly needed

## Do you have any opinions on whether or how signals might be integrated with other standards, such as the DOM standard?

Not sure yet. It'd be really cool to bind DOM Node attributes directly to signals, but probably that should be a different follow up proposal altogether.
In principle anything that is subscribable, and subscribes to a value (rather than an effect or an event), could become a Signal.

## Do you have any other requirements/needs/considerations for signals from your side?

Signals should be composable. It doesn't have to be necessary part of the standard, but they should be designed in such a way that mutable objects / arrays / maps / sets can be modelled using Signals, giving syntactical similarity and reactive powers to complex object graphs like Vue / Svelte / MobX.