https://ng-journal.com/blog/2023-09-29-feature-flags-in-angular-16/

[utterances-bot]

Feature Flags in Angular 16

Feature flags are a great way to enable or disable features at runtime. This can be useful for A/B testing, canary releases, or just to enable or disable features for specific users. In this article, I will show you how to implement feature flags in Angular 16.

https://ng-journal.com/blog/2023-09-29-feature-flags-in-angular-16/

[spock123]

Very cool, thanks

[pBouillon]

Great article! I was working on a side project providing utilities to manage feature flags (ngx-flagr), this looks pretty similar, glad to be going in the good direction!

[HaasStefan]

@pBouillon, your custom PreloadingStrategy looks really interesting. I ditched the feature flags from the data object of the route because I directly passed them into the guard, but with the custom preloading strategy such data object makes a lot of sense. Kudos!

[amosISA]

@HaasStefan how I can replace the effect() in the directive? Because it is in developer preview.

[HaasStefan]

@amosISA you could replace all the signal stuff with RxJS and make it reactive this way. Then featureFlagEnabled would be a Subject and you could subscribe to it in the directive instead of the effect

[amosISA]

@HaasStefan but why are you using effect() when you ain't using signals?

[HaasStefan]

@amosISA

The facade service is implementing signals which are used in the effect invoked through featureFlagEnabled

export class FeatureFlagsFacadeService {
  readonly #featureFlagsDataService = inject(FeatureFlagsDataService);
  readonly #destroyRef = inject(DestroyRef);

  readonly #state = signal(initialState);
  readonly featureFlags = computed(() => this.#state().featureFlags);

  async loadFeatureFlags() {
    return await lastValueFrom(
      this.#featureFlagsDataService.getFeatureFlags().pipe(
        takeUntilDestroyed(this.#destroyRef),
        tap((featureFlags) =>
          this.#state.set({
            featureFlags,
          })
        )
      )
    );
  }

  featureFlagEnabled(featureFlag: FeatureFlag) {
    return this.featureFlags()?.[featureFlag] ?? false;
  }
}

[amosISA]

oh true, thank you didn't see it. Btw, fantastic work. Keep going!

[DominikPieper]

Great. Thats exactly what we need right now :-)

[christophechevalier]

So cool this Feature Flags !!
This applies to all users.
Let's imagine that you implement authentication, and that there are 4 different types of profiles (admin, dev, employee, simple user), what would it be like to apply the content of a manifest.json per user according to their profile type?
Do you think we need a JSON file per profile type? How would you see it if you were logged in as admin and only you had access to the editing functionality?
I am thinking of recovering the manifest.json after authentication which would be returned by the backend. Thus, this would allow access to the feature of my application to be defined according to the connected profile.

Thank you for your work as usual, your articles are fantastic.

[christophechevalier]

Or quite simply, when connecting, providing the manifest-admin.json corresponding to the connected profile (admin for example). All the manifest.json files would be defined in the assets folder like in your example.

[HaasStefan]

@christophechevalier I would handle Permission Management pretty similar, first authentication needs to happen and the backend must return the role of the user and a permission config (or manifest) has to be loaded upfront (probably in the APP_INITIALIZER) and then I would also work with canMatch guards for permissions, and a hasPermission/hasRole directive tailored to the permission logic. Hope this helps?

[christophechevalier]

That's perfect, thank you for your response.

[rfreydi]

Hi @HaasStefan, it look like you rebuilt your site and the repository it target, the article is no more available and I can't find any content in the history.

Where can I find it (url or md) ?

[HaasStefan]

@rfreydi I changed it to the old blog again. I intended to move the old blog posts to the new blog, but it did not really take off and I no longer have enough time to host this project. The original version of NG Journal will stay up now.