Usage patterns and library-author api design (for consumers of signals)

[NullVoxPopuli]

For example, if we're creating an object that needs reactive access to data, we don't need to expose the underlying implementation -- we can rely on getters (and setters, if needed), to make signals behave like "just javascirpt properties".

In providing a reactive property to a class, Board, we can define a property, previous that just is reactive, because it delays the read of the signal until the read of the previous property.

Shown here, using the @signal decorator idea from the readme:

class Demo {
  @signal previous = ...;
  
  // a class method(tm)
  createBoard = (x, y) => {
    let state = this;
    return new Board(x, y, {
      get previous() {
        return state.previous; 
      }
    });
  };
}

or using signals directly, maybe, less tied to what I'm immediately working on:

import { Signal } from "signal-polyfill";

const previousSignal = new Signal.State(/* ... */);

return new Board(x, y, {
  get previous() {
    return previousSignal.get(); 
  }
});

With this approach, the API of Board doesn't need to change to support any style of signals.

---

So, I suppose, more generally, should we try to come up with a list of tips'n'things like this?

My worry, is that we'll give folks a sharp tool, and they'll leave sharp edges on their api boundaries (or other places!), which make broader usage of Signals (or rather the integration between JS Frameworks) potentially more difficult.

[littledan]

Yes, let’s definitely document this stuff, while acknowledging the range of opinions on what the surface should look like (not picking sides).