# What projects related to signals do you work on?
I work on Wiz (proprietery Google Web framework).

# How do you imagine standard signals integrating with that project?
Standard Signals library will make our core bundle smaller. We intend to share signals as a reactivity primitive with Angular. That will be a starting point to drive further framework convergence. Yes Ben, we are open sourcing Wiz.

# Should developers use standard signals directly, or are they more of a primitive for libraries/frameworks?
~Both? We will strongly consider exposing a subset of the standard APIs directly to developers. Our templating system (Closure Templates) will likely need a bespoke API since we render in Java servers. Framework authors will use a subset of the standard API to build effects/scheduling/etc.

# 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.

// **API**
export function signal<T>(value: T): [Signal<T>, Setter<T>]
export function computed<T>(fn: () => T): Signal<T>
export function untrack<T>(fn: () => T): T

// **Use**
const [value, setValue] = signal(5);
untrack(() => console.log(value())); // Logs "5"

const doubled = computed(() => {
  const double = value() * 2;
  console.log(double);
  return double;
});
untrack(() => doubled()); // Logs "10" right away
untrack(() => doubled()); // Logs nothing

setValue(10); // Logs nothing.
untrack(() => doubled()); // Logs "20" right away

// **Abuse**
console.log(value()); // Throws runtime error!
doubled(); // Throws runtime error!
const bad = computed(() => {
  // Cannot set signals when reads are being tracked
  setValue(10);
  return doubled();
});
untrack(() => bad()); // Throws runtime error!

Frameworks and library authors would have the ability to build effects on top of these building blocks. They might require additional APIs. Those APIs wouldn't be commonly used (eg: by feature developers).

# What requirements do you have on how computed/effect dependencies are tracked? How should this be divided between the standard and libraries/frameworks?
Dependencies should be tracked automatically (no manual deps arrays). Computeds know the signals (and other computeds) they depend on. There shouldn't be memory leaks because a signal retains a reference to a computed when the application doesn't care about the computed anymore.

# What requirements do you have on scheduling execution of computed/effect? How should this be divided between the standard and libraries/frameworks?
Scheduling execution should be purely a consideration of the libraries/frameworks. The standard should only provide a mechanism to synchronously pull a signal or computed.

# 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?
Signals can be "lossy". No problem. The standard should only provide a mechanism to synchronously pull a signal or computed. When you eventually pull you only get the latest, glitch-free value.

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

# Do you have any opinions on whether or how signals might be integrated with other standards, such as the DOM standard?
Maybe in the future. Attempting it now seems like taking on too much. Delivering a signals and computeds primitive alone is valuable. Aligning reactivity primitives of multiple frameworks/libraries is priceless :)

# Do you have any other requirements/needs/considerations for signals from your side?
Wiz has a strong requirement to make "resumable signals". We should talk about serialization format during SSR that allows the signal graph to be progressively created on the client as various parts of the application become reactive.