The proxy object is a fairly classic way of doing signals (see Vue, SolidJS), and the whole thing about functions rerunning whenever data that was accessed inside that function changes is pretty much the definition of signals.
It looks like the author is trying to avoid making direct comparisons with signals and existing signal frameworks, which makes sense - depending on your target audience, it can be a bit "inside baseball" - but it's definitely using some sort of signals-like mechanism under the hood.
It basically is that, although the key idea with signals is the automatic tracking. There's no sort of `signal.subscribe()` call happening, instead any time you use a signal inside a reactive context, it automatically gets subscribed. This simplifies a lot of patterns that would otherwise be rather complicated. For example, you might have an effect like:
if (showName()) {
console.log(name());
} else {
console.log("the name is a secret");
}
In this case, both `showName` and `name` are signals. If `showName()` is true, then the effect will automatically subscribe to both signals, and this function will rerun every time the name changes, or someone toggles `showName`. But if it's false, then the effect will only subscribe to the `showName` signal, which means even if the name changes somewhere else, that won't affect this expression at all.
In complex situations, it can be harder to see where the reactivity is flowing without the explicit subscriptions, especially at first, but it's also a lot more intuitive to just use data and have it automatically become reactive where it makes sense. It's also the base for most major web frameworks outside of React.
It looks like the author is trying to avoid making direct comparisons with signals and existing signal frameworks, which makes sense - depending on your target audience, it can be a bit "inside baseball" - but it's definitely using some sort of signals-like mechanism under the hood.