3 ms·

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

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.

troupo 3y ago
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
throwitaway1123 3y ago
> 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 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/Reference/Functions/get https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
pyrolistical 3y ago
I suspect the watcher is needed by the implementation of effect
mondrian 3y ago
> 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.
- posix86 3y ago
  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.
  - mondrian 3y ago
    Hmm, can you explain how if/else branches cause hard to track bugs?
  - __s 3y ago
    if/else isn't a problem. If the condition isn't dependent then update of unused branch doesn't matter
eyelidlessness 3y ago
> 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.

troupo 3y ago

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

throwitaway1123 3y ago

> 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 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/Reference/Functions/get https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

pyrolistical 3y ago

I suspect the watcher is needed by the implementation of effect

mondrian 3y ago

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

posix86 3y ago
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.
- mondrian 3y ago
  Hmm, can you explain how if/else branches cause hard to track bugs?
- __s 3y ago
  if/else isn't a problem. If the condition isn't dependent then update of unused branch doesn't matter

eyelidlessness 3y ago

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