From Store to Signal: A Paradigm Shift#

Front-end state management has undergone several paradigm shifts over the past decade: from direct DOM manipulation in the jQuery era, to Backbone’s event model, to Redux’s single Store + immutable data flow. Each pattern solved the pain points of the previous one, but also introduced new complexity.

In 2026, Signal has become the mainstream paradigm for front-end state management. It didn’t appear overnight—Knockout.js had the concept of “observables” back in 2010, but it wasn’t until Solid.js pushed it to extreme performance in 2021, and subsequently Svelte 5, Angular, Preact, Qwik, and other frameworks built in support, that Signal truly “broke out.”

So what exactly is a Signal? Why does it make state management simpler and more efficient?

The Core Idea of Signal#

A Signal is essentially an automatically dependency-tracking reactive value container. It consists of three parts:

1. Signal: a reactive container that holds a value
2. Derived: a read-only value computed from other Signals
3. Effect: a function that automatically executes when its dependent Signals change

Represented in the simplest pseudocode:

1
const count = signal(0)           // Create signal
2
const doubled = derived(() => count.value * 2)  // Derived value
3
effect(() => console.log(doubled.value))         // Automatically track dependencies
4

5
count.value = 1  // Output: 2
6
count.value = 2  // Output: 4

The key difference from traditional approaches (such as React’s useState + useEffect) is that Signals don’t require declaring dependency arrays. The framework automatically tracks which Signals are read at runtime, thereby building a precise dependency graph and achieving fine-grained updates—only the DOM nodes that actually depend on the changed data re-render, rather than the entire component tree.

Signal Implementations in Mainstream Frameworks#

1
import { createSignal, createMemo, createEffect } from 'solid-js'
2

3
function Counter() {
4
  const [count, setCount] = createSignal(0)
5
  const doubled = createMemo(() => count() * 2)
6

7
  createEffect(() => {
8
    console.log(`count becomes ${count()}, doubled becomes ${doubled()}`)
9
  })
10

11
  return (
12
    <div>
13
      <p>Count: {count()}</p>
14
      <p>Doubled: {doubled()}</p>
15
      <button onClick={() => setCount(c => c + 1)}>+1</button>
16
    </div>
17
  )
18
}

1
<script>
2
  let count = $state(0)
3
  let doubled = $derived(count * 2)
4

5
  $effect(() => {
6
    console.log(`count: ${count}, doubled: ${doubled}`)
7
  })
8
</script>
9

10
<button onclick={() => count++}>
11
  count: {count}, doubled: {doubled}
12
</button>

1
export function createCounter(initial = 0) {
2
  let count = $state(initial)
3
  let doubled = $derived(count * 2)
4

5
  function increment() {
6
    count++
7
  }
8

9
  return {
10
    get count() { return count },
11
    get doubled() { return doubled },
12
    increment
13
  }
14
}

1
import { signal, computed } from '@preact/signals-react'
2

3
const count = signal(0)
4
const doubled = computed(() => count.value * 2)
5

6
function Counter() {
7
  return (
8
    <div>
9
      <p>Count: {count.value}</p>
10
      <p>Doubled: {doubled.value}</p>
11
      <button onClick={() => count.value++}>+1</button>
12
    </div>
13
  )
14
}

1
import { Component, signal, computed, effect } from '@angular/core'
2

3
@Component({
4
  selector: 'app-counter',
5
  template: `
6
    <p>Count: {{ count() }}</p>
7
    <p>Doubled: {{ doubled() }}</p>
8
    <button (click)="increment()">+1</button>
9
  `
10
})
11
export class CounterComponent {
12
  count = signal(0)
13
  doubled = computed(() => this.count() * 2)
14

15
  constructor() {
16
    effect(() => {
17
      console.log(`count: ${this.count()}, doubled: ${this.doubled()}`)
18
    })
19
  }
20

21
  increment() {
22
    this.count.update(v => v + 1)
23
  }
24
}

Signal vs Traditional Approaches: A Practical Comparison#

Let’s use the same scenario—a todo list with optimistic updates—to compare different approaches:

1
const TodoContext = createContext()
2

3
function TodoProvider({ children }) {
4
  const [todos, setTodos] = useState([])
5
  const addTodo = useCallback((text) => {
6
    setTodos(prev => [...prev, { id: Date.now(), text, done: false }])
7
  }, [])
8
  const toggleTodo = useCallback((id) => {
9
    setTodos(prev => prev.map(t =>
10
      t.id === id ? { ...t, done: !t.done } : t
11
    ))
12
  }, [])
13

14
  return (
15
    <TodoContext.Provider value={{ todos, addTodo, toggleTodo }}>
16
      {children}
17
    </TodoContext.Provider>
18
  )
19
}

1
// store.js (framework-agnostic Signal store)
2
import { signal, computed } from '@preact/signals-core'
3

4
const todos = signal([
5
  { id: 1, text: 'Learning Signal', done: false },
6
  { id: 2, text: 'Writing blog posts', done: false }
7
])
8

9
const doneCount = computed(() => todos.value.filter(t => t.done).length)
10
const totalCount = computed(() => todos.value.length)
11

12
function addTodo(text) {
13
  todos.value = [...todos.value, { id: Date.now(), text, done: false }]
14
}
15

16
function toggleTodo(id) {
17
  todos.value = todos.value.map(t =>
18
    t.id === id ? { ...t, done: !t.done } : t
19
  )
20
}
21

22
export { todos, doneCount, totalCount, addTodo, toggleTodo }

TC39 Signals Proposal: Toward Standardization#

In April 2024, several framework authors (including Ryan Carniato of Solid.js, Rich Harris of Svelte, Marvin Hagemeister of Preact, and others) jointly submitted the Signals standardization proposal to TC39, which is currently at Stage 1.

The proposal’s core API design:

1
// Create Signal (via Signal.State instance)
2
const counter = new Signal.State(0)
3

4
// Read value
5
console.log(counter.get())  // 0
6

7
// Write value
8
counter.set(1)
9

10
// Derive (via Signal.Computed)
11
const doubled = new Signal.Computed(() => counter.get() * 2)
12

13
// Watch for changes
14
const watcher = new Signal.subtle.Watcher(() => {
15
  console.log('Changed')
16
})

An important design decision of the proposal is to not rely on Proxy, but instead implement dependency tracking through explicit .get() / .set() APIs. This allows Signals to be used in environments that don’t support Proxy (such as older browsers), and also makes dependency relationships easier to statically analyze and debug.

How to Choose?#

It should be noted that Vue 3’s ref() and reactive() are conceptually highly consistent with Signals—they are all reactive primitives that automatically track dependencies, support derived computations, and drive side effects. Vue’s reactivity system is based on Proxy, which is one of the differences between it and frameworks like Solid, but the design philosophy is entirely in the same direction.

Conclusion#

In 2026, Signal is no longer a question of “whether to use it,” but rather “your framework already supports it—are you using it?” From Solid.js’s meteoric rise, to Svelte 5’s full embrace, to TC39’s standardization push, Signal is becoming the reactive infrastructure of the Web platform.

For developers, now is the best time to learn Signals: the concepts are simple, the patterns are unified, and they’re transferable across frameworks. When the TC39 proposal finally lands, understanding Signals will become an essential skill for every JavaScript developer, just like understanding Promises.

References:

• TC39 Proposal: Signals — Signals standardization proposal (Stage 1)
• Solid.js Official Docs: Signals
• Svelte 5 Runes Documentation
• Preact Signals Official Guide
• Angular Signals Documentation