refactor(generator/angular): extend FeatureFlagDirective<T> instead of using hostDirectives

[tomflenner]

This PR

Refactors the Angular generator to generate directives extending FeatureFlagDirective<T> instead of wrapping BooleanFeatureFlagDirective via hostDirectives.

Previously, the generator relied on hostDirectives to map inputs from a generated directive to <Type>FeatureFlagDirective.

This approach fails when the underlying directive defines required inputs (@Input({ required: true })), because Angular enforces required inputs at compile time even if values are set programmatically in the constructor or via lifecycle hooks such as ngOnInit.

This resulted in compilation errors such as:

Required input 'xyz' from directive BooleanFeatureFlagDirective must be specified.ngtsc(-998008)

To resolve this limitation, the generator now:

• Generates a directive extending FeatureFlagDirective<T>
• Pre-configures the flag key and default value internally
• Maps prefixed inputs directly to the base directive properties
• Removes usage of hostDirectives

This approach avoids Angular required input validation issues and provides a more robust long-term solution for generated structural directives.

Related Issues

Fixes #217

Notes

• This change requires FeatureFlagDirectiveContext<T> to be exported from the Angular SDK (see [FEATURE] export FeatureFlagDirectiveContext for directive extension support js-sdk#1345).
• No breaking changes are introduced at the CLI interface level.
• The generated output is slightly more coupled to the Angular SDK internals, but avoids Angular compiler constraints related to required inputs.
• A smoke test was added to validate that generated Angular directives compile successfully in a minimal Angular setup.

Thanks for the DataGalaxy frontend folks that helped on that refactor 🙏🏻

Follow-up Tasks

• Check with maintainers how to communicate about the minimum Angular SDK version required to run the generated code in a Angular app (since we need FeatureFlagDirectiveContext<T> to be exposed).

How to test

1. Run the integration test suite using make test-integration
2. Generate Angular code from a sample configuration:

openfeature generate angular -i path/to/manifest.json -o output/directory

[gemini-code-assist]

Summary of Changes

Hello @tomflenner, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant architectural change to the Angular generator, moving away from hostDirectives for feature flag directives. The new approach involves generated directives directly inheriting from FeatureFlagDirective<T>, which effectively circumvents Angular's strict compile-time validation for required inputs. This refactor enhances the reliability of the generated code, preventing common compilation failures and providing a more robust foundation for integrating feature flags into Angular applications.

Highlights

• Refactored Angular Generator: The Angular generator has been refactored to generate directives that directly extend FeatureFlagDirective<T> instead of using hostDirectives.
• Resolved Compilation Errors: This change resolves compilation errors that occurred when using hostDirectives with underlying directives defining required inputs, as Angular enforces these at compile time.
• Direct Input Mapping: Generated directives now pre-configure the flag key and default value internally and map prefixed inputs directly to the base directive properties.
• New Integration Test: A smoke test was added to validate that generated Angular directives compile successfully in a minimal Angular setup.

Changelog

• .gitignore
  • Added **/obj/ to ignore test output directories.
• internal/cmd/testdata/success_angular.golden
  • Updated imports to include ChangeDetectorRef, Input, OnChanges, TemplateRef, ViewContainerRef, FeatureFlagDirective, and FeatureFlagDirectiveContext.
  • Removed imports for specific BooleanFeatureFlagDirective, NumberFeatureFlagDirective, ObjectFeatureFlagDirective, and StringFeatureFlagDirective.
  • Modified generated directives to extend FeatureFlagDirective<T> and implement OnChanges.
  • Removed hostDirectives configuration from generated directives.
  • Added _changeDetectorRef, _viewContainerRef, and _thenTemplateRef injections to generated directives.
  • Introduced @Input properties for flag key, default value, and Value (for non-boolean flags).
  • Implemented ngOnChanges lifecycle hook to set base class properties.
  • Added @Input setters for Domain, UpdateOnConfigurationChanged, UpdateOnContextChanged, Else, Initializing, and Reconciling properties.
• internal/generators/angular/angular.go
  • Removed the sdkDirectiveType helper function.
  • Removed the SdkDirectiveType entry from the template function map.
• internal/generators/angular/angular.tmpl
  • Updated import statements to reflect the new directive structure.
  • Removed conditional logic for determining specific SDK directive types and prefixes.
  • Modified the directive template to generate classes that extend FeatureFlagDirective<T> and implement OnChanges.
  • Added template code for injecting ChangeDetectorRef, ViewContainerRef, and TemplateRef.
  • Added template code for @Input properties for flag key, default value, and Value.
  • Added template code for the ngOnChanges implementation.
  • Added template code for @Input setters for various directive properties.
• test/angular-integration/specs/ngtsc-compile.spec.ts
  • Added a new integration test to verify that generated Angular directives compile successfully using ngtsc without issues related to required inputs.

Activity

• The author, tomflenner, created this pull request to address a known compilation issue with Angular's hostDirectives and required inputs.
• A new smoke test was added to validate that generated Angular directives compile successfully in a minimal Angular setup.
• The author noted that this change requires FeatureFlagDirectiveContext<T> to be exported from the Angular SDK and mentioned a follow-up task to communicate minimum Angular SDK version requirements.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This is a great refactoring that addresses a fundamental limitation with Angular's handling of hostDirectives and required inputs. The new approach of extending FeatureFlagDirective<T> is much more robust and cleaner. The addition of a compile-time integration test using ngtsc is an excellent way to ensure this issue is resolved and doesn't regress. I have one suggestion to improve the generated code.

[tomflenner]

On hold, waiting for : open-feature/js-sdk#1346 to be merged and a new angular SDK version in order to have access to FeatureFlagDirectiveContext<T>

[tomflenner]

After running into several issues while integrating the generated directive, I decided to update the generated JSDoc accordingly. The goal is to better guide end users on the correct usage, especially clarifying microsyntax vs. property binding.

We also updated the name of the generated directive to explicitly include FeatureFlag, in order to avoid naming conflicts with end-user, domain-specific directives that may already exist in applications.

For example, in production we have an event-logs feature flag covering the event log system, while the frontend already exposes an existing EventLogDirective. Without this change, the generated directive name could easily conflict with domain-level concepts.

Additionally, a note was added documenting the minimum required Angular version for this code to work reliably.

Finally, I completed a series of smoke tests covering multiple scenarios we encountered when using the directive in production. These tests reflect real-world usage patterns, and based on the results, the current implementation appears stable and ready for use ✅

[kriscoleman]

Great work, not just patched the bug, but also bolstered tests. The bug fix cleaned up some code too. Thanks for your contributions!

[lukas-reining]

Thank you so much @tomflenner!
I have tried generating the flags and it looks great!
The docs are very good, I think is gives all information needed to just use it!

Left some small nits, but its only formatting and docs!

[tomflenner]

Another note for history : we did not spot issue in the first iteration of angular due to the way vitest is running test. I am not sure about that but it looks like he doesn't compile same way as a production code so no warning/errors on the hostDirectives mapping. Also due to limitation of test isolation we had to set the domain to separate InMemory provider on a test basis so we were not able to detect in test the microsyntaxe issues.