feat(service): use of signal

[rbalet]

Current behavior

We need to be working with subscription.

Expected behavior

Although this is good the way it is, it could be nicer to add additional signal alternative.

What is the motivation / use case for changing the behavior?

1. It would let us work with computed variable directly
2. It will lower the chances of forgotten unsubscription

How do you think that we should implement this?

I can do a PR if needed

I do see two options

1: Additional variable

Inside the translate.service.ts, add of additional signal for reach observable

// Exemple

  $onTranslationChange = toSignal(this.store.onTranslationChange)
  get onTranslationChange(): Observable<TranslationChangeEvent> {
    return this.store.onTranslationChange;
  }

2: Replacement of the former logic

I'd avoid this as this is quite a breaking change

Same as 1. but we remove the onTranslationChange() method. which let you write it as follow.

onTranslationChange = toSignal(this.store.onTranslationChange)

I do personally always use the $ in front of a signal, but standards aren't set yet for the nomenclature

[floAtEbcont]

@rbalet You only addressed onTranslationChange, but to be consistent, I think get() should have a signal equivalent too - here's a method that works for me:

class ExtendedTranslateService extends TranslateService {
  translate(
        key: string | Signal<string>,
        params?: Record<string, string | number | null | undefined> | Signal<Record<string, string | number | null | undefined> | undefined>,
    ): Signal<string | undefined> {
        const key$ = toObservable(isSignal(key) ? key : signal(key));
        const params$ = toObservable(isSignal(params) ? params : signal(params));

        const translation$ = key$.pipe(switchMap((key) => params$.pipe(switchMap((params) => this.get(key, params)))));

        return toSignal(translation$);
   }
}

This can than be used like this for example:

class MyComponent {
  readonly amount = computed(() => this.someComputation());
  readonly someReactiveTranslation = this.extendedTranslateService.translate('myKey', computed(() => ({
    amount: this.amount()
  }));
}

[rbalet]

@floAtEbcont yes indeed, every method would have their equivalent.

It was just for the sake of simplicity

[homj]

Thank you for opening this issue @rbalet. Signals are essential for modern angular development and should be supported by ngx-translate asap.

This should also extend to actual translation. I propose to add a method similar to stream, that returns a signal which reacts on lang or translation change. We could simply call this method translate

[rbalet]

@homj it is true that, if you add the $ in front of the variable, you could not need the on...Change as it is per syntax already understandable

[floAtEbcont]

@homj

This should also extend to actual translation. I propose to add a method similar to stream, that returns a signal which reacts on lang or translation change. We could simply call this method translate

This is exactly what I suggested and provided a workaround for further up, right?

[EinfachHans]

@rbalet is there a target branch for v18 already? I'm considering working on a PR for that.
Any additional informations/hints you would like to place for the implementation?

[rbalet]

Hey @EinfachHans, thanks for the proposition.

We're sadly on pause till we find the best solution for the following discussion: #1599

So I wouldn't invest much time till we get done with it.
But I'll text you back once we could make a stable version.

Don't hesitate to take part of the discussion, all the help are always welcome

[CodeAndWeb]

onTranslationChange() and use() will not be able to provide translations anymore through the observable.
This is because we won't have a combined store that contains all translations.
So it would practically only be bool or void - just to inform the users about the change.

Adding that translate() signal sounds good for me - how ever it's not sufficient like in the implementation by @floAtEbcont it should also recalculate on onLangChange, onTranslationChange and onFallbackLangChange .

Introducing a combined observable for all of these 3 would make sense and simplify the code.

[rbalet]

@CodeAndWeb
Linked proposition : https://github.com/ngx-translate/core/tree/feat/signals

Note:

• I have not yet implemented the tests as I'd prefer being sure about this new implementation before moving forward
• I'm Also, wondering how much sens it'll make as the older way of doing will mostly be deprecated
• When we're honest, maybe it's better to drop the backward compatibility as we both have not that much time to maintain it (But if wished I will invest the required time)

@homj Care to do your stream approach on my PR ?
@EinfachHans Would you be open to give it a look, what do you think of this implementation ? (I'm open to any suggestion)
@floAtEbcont I did change every observable andalso the get. Let me know what you think or if you see something's missing