Consider renaming “Signal” to avoid collision with existing AbortSignal

[ryanflorence]

The term "signal" is already a well-established concept in the JavaScript platform via AbortController / AbortSignal. These are deeply integrated into the web platform, widely used, and baked into many APIs (fetch, streams, event targets, etc.).

Introducing another first-class primitive called "Signal"—with unrelated semantics—creates ambiguous vocabulary:

• Developers will need to clarify "reactive signals" vs "abort signals."
• Documentation, examples, and teaching will repeatedly have to disambiguate two unrelated concepts with the same name.
• Frameworks and applications that use both will encounter real ergonomics friction.

Our in-progress Remix 3 component API relies heavily on abort signals (like event-handler/render task re-entry and element/component lifecycle etc.). We also plan to support reactive values. Having both concepts named signal creates unavoidable naming collisions.

This is not a matter of preference but of namespace hygiene: JavaScript already has a Signal, with different meaning and long-term permanence.

Maybe we can consider a different term? Any name that avoids overloading existing platform terminology would improve long-term clarity for the entire ecosystem.

---

Suggestion: Tracked

• To avoid collisions with abort signals, Remix intends to use track instead of signal
• This proposal already uses "track" to describe the feature
• Ripple.js also uses track, suggesting the term is gaining natural ... traction 😏

It also reads nicely:

let counter = new Tracked.State(0)

Illustrative pseudo-code:

interface TrackedValue<T> {
  read(): T
}

declare namespace Tracked {
  class State<T> implements TrackedValue<T> {
    constructor(initial: T, options?: TrackOptions<T>)
    read(): T
    write(next: T): void
  }

  class Computed<T = unknown> implements TrackedValue<T> {
    constructor(compute: (this: Computed<T>) => T, options?: TrackOptions<T>)
    read(): T
  }

  // ... etc.
}

[ryansolid]

Ripple.js also uses track, suggesting the term is gaining natural ... traction 😏

For what it's worth, Ripple.js doesn't use Signals and probably chose Tracked to differentiate it from Signals. But this is also probably a bit of this ship has sailed sort of thing. Signals as a term has a long term history going back to the 1970s. From the original SRP work through Qt in the 1990s, through to Elm and S.js in the early 2010s.

I do agree there is some overlap here in term of AbortSignals which is unfortunate and since it is standarized it is hard to argue against that even if the other usage even in JavaScript well predates it. But it is also the type of thing that regardless of what name we choose to go with here, Signals will still be used to refer to this technology generically.

I do see the dilemma in terms of documentation, when AbortSignals are used as a core mechanism. That being said when Angular, Preact, Solid, Qwik and others have all agreed on using the name and used that across all their materials and invested in teaching under that name it is unlikely this ambiguity won't continue to exist. But it might exist anyway because of slight differences across versions.

[NullVoxPopuli]

I don't think it's a problem to have the framework-specific implementation be different from the platform implementation.

In order to have compatibility and non-breaking changes, framework authors can only change their implementation, but they keep their APIs the same... so it doesn't matter what the underlying stuff is called.

I dare say it is beneficial to have a core tech have a proper name, for easier SEO, and less conflation.

Because searching for "Signals" (if TC39 Signals ships with that name) will be conflated with everyone else who chose the name, and there will already be subtle differences that people need to learn.

Using a different name improves searchability and clarity in which name has which behaviors

[jkup]

Hey all! We've been having a bit of discussion on this topic as well. Also see Anne's comment in #148 (comment)

I'm wondering if there is a good compromise here, like what @NullVoxPopuli is suggesting. We can pick a web platform safe name for the TC39 Specification itself to avoid spec ambiguity and then framework authors can continue using whatever word they would like? Imagining a future where Solid's createSignal and Remix's Tracked() both use new ReactivePrimitive.State() under the hood?

[atk]

I don't think that there will be confusion between Signal and AbortSignal. The AbortSignal is a void signal (a pattern that we use regularly in our solid-primitives packages) that is triggered to abort the process. You could (and probably should, so you can use any signal to abort without having to wrap it) even use actual signals internally and it would make zero difference to the user.

[jkup]

Just adding as a note but there are multiple places in the web platform that refer to AbortSignals as signal i.e the fetch API https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#canceling_a_request

[EisenbergEffect]

In the spirit of putting all options on the table, one solution could be to make AbortSignal into a reactive Signal. Give it a get() method that returns the aborted state and make it participate in the signal graph (or just make the current aborted property use a signal as its backing field). Now AbortSignal is just a special kind of Signal. I'm pretty sure there are other places in the platform where a similar approach would be useful as well.

[trusktr]

I don't think that there will be confusion between Signal and AbortSignal. The AbortSignal is a void signal (a pattern that we use regularly in our solid-primitives packages) that is triggered to abort the process. You could (and probably should, so you can use any signal to abort without having to wrap it) even use actual signals internally and it would make zero difference to the user.

This is an interesting idea. Here's what that could look like:

const abortSignal = new Signal(false)

// When the signal changes once, the event handler will be removed.
document.addEventListener('foo', handler, {signal: abortSignal}) 

// later, clean up the event handler
abortSignal.set(true)

[trusktr]

make AbortSignal into a reactive Signal. Give it a get() method that returns the aborted state and make it participate in the signal graph

This is an extremely nice-sounding idea too. Here's what that looks like:

// Abort controller is now reduced to a readonly Signal.Computed (backwards compatible)
// where controller.abort() is simply setting an internal writable signal from `true` to `false`:
const controller = new AbortController()
const abortSignal = controller.signal

console.log(abortSignal.get()) // logs "false"

document.addEventListener('foo', handler, {signal: abortSignal}) 

// later, remove the handler
controller.abort()

console.log(abortSignal.get()) // logs "true"

And here's what the same abortSignal from above used in an effect looks like (in Solid-style form):

createEffect(() => {
  if (abortSignal.get()) return // done!

  // otherwise do stuff
  createEffect(() => console.log(someValue.get())
})

^{(Btw, creating a nested effect API seems very awkward and cumbersome to do with Signal.subtle.Watcher, I'd rather that API was replaced with a highly usable Effect API out of the box)}

Currently the way abortController.signal works is blackbox magic that is not accessible to user space, but with Signals it is easily explained! 😍

[ziadkh0]

How would AbortSignal's reason property be handled? Is it also a signal?

[atk]

How would AbortSignal's reason property be handled? Is it also a signal?

If the signal value is falsy, it is not aborted, if it is truthy, it is aborted. A string with a reason is also truthy.

const controller = new AbortController()
console.log(AbortController.signal.get()) // false

controller.abort('manually aborted')
console.log(AbortController.signal.get()) // 'manually aborted'

The implementation can be something simple like:

class AbortError extends Error {}

class AbortSignal extends Signal {
  get aborted() { return !!this.get() }
  get reason() { 
    if (this.get() === true) throw new AbortError("signal is aborted without reason")
    return this.get()
  }
}

class AbortController {
  signal = new AbortSignal(false)
  abort(reason = true) { this.signal.set(reason) }
}