Retrieving signal values can result in leaky abstractions.

[theScottyJam]

The problem

Say I want to export a function that adds one to a counter. I might do so like this:

const counter = new Signal.State(0);

export function addOneToCounter() {
  counter.set(counter() + 1);
}

...

This works, but there's a problem. I'm inadvertently leaking implementation detail - The consumer of this file might not even know or care that I'm using a signal under the hood, and yet, if they happened to call my function at the wrong time (i.e. inside an effect), bad things will happen. (I know effect() isn't provided by this proposal, so we'll just have to pretend I'm using an effect implementation from a framework that builds on top of the signals).

import { addOneToCounter } from './counter.js';

const selectedDate = new Signal.State(Date.now());

...

effect(() => {
  // If the date changes
  if (selectedDate()) {
    // increment the counter.
    addOneToCounter();
  }
});

Boom! By calling addOneToCounter(), we've both subscribed to counter and updated counter at the same time, sending us into an infinite loop, or perhaps an early error? Certainly, whatever it ends up doing won't be what the user was trying to make it do.

This sort of thing isn't theoretical - I've actually ran into it in Angular. I was using an instance of a third-party component library's class, and was trying to assign to one of its members inside of an effect() call. Turns out it was a setter function that must have been updating an internal signal, and at the time, Angular didn't allow you to update signals inside of effect calls without providing a special opt-in argument. I ended up using an untrack() call instead to avoid subscribing to whatever internal signals they were using. All of this felt like an accidental leakage of internals.

Of course, this library author could have wrapped their code in untrack() to fix the issue, and I could do the same in my above example as well, but in practice, from what I can tell, people don't tend to do this. untrack() is used more often at the place where the effect()/computed() call happens, not inside the API side. Plus, untrack() is somewhat clunky to use for this purpose.

Potential solutions

The root problem is that the default way to get a value out of a signal also automatically causes the function to leak implementation detail (i.e. what signals it would track if used in a computed/effect block). It would be better if 1. you opt into tracking instead of opting out, and 2. one-off untracked retrieval of values wasn't so clunky.

There's multiple ways to accomplish this. Here's one approach:

The computed() function now provides a single argument, use. (effect() functions could do so as well). If you pass a signal into use(), it will automatically return the signal's value and start tracking it. You can still call a signal to get its value as well, but doing so does not automatically cause tracking to happen. You can, of course, pass this use function around as needed, so anyone who needs to participate in tracking can do so.

const counter = new Signal.State(0);

export function addOneToCounter() {
  // use() isn't used here, so calling addOneToCounter()
  // will never cause tracking to happen on `counter`.
  counter.set(counter() + 1);
}

---

effect(use => {
  // Check if the date has changed.
  // We did `use(selectedDate)` instead of `selectedDate()` to get the signal value,
  // which means we'll automatically track this signal.
  if (use(selectedDate)) {
    // increment the counter.
    addOneToCounter();
  }
});

I like the explicitness of the above approach - I like how all functions (including helper functions) that are participating in tracking are required to receive a "use" function as an argument, making the tracking behavior part of the function signature instead of a detail hidden inside the function.

But, that's not the only way to solve the problem. You could also provide two different functions on the signal object that you can use to decide if you just want to read a value or read+track. So, in this picture, signals wouldn't be callable anymore, but counter.get() can be used to see the value without tracking and counter.use() lets you see the value and start tracking it if you're inside a computed/effect call.

const counter = new Signal.State(0);

export function addOneToCounter() {
  // get() is used here, so calling addOneToCounter()
  // will never cause tracking to happen on `counter`.
  counter.set(counter.get() + 1);
}

---

effect(() => {
  // Check if the date has changed.
  // We did `selectedDate.use()` instead of `selectedDate.get()` to get the signal value,
  // which means we'll automatically track this signal.
  if (selectedDate.use()) {
    // increment the counter.
    addOneToCounter();
  }
});

[trusktr]

The use idea is too cumbersome. Everyone will have to remember to always use use everywhere.

A solution at the language level would be to make atomic operations on signals automatically untracked by using a .value property instead of .get() and .set():

count.value++ // implicitly untracked

But for complex expressions, untracked is still necessary:

// this syntax is still nicer than with get/set imo:
untrack(() => count.value = 1 + count.value / sin(count.value)) 

I think that occasional untrack is simply a better way because most of the time we don't need it. In self-compounding state setters it will be a good practice:

export function increment() {
  untrack(() => counter.set(counter.get() + 1))
}

I think ESLint/TSLint can help warn here too.

[ziadkh0]

Another option would be to have a .peek() that does an untracked .get().

[theScottyJam]

In self-compounding state setters

Self-compounding state isn't the only scenario where this kind of issue happens, it's just the example I used (and the example that blows up the biggest if it goes wrong). Really, this leaky abstraction issue can happen anytime you're wanting to write helper functions that does one-off reads of the signal data. Maybe the user clicked a button and you're wanting to read the signal's state to decide how to react to the event - that sort of thing. Depending on the program, there could be quite a number of places where untracked() would be appropriate.

Another option would be to have a .peek() that does an untracked .get().

That would work as well.

[JuerGenie]

Could we use update just like:

export function increment() {
  counter.update((oldValue) => oldValue + 1);
}

with this implementation:

class State {
  // ...

  update(updater: (oldValue: T) => T): T {
    const newValue = updater(untrack(() => this.get()));
    this.set(newValue);
    return newValue;
  }
}

or with a parameter untrack for get() like counter.get({ untrack: true }).

or use a getter without track like counter.raw()?

[theScottyJam]

Angular has an .update() function, and I've never cared much for it. We would still need something like counter.raw() in addition to it since .update() alone isn't capable of fully fixing the issue. And if we have .raw(), then using counter.update((oldValue) => oldValue + 1) isn't much cleaner than using counter.set(counter.raw() + 1) IMO.

The counter.get({ untrack: true }) option is a little too verbose for my taste, but works.

I'd be fine with something like counter.raw().

[theScottyJam]

I do want to discuss this option a little more, of a use() function being passed in, which you then use to track and retrieve the value of a signal.

effect(use => {
  // Check if the date has changed.
  // We did `use(selectedDate)` instead of `selectedDate()` to get the signal value,
  // which means we'll automatically track this signal.
  if (use(selectedDate)) {
    addOneToCounter();
  }
});

While if you need to retrieve the value without tracking, you do theSignal() / theSignal.get() / theSignal.untracked() / theSignal.raw() - whatever we decide.

This particular solution is less conventional, but solves a second important "implicitness" problem.

Thing is, the popularity of signals have really exploded and spread through frameworks like wildfire, and we haven't really had much long-term experience with them yet. Most people's experience with signals involved doing green-field development on new projects using the signals. Few people have had the opportunity to enter a large, complex code base filled with signals, trying to tease apart what's going on. I worry that if we're not careful, we'll end up with the "switch statement" scenario, where we just copy-paste it around as-is, then later start realizing how bad some of those design decisions were.

Anyways, here's an example of a maintainability issue that will, perhaps, grow to become more of an issue as more and more people start trying to maintain signal-heavy codebases.

Let's say I see an effect like the following:

effect(() => {
  const theSize = size();
  const data = helperFunction();
  const data2 = thirdPartyLibrary.someFunction();

  showBlinkAnimation(theSize, data, data2);
});

There's a bug where the blink animation is firing when it shouldn't, so I need to figure out which exact signals are being tracked in this effect so I can figure out what's causing it to go off incorrectly. How would I do that? Well, I would need to dig into each and every function here, size(), helperFunction(), showBlinkAnimation(), maybe even thirdPartyLibrary.someFunction() (either looking up its documentation, or if I believe it may be accidentally tracking signals without documenting it, I may have to dig into its code). It's also worth noting that it's not immediately obvious what is or isn't a signal - is size() a signal, or is it a helper function that might call signals?

Now let's say the code looked like this instead:

effect(use => {
  const theSize = use(size);
  const data = helperFunction(use);
  const data2 = thirdPartyLibrary.someFunction();

  showBlinkAnimation(theSize, data, data2);
});

Which signals are being tracked during this call? Easy. size is a signal and is being tracked, and I need to jump into helperFunction() to see what else is being tracked. I don't need to look anywhere else.

(The example used effect() but the same pattern would apply to computed() as well - having it take a use parameter that gets used to explicitly track signal values).

[EisenbergEffect]

@theScottyJam Thanks for writing this up in detail. The idea of requiring explicit use(...) calls inside effects to participate in tracking runs into problems for some important integration cases, like classes with signal-backed fields where callers are just using properties/methods and shouldn’t need to know about signals at all.

If the main concern is debuggability or tracing, I’d rather solve that orthogonally with tooling instead of pushing it into every call site. For example, devtools that visualize the reactive graph, or a “signal stack trace” view that shows who is tracking what.

[theScottyJam]

like classes with signal-backed fields where callers are just using properties/methods and shouldn’t need to know about signals at all.

I believe that would still work just fine. If the caller doesn't need to know about signals at all, then I presume these methods should be using signals in an untracked fashion (if they were auto-tracking, then the fact that signals are being used would leak and the callers would know), in which case they wouldn't use the use function, they would use something like signal.untracked() to get the value without tracking it.

Unless I'm misunderstanding the scenario - if that's the case, could you expound?

[EisenbergEffect]

@theScottyJam In this use case, signals backing the class properties would need to be auto tracked. That's the issue. That pattern has been in use for 15 years on the web since Object.defineProperty and Knockout (some native platforms have supported this pattern for even longer). Many app architectures rely on this, which is one of the reasons why the original design went the auto-tracking route.

From the API Surface section of the proposal:

Must be a solid base for multiple frameworks to implement their Signals/reactivity mechanisms.

• Should be a good base for recursive store proxies, decorator-based class field reactivity, and both .value and [state, setState]-style APIs.

In terms of leaking implementation, that depends more on how the theoretical effect behaves when signals are set during the effect callback. User land code can't access or "see" those signals directly unless they are exposed by the class. Only the platform can.

[theScottyJam]

Oh, I think I see what you mean? The class would have properties that are getters, that retrieve the value of a signal. Those who use the class don't care necessarily that it's backed by signals per-say (because maybe their chosen framework doesn't directly deal with signals), but they do care that when they access those properties, tracking happens, if they're inside their framework's effect function.

Perhaps there's ways to leave implicit tracking out by default, but still allow frameworks to add it in as needed? That way, existing frameworks can still re-build themselves on top of signals if they so wish to do so, while new frameworks can simply not hook into signals in this fashion, allowing signals to only be tracked explicitly.

[NullVoxPopuli]

That strategy of using getters in plain classes has been used by modern ember for the last few years, and it's been working very well. Generally no issues, unless folks do bad things anyway. Like, mutating anything during render (in a web/browser framework) is usually a problem to begin with, so we've been trying to teach more decivation pattern as general coding principles, rather than synchronous effects, and have had positive results with that so far.

(This is from the app dev and framework dev perspective - all render things are batched in a phase of our 'game loop')

[theScottyJam]

I'm sure what currently exists has worked well - it's much better that what we had before. Doesn't mean there's not room for improvements or better ways to do things. Do you feel like the issue I brought up earlier, of "trying to figure out what causes an effect to re-fire", is not a real issue for those trying to enter the codebase? If it's not an issue, why not? I don't know Ember, but do they have a good way to solve this problem?

I know "use tooling" was a potential solution brought up earlier, but that's not really a solution, it's more of a band-aid, and it can't tell you everything that could be tracked inside an effect call, it can only tell you what's currently being tracked at a given point in time. e.g. imagine getting the value of a signal inside of an if's block.

[NullVoxPopuli]

Doesn't mean there's not room for improvements or better ways to do things

ccc -- always gotta improve 🎉

"trying to figure out what causes an effect to re-fire", is not a real issue for those trying to enter the codebase? If it's not an issue, why not? I don't know Ember, but do they have a good way to solve this problem?

So, specific to ember, and likely wouldn't work generically for the Signals proposal, but Ember does not provide a formal effect primitive (reasons for that are off topic here), but what this means is that all things that can be reactive are part of our "debug render tree", which our inspector tooling can show all the details of.

I know "use tooling" was a potential solution brought up earlier,

if there were public APIs to inspect maybe that would help? like...

Signal.dependenciesOf(() => obj.whateverGetter)

it can only tell you what's currently being tracked at a given point in time. e.g. imagine getting the value of a signal inside of an if's block.

aye -- this has been my understanding of how tooling would work as well -- no way to track the history of what's consumed by the getter or computed -- but maybe implementors could do it like how we have stack rewinding in debug tooling.

There is a lot of behavior in existing debug tooling that isn't possible to implement in user space, and I think that's ok.

[NullVoxPopuli]

Oh svelte already has something similar
https://svelte.dev/docs/svelte/$inspect#$inspect.trace()

Noice

[trusktr]

Really, this leaky abstraction issue can happen anytime you're wanting to write helper functions that does one-off reads of the signal data

@theScottyJam We shouldn't be disabling tracking generally speaking. We'll get into worse scenarios where when something is written with untracking, then we start to implicitly implement an alternative reactivity system than the main one just to make that untracked code run again, and now you have two reactivity systems which is more difficult to manage.

Refactoring this code gets even more difficult because then we move things around, and state isn't working as we'd expect, and will end up writing undesired patches to make things run when everything should have been simply automatic from the start.

Instead, trying to keep everything as signals and effects (or declarative templates, etc) keeps code within a single paradigm that ultimately makes it easier to reason about and to work with.

The moment we stop tracking in some function, then we have to ensure by other means that we cal the function when it is needed, and I've seen this type of code get difficult to maintain.

---

use() is a foot gun. It opens up the door to easily forgetting to track things, leading to the aforementioned problem of app code straying away from the paradigm on which it is intended to be used, leading to creation of new reactive paradigms to work around the main one not working.

---

.peek()

@ziadkh0 that could be useful, but I'd say have it live as .subtle.peek() to likewise tell people they better be careful.

In all apps I've written with signals (starting more than a decade ago with Meteor), untracking tends to typically lead to problems, unless used carefully when absolutely necessary (such as initializing state in a effect only to use that state further down in a nested effect, and in this case it should be abstracted into an API that created the state and makes untrack during initialization implied so end users don't have to remember to use it).