Collection of Signal Patterns

[oravecz]

Probably not the most ideal spot for this, but as Signals explode in popularity across multiple frameworks, I can't seem to find a set of common patterns for using Signals. So, I thought we might use this discussion to collect them.

[oravecz]

Debounce for Signal

export const debounceSignal = <T>(
  targetSignal: Signal<T>,
  timeoutMs = 0,
): Signal<T> => {
  const debounceSignal = signal<T>(targetSignal.value);

  effect(() => {
    const value = targetSignal.value;
    const timeout = setTimeout(() => {
      debounceSignal.value = value;
    }, timeoutMs);
    return () => {
      clearTimeout(timeout);
    };
  });

  return debounceSignal;
};

[oravecz]

Here is a use case that came up today. We have a separate signal for each type of filter that drives the resource's fetcher.

As the user makes choices (e.g. clientNameSignal, clientStatusSignal, clientTypeSignal) that will affect the query parameters, we wanted a signal (clientCriteriaSignal) that collects these updated values, but doesn't notify its own subscribers until some sort of "trigger".

There are alternative ways to model this using booleans as triggers or duplicating some state in local variables, but I was wondering if there is a better pattern or whether this is a good use case to come up with a DeferredNotificationSignal or TriggerNotificationSignal that exposes a notify() method which will then notify subscribers, but otherwise holds its state.

[andywilsonuk]

I think you could achieve this using the existing signal functionality, something like:

const notify = signal(0)

const trigger = () => {
  // be a writer but not a reader
  notify.value = notify.peek() + 1
}

effect(() => {
  // subscribe to the signal
  if (notify.value > 0) {
    // do something
  }
})

It doesn't hold state like you mentioned however does have the advantage over boolean signals, in that there's no need to set the signal back to false once it has been processed.