feat: add feature flag service for angular

[lukas-reining]

NOTE: This is still a draft for discussion!

This PR

Adds a service for evaluating flags in angular services.
It enables application authors to evaluate flags directly as observables or signal.

I am not 100% sure about returning signals or leaving the toSignal to the application autors.
As far as I understand, when used like the following, subscriptions for toSignal will still be cleaned up correctly, as the injection context will be captured correctly in that case:

@Component({
  template: `
    <div data-testid="value">{{ thumbs()?.value ? '👍' : '👎' }}</div>
    <div data-testid="reason">reason: {{ thumbs()?.reason }}</div>
  `,
  standalone: true,
})
class TestSignalComponent {
  private flagService = inject(FeatureFlagService);
  thumbs = this.flagService.getBooleanDetailsSignal(FLAG_KEY, false);
}

Edit: We decided to leave the toSignal to the app authors.

@juanparadox please leave feedback.

I still have to clean up the tests and the code in general, if we decide this is the design we opt for.

[beeme1mr]

@lukas-reining, what would it look like if you left the toSignal up to the author? Your proposal looks good to me but it has been years since I've used Angular.

[lukas-reining]

@lukas-reining, what would it look like if you left the toSignal up to the author? Your proposal looks good to me but it has been years since I've used Angular.

@Component({
  template: `
    <div data-testid="value">{{ thumbs()?.value ? '👍' : '👎' }}</div>
    <div data-testid="reason">reason: {{ thumbs()?.reason }}</div>
  `,
  standalone: true,
})
class TestSignalComponent {
  private flagService = inject(FeatureFlagService);
  thumbs = toSignal(this.flagService.getBooleanDetails(FLAG_KEY, false));
}

@beeme1mr it would just be removing the methods for signals and wrapping the observable methods in toSignal as seen above.

[juanparadox]

@lukas-reining, what would it look like if you left the toSignal up to the author? Your proposal looks good to me but it has been years since I've used Angular.

@Component({
  template: `
    <div data-testid="value">{{ thumbs()?.value ? '👍' : '👎' }}</div>
    <div data-testid="reason">reason: {{ thumbs()?.reason }}</div>
  `,
  standalone: true,
})
class TestSignalComponent {
  private flagService = inject(FeatureFlagService);
  thumbs = toSignal(this.flagService.getBooleanDetails(FLAG_KEY, false));
}

@beeme1mr it would just be removing the methods for signals and wrapping the observable methods in toSignal as seen above.

This would mean that the user can choose to consume the evaluation as an Observable or as a Signal, right? If that is the case, and if it is also the case that Angular wants to continue supporting both Observables and Signals, then I really like the approach of leaving toSignal to the user. This creates more flexibility in how the evaluation results are used/consumed.

[lukas-reining]

This would mean that the user can choose to consume the evaluation as an Observable or as a Signal, right? If that is the case, and if it is also the case that Angular wants to continue supporting both Observables and Signals, then I really like the approach of leaving toSignal to the user. This creates more flexibility in how the evaluation results are used/consumed.

Exactly, I also lean towards only having the observables in the API of the service. Having it in would just be hiding toSignal from the app authors.

[juanparadox]

This would mean that the user can choose to consume the evaluation as an Observable or as a Signal, right? If that is the case, and if it is also the case that Angular wants to continue supporting both Observables and Signals, then I really like the approach of leaving toSignal to the user. This creates more flexibility in how the evaluation results are used/consumed.

Exactly, I also lean towards only having the observables in the API of the service. Having it in would just be hiding toSignal from the app authors.

Okay cool - I'd lean for leaving the toSignal out then 👍

[lukas-reining]

Okay great!
This is ready to review now, I tried to make it similar to how React works @toddbaert.
Would be happy about a review @beeme1mr @juanparadox @toddbaert :)

[juanparadox]

I like it - straightforward and easy to understand how it's used for both Observables and Signals 👍

[beeme1mr]

Should we move this to core? I could go either way since it's small and is unlikely to change but the same function is also in the React SDK.

[beeme1mr]

When will this callback fire? Sorry if it's a basic question, I'm not that familiar with Observables. I just want to make sure we're not prematurely unregistering the handlers.

[beeme1mr]

Could you add a JSDoc to explain these config options? It would help the developer to understand when to provide a Provider and when it's okay to omit that value. Thanks!

[beeme1mr]

This is clever. I know why you did this but future me may not. Could you please add a comment explaining why this was necessary?

[beeme1mr]

Why do you need the ?? Won't value always be there once the flag been evaluated?