Hacker News Reader

Comment by vbezhenar | Hacker News Reader

I didn't understand the example in the linked README.

  // A library or framework defines effects based on other Signal primitives
  declare function effect(cb: () => void): (() => void);

What library? What framework? I lost here. What's effect?

  effect(() => element.innerText = parity.get());

How does effect knows that it needs to call this lambda whenever parity gets changed? Will it call this lambda on any signal change? Why this talk about caching then? Probably not.

Anyway I think that signal idea is sound, if I understood correctly what the authors tried to convey. My main issue with those decoupling architectures is that once your application is complex enough, you will get lost trying to figure out why this particular event being emitting. Ideally signals should fix this by modifying stacktrace, so when my callback is being called, it'd already contain a stacktrace of the code which triggered that signal in the first place.

View on HN

> What library? What framework? I lost here. What's effect?

There are various libraries that export a function called effect which allows you to run arbitrary code in response to a signal update. The Preact docs have a great primer on signals and effects: https://preactjs.com/guide/v10/signals#effectfn

As I understand it, these effect functions run the callback once initially to see which signals were accessed while the callback was executing, and then call the callback again whenever the signals it depends on update. As long as signal access is synchronous and single-threaded, you know that if a signal was accessed during the callback's execution that the callback should be subscribed to those signals.

> How does effect knows that it needs to call this lambda whenever parity gets changed? Will it call this lambda on any signal change?

You can do this with getters [1], where the effect function tracks which properties of the signal were accessed in a getter method (I believe Vue historically did this in version 2), but you can also track object access using proxies [2]. The example from the proposal simply has a 'get' method that is called to access the value of the signal, and executing this method allows dependencies to be tracked.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> How does effect knows that it needs to call this lambda whenever parity gets changed?

The call `parity.get()` will register a dependency on the function that is passed to `effect()`. When `parity` is updated, the function is called.

> Will it call this lambda on any signal change?

Only when a dependent signal changes.

In this case, `parity` depends on `isEven` and `isEven` depends on `counter`. So when `counter` is updated, that whole dependency chain is invalidated leading to `parity` getting invalidated, and that callback re-running.

This works well until you accidentally have an if/else branch, then you get hard to track bugs (halting problem in the general case).

I'm guessing this is why they don't propose to add this function to the standard: That fact makes it not very pretty.

Hmm, can you explain how if/else branches cause hard to track bugs?

if/else isn't a problem. If the condition isn't dependent then update of unused branch doesn't matter

> How does effect knows that it needs to call this lambda whenever parity gets changed?

Basically all implementations of signals (by whatever name) build a dynamic dependency graph, where edges are established by reading nodes. In a tracking context like this hypothetical `effect`, the read also establishes an edge between the signal’s state node and the effect’s computation node—effectively subscribing the latter to subsequent writes to the former, in order to determine when to rerun the computation.

1. effect is any function you want to invoke

2. with signals the dependency tracking mechanism knows what values need to be recalculated and as a result the system knows which functions to call again

I suspect the watcher is needed by the implementation of effect

Reply on news.ycombinator.com