NullVoxPopuli
commented
6 months ago the global entity orchestrating the whole process no longer knows what computed value to add the dependency to.
imo, this is a feature, not a bug or design flaw -- you need some way to choose what signals to entangle with. As in: https://github.com/NullVoxPopuli/signal-utils/
import { Signal } from 'signal-polyfill';
import { signalFunction } from 'signal-utils/async-function';
const url = new Signal.State('...');
const signalResponse = signalFunction(async () => {
const response = await fetch(url.get()); // entangles with `url`
// after an away, you've detatched from the signal-auto-tracking
return response.json();
});
// output: true
// after the fetch finishes
// output: false
<template>
<output>{{signalResponse.isLoading}}</output>
</template>This is implemented via an impure Computed:
const state = new State(fn);
const computed = new Signal.Computed(() => {
state.retry();
return state;
});If we always tracked any signal accessed within an async function, we'd more easily have infinite loops -- as any Signal accessed within state would entangle with along with url changes -- which would make loading state (or any async state) much harder to handle.
return watch(val1) * watch(val2);
This is an interesting idea, and would indeed be very explicit about what's happening. However, it "feels like" (to me, I could be wrong! and please correct me if I am), that we'd lose autotracking, and the transparent abstractions we can achieve by hiding the underlying Signal API -- for example, app-devs consuming a Signals (as designed today), may not even know they have reactive data! and things would just work! :tada: (provided folks using destructuring in their component renderers do not do so too eagerly -- this is a DevEx thing being explored in frameworks that use functions as components / computeds / async computeds).
For example, if I'm a library author, and I implement a reactive array, such as: https://github.com/NullVoxPopuli/signal-utils/tree/main?tab=readme-ov-file#array, and then pass it to you, you could mutate the array with and my library could just reactive update without you having any knowledge of reactivity -- it behaves just like a native array :tada:
DavidANeil
TarVK
hediet
jeff-hykin
lassevk
parched
Concerns
I don't know if this is an appropriate place to start this discussion, but I've had some concerns about signals for a while now. I've worked on some statemanagement systems in the past myself, and independently came up with something similar to signals. Then when I found out that signals already exist and are semi-standardized, I got quite excited. However, there are 3 major caveats I see with signals that I don't like:
Reliance on globals
In order for computed values to be aware of their dependencies, dependencies have to communicate their presence to computed values. The approach I have seen taken by several libraries to achieve this, is the following: Before evaluating a computed value, it tells some global entity G that it will evaluate. Then the computed value computes and accesses a signal S, during wich S informs G of the access. In turn, G can let the computed value know that it apparently depends on S.
This approach relies on globals, and without special runtime language features, I don't think one can do much better than this approach with the current form factor of signals. The reliance on globals hurts interoptability of different libraries however, similar to the problem that was faced by React hooks. I don't know how this problem was solved in React (because I believe it is now?) so it might be solveable. Additionally if this becomes a core part of JavaScript itself, it might not be an issue to begin with. But I wanted to express my doubts on this either way.
Implicit dependency tracking
Dependency tracking is implicit in signals. This means that when looking at the code for computed values, you can not directly see which of the dependencies can cause recomputations. Now you might argue that you don't have to see it, that it's not relevant, but I think it can be for several reasons:
I like the system that async/await introduces more. Here an explicit 'await' keyword exists, that makes awaiting data explicit. Similarly a 'watch' keyword could exist for computed values, that makes dependency tracking explicit. For async/await it was decided that having an explicit await keyword was beneficial, even though this could also have been implicit. I don't know what the reasons for this choice were, if it was for technical reasons or usage reasons, but either way I believe this to have been the better choice.
Requiring synchronous code
One thing that seems to be lacking from most signal libraries/systems, is asynchronous computations. There may be several reasons for this, potentially including hydration and server side rendering concerns, but besides this the current way of dependency tracking also limits potential async implementations. Ideally, I would want to be able to write something like this:
This would result in a signal that has a default value of 0, and when accessed would perform the computation but without updating its value yet since the computation does not finish synchronously, updating its value and signalling it only afterwards when the computation finishes.
I believe there can be a very nice interplay between asynchronous computations and signals in this way, symplifying how asynchronous computations are used in defining state. The current norm for dependency tracking however falls apart in this use case. If a value is accessed after some delay, the global entity orchestrating the whole process no longer knows what computed value to add the dependency to. This for instance would happen in the following code:
Personal ideas
So let me first mention that I'm aware I'm not as deep into this material as the people working on this repository are, but because I've worked on my own system for a while and have thought about some of these tradeoffs, I did think it was worth reaching out.
All of the issues above were solved in my own system by a simple 'change' (this is actually just how I designed it before I learned about signals) of the interface of computed values. In my system I work with a 2 phase notification, which I believe is similar to what many signal libraries do, where I first mark dependents as dirty before dispatching a change event. As such my signals (which I call "watchables" in my system) have the following interface:
Then, computed values (which I call derived values) are defined using explicit dependency tracking. Consider for example the following fragment:
Here the
watchfunction both calls thegetof the watchable, and registers the watchable as a dependency of the derived value. As a result, this system does not rely on globals, allows users to choose whether to actively watch dependencies, and can deal with asynchronous computations. In my own system I go a bit further and also attach metadata to watchables that allow for automatic tracking of additional data like whether the derived value depends on any data that's still loading. But this is probably outside the scope of a standard JavaScript primitive.