Proposal: Signals

[Keyslam]

Proposal: Signals

Signals provide a reactive programming system that automatically updates when data changes. The system includes three main types of signals: Signal, Computed, and Effect. Each signal can be a source of data, a consumer of data, or both, allowing data to flow in one direction and update automatically.
Signals will form the basis of 'props' for UI elements.

Code example:

-- Create a source signal for a counter
local counter = Signal(0)

-- Create a computed signal that depends on the counter
local doubled = Computed(function()
    return counter() * 2
end)

-- Create another computed signal that depends on both signals
local isEven = Computed(function()
    return doubled() % 2 == 0
end)

-- Create an effect that runs whenever any of its dependencies change
Effect(function()
    print(string.format(
        "Counter: %d, Doubled: %d, Is Even: %s",
        counter()
        doubled()
        isEven() and "Yes" or "No"
    ))
end)

-- Update the counter, which will automatically update all dependent signals
counter:set(5)  -- Prints: Counter: 5, Doubled: 10, Is Even: Yes
counter:set(3)  -- Prints: Counter: 3, Doubled: 6, Is Even: Yes
counter:set(7)  -- Prints: Counter: 7, Doubled: 14, Is Even: Yes

API

Signal

Creates a source signal that can be manually updated.

Signal(initialValue: any): Signal

Methods:

• signal(): any / signal:get(): any
  • Returns the current value of the signal
• signal:set(newValue: prev): void
  • Sets the signal's value
• signal:update(fn: (curr: any) => any): void
  • Updates the signal's value with the result of the function, passing in the current value

Computed

Creates a computed signal that automatically updates based on its dependencies.

Computed signals are lazy - they only compute their value when accessed

Computed(fn: () => any): ComputedSignal

Methods:

• signal(): any / signal:get(): any
  • Returns the current value of the signal

Effect

Creates an effect that runs whenever its dependencies change.

Effect(fn: () => void): EffectSignal

Methods:

• effect:destroy() -> void
  • Destroys the signal

Notes

• All signals automatically track their dependencies when accessed
  • Dependencies may change over time; when one signal is accessed conditionally based on another signal
• Updates propagate in one direction only, preventing circular dependencies
• Effects run synchronously when their dependencies change

[pablomayobre]

This looks great. I'd like a few specifications on:

Nested Signals/Effects/Computed properties

What happens when you create a signal, effect or computed value inside of an effect or computed value? Is that dissallowed? Do we track them and destroy them whenever the effect re-runs?

This is important for components that act as effects, but effects, computed values and signals may be created during their execution. When they are destroyed we wanna remove all traces of them including all these signals and effects that were created inside of them.

Changing Dependencies

When an effect runs and the dependencies change, do we remove all previous dependencies and replace with the new ones?

Atomic Updates

Is there a way to batch multiple updates to avoid re-running effects when we need to update multiple values all at once? This is good for atomic updates

local a = signal(0)
local b = signal(0)

effect(function ()
  print(a() + b())
end)

a:set(1)
-- prints: 1
b:set(2)
-- prints: 3
batch(function ()
  a:set(4)
  b:set(5)
end)
-- prints: 9

Signal destruction

What happens when an effect depends on two signals, one gets destroyed and the other gets updated?
Do we forbid signal destruction?

Effect Arguments

Do we wanna support this pattern?

effect(function (a, b)
  print(a + b + signal())
end, 1, 2)

Computed vs Effects vs Functions

Is computed a wrapper around effects?

-- With computed we can do something like:
local value = signal(0)
local double = computed(function ()
  return value() * 2
end)

-- Using effect we can do the same thing like so:
local value = signal(0)
local double = signal(0)

effect(function ()
  double:set(value() * 2)
end)

-- We can define computed as:
function computed (func)
  local c = signal(func())

  effect(function ()
    c:set(func())
  end)

  return c
end

You mention that computed values are lazy, would you recompute on every invocation? If that's the case, what's the difference with just a function?

-- With computed we can do something like:
local value = signal(0)
local double = function ()
  return value() * 2
end

[Keyslam]

I'll answer the questions in order:

Nested Signals/Effects/Computed properties
Honestly, I'm not sure. My first instinct is that signals may not be created within other signals, but maybe there's some valid use case for that. I think we'll have to get back to it later when we have a concrete implementation to test around with.

Changing Dependencies
Yes. Every time a computed/effect runs it's dependencies may change, for example:

local _ = computed(function()
  if (a()) then
    return b()
  else
    return c()
  end
end

Sidenote: As a user you can get around that by doing

local _ = computed(function()
  local b = b()
  local c = c()

  if (a()) then
    return b
  else
    return c
  end
end

Signal destruction
signal and computed can not be destroyed, only effects. Signals will be "destroyed" once all references to it are gone.

Effect Arguments
Sure, I don't see any reason why not.

Computed vs Effects vs Functions
The difference between computed and effect is that effect will run when a dependency changes, whereas a computed will run when a dependent asks for it's value, for this it must also propagate upwards when it's value may have changed.

Your function example doesn't work, because the function wont get signaled when the dependency changed.

[pablomayobre]

My first instinct is that signals may not be created within other signals

Yeah I feel like creating a new signal during a computed doesn't make much sense... but to me computed already is in an odd position where most of its behavior can be solved through other means.

Every time a computed/effect runs it's dependencies may change

Agreed here, whenever we run we reset dependencies to whatever the effect is now consuming.

Signals will be "destroyed" once all references to it are gone

Sounds good!

Your function example doesn't work, because the function wont get signaled when the dependency changed.

Aaaaactually, the function works because the signals are called while the effect executes, so the effect knows that the signals are required to compute the value.

local a = signal(0)
local b = signal(0)

local addition = function ()
  return a() + b()
end

effect(function ()
  print(addition())
end)

a:set(4) -- prints 4
b:set(5) -- prints 9

This is equivalent to:

local a = signal(0)
local b = signal(0)

effect(function ()
  print(a() + b())
end)

a:set(4) -- prints 4
b:set(5) -- prints 9

If you want memoization then yeah computed makes more sense, cause you need to forward dependencies even if you are returning a memoized value (not recomputing it)