Add channel based signals

[denisboreyko97]

Here is the functionality with detailed comment that I would add to signals library. It solves the problem when I want to connect separate components on the page through signals, but I do not want one component to update all instances of another one which is dependent through signals. instead I would create channel based signal and would change signal for specific channel, to update only specific instances of dependent components

/**
 * Initializes a channel-based signal manager that enables isolated reactive state
 * management across multiple named channels. Each channel holds an independent signal,
 * allowing decoupled control for components sharing common logic.
 *
 * Example usage:
 * const mySignal = $channelSignal();
 * mySignal.setForChannel('PageChannel1', true);
 * const current = mySignal.forChannel('PageChannel1');
 *
 * This is particularly useful for generic components—like pagination—that rely on reactive state.
 * Consider a scenario where multiple paginated tables are rendered on the same page:
 * 
 * With a single signal:
 * const pageNumber = $signal(1);
 * 
 * Every pagination instance would trigger updates across all tables via a shared effect:
 * $effect(() => {
 *     if (pageNumber.value !== this.pageNumber) {
 *         this.pageNumber = pageNumber.value;
 *     }
 *     this.fetchCurrentPage();
 * });
 *
 * Replacing it with a channel-based signal isolates each table’s pagination:
 * const pageNumber = $channelSignal();
 * 
 * Each Pagination component assigns its own channel:
 * 
 * export default class Pagination {
 *     @api channel;
 *     
 *     setPage(event) {
 *         pageNumber.setForChannel(this.channel, event.detail.value);
 *     }
 * }
 * 
 * export default class GenericTable {
 *     @api channel;
 *     pageNumber;
 * 
 *     connectedCallback() {
 *         $effect(() => {
 *             this.pageNumber = pageNumber.forChannel(this.channel).value;
 *             this.fetchCurrentPage();
 *         });
 *     }
 * }
 *
 * This approach prevents unwanted cross-updates and keeps component state scoped to its context.
 *
 * @function
 * @returns {Object} An object containing `forChannel` and `setForChannel` methods
 *                   for managing per-channel signals.
 *
 * @property {Function} forChannel - Retrieves or initializes a signal for a given channel.
 * @param {string} channel - The channel identifier.
 * @param {*} [defaultValue] - Initial value if the signal is newly created.
 * @param {Object} [options] - Optional signal configuration.
 * @returns {*} The signal linked to the provided channel.
 *
 * @property {Function} setForChannel - Updates the signal value for a specified channel.
 * @param {string} channel - The target channel name.
 * @param {*} value - New value to assign.
 * @param {Object} [options] - Optional signal configuration.
 */

function $channelSignal() {
  return {
    forChannel: function(channel, defaultValue, options) {
      if (!this[channel]) {
        this[channel] = $signal(defaultValue ?? undefined, options);
      }

      return this[channel];
    },
    setForChannel: function(channel, value, options) {
      if (!this[channel]) {
        this[channel] = $signal(value, options);
      } else {
        this[channel].value = value;
      }
    }
  };
}

[cesarParra]

Thanks @denisboreyko97

I like it the idea!

A few comments/questions:

• Instead of creating a new $channelSignal endpoint, could it be possible to have a new option when creating the signal that allows for the consumer to optionally pass the channel name through which the signal is broadcast? I'm not opposed to adding new endpoints, but if possible I'd like to keep the surface area of the API smaller. But let me know if it makes sense for the use case
• If we do end up adding a new endpoint, instead of having to first create the $channelSignal and then having to call setForChannel, could the channel name be passed directly in the initial call?

[denisboreyko97]

We can try to play with $signal function to support channels, but for me it looks difficult for now as I need to consider all the logic we have inside.

As for passing channel while initializing channelSignal - e.g. in my case it does not work, because the purpose of this is to create an object that can create and provide signals for different channels. Let me give you an example.

I have searchInput component, which is exposed to use within the community. I have 2 different exposed components on the community - products, accounts table

Whenever something is changed in searchInput(I mean user enters something), I need to handle it in accounts table (or products) or any other component that can have interaction with search input. Note that searchInput is a separate exposed component that can be put anywhere on the page.

With signals I implement it so:

// searchService component
searchService.js

export const searchTerm = $signal(undefined);

// searchInput component

import { searchTerm } from 'c/searchService';

export default class SearchInput extends LightningElement {
    handleSearchChange(event) {
        searchTerm.value = event.target.value;
    }
}

// accounts table

import {.searchTerm } from 'c/searchService'

export default class AccountsTable extends LightningElement {
    connectedCallback() {
        $effect(() => {
            if (searchTerm.value) {
                this.filterAccounts();
            }
        });
    }
}

// products

import {.searchTerm } from 'c/searchService'

export default class Products extends LightningElement {
    connectedCallback() {
        $effect(() => {
            if (searchTerm.value) {
                this.filterProducts();
            }
        });
    }
}

Now, what's happening if we have 2 search inputs on the page and products + accounts table:

One searchInput is above accounts table, another one is above products, but they both impact products & account table

It happens because we have only one shared signal that is imported and changed by different instances of searchInput

So to resolve such kind of issue, I created $channelSignal(), which does not have any channel while init, because we assume that there are multiple searchInputs, that work with the same signal but for different channels,

so we just change searchService.js with

// here we still do not know which channels will use it
const searchTerm = $channelSignal();

in searchInput we create a property named channel and instead of doing:

searchTerm.value = event.target.value;

we do:

searchTerm.setForChannel(this.channel, event.target.value);

products implementation is replaced to the following:

$effect(() => {
    if (searchTerm.forChannel('Products').value) {
        this.filterProducts();
    }
});

and accountsTable is replaced to

$effect(() => {
    if (searchTerm.forChannel('AccountsTable').value) {
        this.filterAccounts();
    }
});

So it means that searchService.js is not aware, which channels will use it. We just add capability to manage searchTerm signal by different channels.

As a result, if 2 Products and Accounts Table are both on the page and we have 2 searchInputs, our channelSignal will have the following structure at some point:

{
    Products: $signal(),
    AccountsTable: $signal(),
    setForChannel: ...,
    forChannel: ...
}

If we have only Products component on the page then structure is:

{
    Products: $signal(),
    setForChannel: ...,
    forChannel: ...
}

[cesarParra]

Thanks for the detailed example, that's clarifies the purpose for me, that makes sense!

Would you be willing to put up a PR for this with your proposal? For contributions they should be in Typescript and go to the src folder: https://github.com/cesarParra/lwc-signals/tree/main/src, and you can build the js files by running npm run build. This will update the LWC service that can be imported to the Salesforce project.

[denisboreyko97]

I tried but I can not push to branch created from main

[denisboreyko97]

[cesarParra]

You'll have to fork it and that'll allow you to many any desired changes in your own version of the repo: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo, then you can follow the contribution guide to set up a PR https://github.com/cesarParra/lwc-signals/blob/main/CONTRIBUTING.md

[denisboreyko97]

Okay, got it. Will fork tomorrow then