Convert back decorated property accessor to signal (with `.get`/`.set`) for 3rd party libs to use.

[JulianCataldo]

@vtaits/react-signals or use-signals are expecting a Signal.State or a Signal.Computed in their hooks arguments.

Is there a way to "desugar"/"unwrap" a property decorated with an accessor (@signal)?
Right now, we can't use these implementations with those.

Maybe wrapping them in a computed each time? (seems a bit clunky)

Thanks :)

[NullVoxPopuli]

yeah, you could do something like this:

class ReWrapped {
  @signal accessor #data = 0;

  get() {
    return this.#data;
  }

  set(value) {
    this.#data = value;
  }
}

@vtaits/react-signals or use-signals are expecting a Signal.State or a Signal.Computed in their hooks arguments.

any library working with signals may want to think about narrowing in on their APIs that they actually use, rather than require whole-objects.

For example:

function update(signal: Signal.State) {
  signal.set('updated');
}

only declare the API that you're going to use:

function update(signal: Pick<Signal.State, 'set'>) {
  signal.set('updated');
}

that would make this possible:

update({ set: console.log });
update({ set: (value) => myApi(value) })
update({ set: (value) => this.foo = value });

which is handy for more flexible types of data, testing, etc

[JulianCataldo]

The rewrapper is an interesting idea, I can see where this can be useful! Thx

For my current project, I think I'll keep an API like below for now. Keep in mind it's for a distributable library, not for app development, so internal DX is good for just me, but priority goes to consumers, for whom I can't predict how they gonna handle my signals. Can't make definite asumptions ^^.

// ...

  public readonly $isDragging = signal(false);
  public get isDragging(): boolean {
    return this.$isDragging.get();
  }
  public setIsDragging(state: boolean): void {
    this.$isDragging.set(state);
  }

// ...

Handful of reasons:

1. Decorators are still heavy, not a prob' for an app but for a lib it's definitely an issue.
2. the $ is a bit ugly, but nanostores or svelte use this kind of token, so it's explicit what is reactive, or a "store", and what is a plain old JS value.
3. The getter is handy, especially in the consumer app' templates, so type-guards smoother, and everything is less verboce.
4. But you still get the .set and .get in the signal object for 3rd parties. .set is not supposed to be used much, the action method is here to change the signal value, and trigger side-effects when needed.

Yes, it's definitely more verbose than with decorators, but at the same time it offers more possible use cases.

[NullVoxPopuli]

makes sense -- yeah. Before decorators land everywhere, the need to transpile them feels a little silly.
Implementations are currently in progress, as far as I know though -- so consumers wouldn't need to care that you're using a decorator -- it would "just work" (albeit, not the case today).

for efficient decorator transforming, you wouldn't want to use babel at all, either -- babel tacks on a ton of legacy transforms -- instead you'd want something like this transform: https://github.com/ef4/decorator-transforms -- it's much lighter, and has saved me 15-20% of pre-gzip bytes compared to babel.

Soon native 🤞