Signal & Observable [Updated]

[FrameMuse]

Initial Proposal

There is huge discussion about Signals and Observables, Solid.js is built upon Signals, highly popular library like react-use has useObservable util hook.

"Recently", a Signals proposal appeared and quickly drew attention.

-> Keep reading

---

Now observables are shipped into browsers officially and I introduce a new update to my earlier proposal.

Use cases

The main use-case of introducing signals to React is keeping Component updates Isolated, which React Team (IMHO) hasn't been able to achieve so far.

We know React Context, which is great actually, but it forces all the children of the context provider to reconcile.

What people trying to achieve with Redux, Jotai Atoms and etc. is essentially the same thing - have a "source" (provider) and "sink" (consumer) independent.

"Independent/Isolated" means

• The "atom" doesn't need to be declared as Down Tree Component context, you can set/get it any component.
• You can access the state out of React Component.

Abstract Example (from my previous issue)

import { use } from "react"
import { searchSignal } from "@/signals"

function Images() {
        // Only components that use this signal are updated.
	const search = use(searchSignal)

	return (...)
}

function App() {
        // Parent doesn't need to declare the signal provider.
	return (
		<SearchBar />
		<Images />
	)
}

function SearchBar() {
        // The signal can be updated from anywhere.
	return <input onChange={event => searchSignal.set(event.currentTarget.value)} />
}

This may look as something really simple, but think about a "save" button that sits in the static page header with dynamic body. On click, you want to save changes in the body, but state of your page body and header components are split by really deep components nesting and arrangement - you put React Context, you may say goodbye to your performance and say hello to numerous "unexpected" component effects that may be triggered.

That's where developers came with Redux (essentially an isolated React Reducer) and Jotai Atoms (essentially Signals).

Proposal

Maybe make it a conventional? Here's a 76 lines 100% React-style Signal/Observable implementation that Just Works and looks like official React API. 🫠

import { useEffect, useRef, useSyncExternalStore, type Dispatch, type SetStateAction } from "react"

type Unsubscribe = () => void

interface Signal<T> {
  get: () => T
  set: (value: T) => void
  subscribe: (onChange: () => void) => Unsubscribe
}

interface SignalDispatch {
  dispatch: () => void
  subscribe: (onChange: () => void) => Unsubscribe
}


export function createSignal(): SignalDispatch
export function createSignal<T>(initial: T): Signal<T>
export function createSignal<T>(arg?: T): Signal<T> | SignalDispatch {
  let value = arg
  const subs = new Set<() => void>()

  function get() { return value }

  function set(newValue: T) {
    value = newValue
    dispatch()
  }
  function dispatch() {
    subs.forEach(sub => sub())
  }

  function subscribe(onChange: () => void): Unsubscribe {
    subs.add(onChange)
    return () => subs.delete(onChange)
  }

  if (arg == null) return { dispatch, subscribe }
  return { get, set, subscribe } as never
}

function isSignal<T>(value: any): value is Signal<T> {
  return value instanceof Object && value.get instanceof Function && value.subscribe instanceof Function && value.set instanceof Function
}

/**
 * This is essentially a `useState` hook backed by a Signal.
 *
 * - If passed a plain initial value, it creates and owns a local Signal for the component lifetime.
 * - If passed an existing Signal, it subscribes to that signal and returns its current value + setter.
 *
 * @example
 * const [count, setCount] = useSignal(0) // Local signal.
 * 
 * @example
 * const shared = createSignal(0) // Outside component.
 * const [count, setCount] = useSignal(shared) // Inherit from shared signal.
 */
export function useSignal<T>(signal: Signal<T>): readonly [T, Dispatch<SetStateAction<T>>]
export function useSignal<T>(initialValue: T): readonly [T, Dispatch<SetStateAction<T>>]
export function useSignal<T>(arg: T | Signal<T>): readonly [T, Dispatch<SetStateAction<T>>] {
  // If caller passed an existing signal, use it. Otherwise create a local signal once.
  const signalRef = useRef<Signal<T> | null>(isSignal<T>(arg) ? arg : createSignal(arg as T))

  const signal = signalRef.current as Signal<T>
  const value = useSyncExternalStore(signal.subscribe, signal.get, signal.get)

  function set(action: SetStateAction<T>) {
    signal.set(action instanceof Function ? action(value) : action)
  }

  return [value, set] as const
}
export function useSignalEffect<T>(callback: () => void, signal: Signal<T> | SignalDispatch): void {
  useEffect(() => signal.subscribe(callback), [signal])
}

Explanation

This introduces

• createSignal - just like createContext, creates a signal instance, which is basically Jotai atom or Redux createStore
• useSignal - just like useState but shareable. It can be used to useSignal(123) to create signal in place or to get updated from external signal useSignal(otherSignal) - basically Jotai useAtom or Redux useSelector.
• useSignalEffect - additionally hook to subscribe a callback to updates - useful in cases when the signal is a "Dispatch Signal" (brings no value, just the fact of update).

The React Signal API itself splits into Signal and SignalDispatch, one can pipe values, second one is just to notify.

Usage

In a React application with well defined boundaries, a signal is introduced to connect a "far away" button living in a static header with dynamically update body, where the changes happen.

const someValueSignal = createSignal("")
const anotherValueSignal = createSignal("")
const saveSignal = createSignal()

function DynamicBody() {
  // Component gets updated only when someValueSignal changes, no parent reconciliation.
  const [value, setValue] = useSignal(someValueSignal)

  // Lots of logic...

  return (
    <div>
      <input value={value} onChange={event => setValue(event.target.value)} />
      <input onChange={event => anotherValueSignal.set(event.target.value)} />
      <p>{value}</p>
    </div>
  )
}

function StaticHeader() {
  return (
    <div>
      <button type="button" onClick={() => saveSignal.dispatch()}>Save</button>
    </div>
  )
}

function App() {
  useSignalEffect(() => fetch("api", someValueSignal.get()), [saveSignal])

  return (
    <div>
      <StaticHeader />
      <DynamicBody />
    </div>
  )
}

I used signals for DynamicBody data update as well, but in practice React Context is the choice to ensure that DynamicBody is in the context of related data not Global. But signals are used here to demonstrate that they are useful where we connect components globally, when it's actually reasonable, at the moment we don't care about context, but just want to transfer an event from one "far away" component to another one.

This displays that React Signal API can be a nice addition to React itself and will work well with other APIs too.

Bonus: it can support any Signal-like and Observable-like structures, be just a fancy useSyncExternalStore hook.

[FrameMuse]

There is even Tanstack Store library that basically solving the same problem too.

[tocque]

I think any proposal that introduces a new set of reactive primitives sounds completely unacceptable.
https://github.com/reactjs/rfcs/pull/119 Actually, only add a new parameter is enough for the majority of requirements.
(however, the React team also has no interest in it).

[FrameMuse]

For what reason?

I think any proposal that introduces a new set of reactive primitives sounds completely unacceptable.

---

That's a completely unrelated to what I described in this issue, the React Context API still requires you to update component and re-rendered every children recursively, which IS the problem I'm trying to solve with signals.

https://github.com/reactjs/rfcs/pull/119Actually, only add a new parameter is enough for the majority of requirements.

[tocque]

For what reason?

I think any proposal that introduces a new set of reactive primitives sounds completely unacceptable.

First, a new set of primitives will double the learning cost.

Secondly, having two sets of primitives will cause confusion. As far as I know, signal is a self-consistent reactive system, many other UI frameworks are based on it. I have no doubt that some people will switch to total-signal-base style and then split react into two different frameworks, and react is already confusing enough.

If your motivation is simply to share state between two components that are far apart. I think globalState seems more appropriate.At least it seems to be just a special state, and we can guarantee that it will not be passed around the component by props.

[tocque]

That's a completely unrelated to what I described in this issue, the React Context API still requires you to update component and re-rendered every children recursively, which IS the problem I'm trying to solve with signals.

https://github.com/reactjs/rfcs/pull/119Actually, only add a new parameter is enough for the majority of requirements.

And Actually, under this RFC, the React team directly mentioned signals, as well as their solution to the context performance issue.

[FrameMuse]

@tocque Well, globarStore is basically a signal implementation, just named differently, internally it works exactly the same way I described here. Also, it repeats what Tanstack Store has developed, that's why I mentioned it above.

Then saying globarStore is more appropriate is proving that the problem exists and it's wanted to be resolved, my implementation and proposal does the job.
I think you're against signals just because of their name - I agree on any name - let it by useInsanelySyncGlobalStore, it's ok if it makes you feel better.

btw, I'm not trying to insult or offend you, sorry for sounding rude if so

---

Look, every Signal or Signal-like implementation (even Tanstack Store and globaStore PR), in its core, is 3 methods: get, set, subscribe - it's not new, it exists for eternity. Someone simply came up with "Signals" naming and here we go.

class Signal<T> {
  private readonly callbacks = new Set<(value: T) => void>()
  private value: T

  constructor(initialValue: T) { this.value = initialValue }

  get(): T { return this.value }
  set(value: T): void {
    this.value = value
    this.dispatch(value)
  }

  private dispatch(value: T) {
    this.callbacks.forEach(callback => callback(value))
  }

  subscribe(next: (value: T) => void) {
    this.callbacks.add(next)
    return { unsubscribe: () => void this.callbacks.delete(next) }
  }
}

That's it, this snippet is true for ANY implementation of something you can "subscribe" to.

And this is used in my proposal here as well, I also created a library that is 100% based on this snippet.

---

Just to mention, there is also Closure-based signals, which takes place in https://github.com/tc39/proposal-signals, but in React we historically don't work with such hidden subscribers since React is already handling such implicit reactivity internally.

I know it's hard to tell the difference between Closure-based and Event-based Signals, but my proposal refers exactly to what is commonly accepted in React community - Event-based observations.

• https://github.com/framemuse/event-signal
• https://github.com/FrameMuse/closure-signal