Allow signals sync between component and a service

[tomer953]

Which @angular/* package(s) are relevant/related to the feature request?

No response

Description

Problem

Sometimes we want to sync signals from components to a service (or everywhere else I Assume)

@Component()
export class SomeComponent {
  count = input(0)
  double = computed(() => this.count() * 2)
}

@Injectable()
export class SomeService {
  // Imagine I need the count/double here as well
}

Current solutions

1. using effect() to sync between the component and the service

  effect(() => this.someService.double.set(this.double())

Obviously not the purpose of effects

2. redesign the data-flow so the signal source will be on higher level

this is not always easy to implement, and in some cases even impossible, since we not always control everything

Proposed solution

Allow some new kind of utility to "Proxy" or "Sync" signals

class SomeService {
 // will be updated from the component
 count = syncedSignal<number>();
}

class SomeComponent {
 someService = inject(SomeService)

 count = input(0)
 double = computed(() => this.count() * 2)

 constructor() {
  // "move" the signal to a service
  syncSignal(this.count, this.someService.count) 
 }
}

• probably be one-way only
• worth exploring connect from ngxtension

Alternatives considered

.

[tomer953]

https://stackblitz.com/edit/stackblitz-starters-mcxdxcwe?file=src%2Fmain.ts

Here is a more real-life example, where the consumer of a component needs access to a computed value from the child component.

as for today we can:

1. using effect to move that computed to the service
2. tell consumers to use the componentRef to directly access that computed

[e-oz]

That would be really awesome for stores.

[khalilou88]

I asked something similar here: #59817

[pkozlowski-opensource]

Sometimes we want to sync signals from components to a service (or everywhere else I Assume)

While I understand the motivation here it goes against the philosophy we are trying to establish for signal-based UI. As a general rule we want a single source of truth and any "manual" synchronization goes against this goal. We do believe that having a single source of truth makes it easier to reason about the overall data flow.

Having said all this I think that we can cover the exposed use-case by restructuring code a bit, see: https://stackblitz.com/edit/stackblitz-starters-j7pjoh2g?file=src%2Fmain.ts

[JeanMeche]

One reason I can see that people may want to sync signals is components with input bindings passing a route paramter to the service.
Today this isn't straight foward, you'd need to subscribe to router changes.

[Harpush]

Isn't model a good example of signals "sync"?

There is also for example:
Counter state (say class)
A different place wants to reset the counter based on another state.
The only ways now are:

1. An effect which keeps the counter class separated from the reset orign (on X change call reset on counter)
2. Pass at constructor a signal indicating that when this signal changes a reset is needed (resetSource) and the counter needs to have linkedSignal as state.

2 is more correct but harder to maintain and also makes the counter class a bit weird. 1 seeme better for separation of concerns but requires an effect.

[khalilou88]

@pkozlowski-opensource Thanks for the idea but if I don't need to use a service, do you recommend this approach with functions?

I removed the service here and updated the code :

https://stackblitz.com/edit/stackblitz-starters-7tdcd7j8?file=src%2Fmain.ts

[pkozlowski-opensource]

One reason I can see that people may want to sync signals is components with input bindings passing a route paramter to the service. Today this isn't straight foward, you'd need to subscribe to router changes.

@JeanMeche agreed, but I don't think it justifies a new primitive as we do plan on exposing router-related info via signals.

[pkozlowski-opensource]

Thanks for the idea but if I don't need to use a service, do you recommend this approach with functions? I removed the service here and updated the code : https://stackblitz.com/edit/stackblitz-starters-7tdcd7j8?file=src%2Fmain.ts

Yeh, I think that this pattern works in general

[pkozlowski-opensource]

@Harpush would you mind putting your use-case as a code example in a stackblitz? I find the text description hard to follow / decipher.

[Harpush]

@pkozlowski-opensource I am on phone so will post a code example and will add stackblitz later:

// Using effect (what I want but with sync signal somehow)
export function createCounter(initialCount: number) {
  const value = signal(initialCount);

  function increase() {
    value.update((x) => x + 1)
  }

  function decrease() {
    value.update((x) => x - 1)
  }

  function reset() {
    value.set(initialCount)
  }

  return {
    value: value.asReadonly,
    increase,
    decrease,
    reset,
  }
}

const parent = createCounter(0)
const child = createCounter(0)
effect(() => {
  parent.value()
  child.reset()
})

// Option B - the only "correct" way currently
export function createCounter(params: { initialValue: number; resetSource?: Signal<unknown> }) {
  const value = linkedSignal({
    source: () => params.resetSource?.(),
    computation: () => params.initialValue,
  })

  function increase() {
    value.update((x) => x + 1)
  }

  function decrease() {
    value.update((x) => x - 1)
  }

  function reset() {
    value.set(params.initialValue)
  }

  return {
    value: value.asReadonly,
    increase,
    decrease,
    reset,
  }
}

const parent = createCounter({ initialValue: 0 })
const child = createCounter({ initialValue: 0, resetSource: parent.value})