Skip to content

feat(control-error): accept control name#663

Merged
eneajaho merged 4 commits intongxtension:mainfrom
Dafnik:feat/ngx-control-error-form-control-name
Feb 26, 2026
Merged

feat(control-error): accept control name#663
eneajaho merged 4 commits intongxtension:mainfrom
Dafnik:feat/ngx-control-error-form-control-name

Conversation

@Dafnik
Copy link
Contributor

@Dafnik Dafnik commented Feb 17, 2026

Rebased on current main.

Fixes #267

Commits from: #588

@gemini-code-assist
Copy link

Summary of Changes

Hello @Dafnik, I'm Gemini Code Assist1! 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 significantly improves the ngxControlError directive by allowing developers to reference form controls using their string names when working with FormGroups. This enhancement streamlines the process of displaying validation errors in templates, making the directive more intuitive and less verbose. It also includes comprehensive error handling to guide developers when control names are incorrectly specified, ensuring a more robust and user-friendly experience.

Highlights

  • Enhanced ngxControlError Directive: The *ngxControlError directive now accepts a control name (string) as input, in addition to an AbstractControl instance, simplifying its usage within FormGroup contexts.
  • Robust Error Handling: New error checks were introduced to gracefully handle scenarios where a control name is provided without a parent FormGroup or if the specified control name cannot be found within the form hierarchy.
  • Updated Documentation and Examples: Both English and Spanish documentation, along with the test application, have been updated to demonstrate and reflect the new string-based control name usage.
  • Internal Code Improvements: Signal getters within NgxControlError were wrapped with untracked to optimize performance by preventing unnecessary re-evaluations, and ControlContainer was injected to facilitate control name resolution.
Changelog
  • apps/test-app/src/app/control-error/control-error.component.ts
    • Updated the example to use formControlName and pass the control name as a string to *ngxControlError.
  • docs/src/content/docs/es/utilities/Forms/control-error.md
    • Added a new section in Spanish documenting how to use *ngxControlError with a control name (string) within a FormGroup.
  • docs/src/content/docs/utilities/Forms/control-error.md
    • Added a new section in English documenting how to use *ngxControlError with a control name (string) within a FormGroup.
  • libs/ngxtension/control-error/src/control-error.spec.ts
    • Imported FormGroup and ReactiveFormsModule for testing form group functionality.
    • Renamed unitTest to isolatedTest for improved clarity in test descriptions.
    • Added ReactiveFormsModule to the render helper's imports to support reactive forms in tests.
    • Implemented new test cases to verify ngxControlError correctly resolves controls by name, including nested controls.
    • Added tests to confirm proper error throwing when a control name is not found or no parent FormGroup exists.
    • Updated existing tests to utilize the isolatedTest helper and ReactiveFormsModule where applicable.
  • libs/ngxtension/control-error/src/control-error.ts
    • Imported untracked from @angular/core and ControlContainer from @angular/forms.
    • Injected ControlContainer to gain access to the direct parent form group directive for control resolution.
    • Modified the control input setter to controlInput and implemented logic to resolve a control by its string name if an AbstractControl instance is not directly provided.
    • Added explicit error messages for scenarios where a control name is used without a parent FormGroup or if the named control cannot be found.
    • Wrapped signal getters (track$, control$, errorStateMatcher$, parent$) with untracked to prevent unnecessary change detection cycles.
    • Updated JSDoc comments for the control and parent properties to reflect the new functionality and clarify their roles.
Activity
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.

@nx-cloud
Copy link

nx-cloud bot commented Feb 17, 2026

View your CI Pipeline Execution ↗ for commit 9b0fed3

Command Status Duration Result
nx affected --target=build --parallel=3 --exclu... ✅ Succeeded 11s View ↗
nx affected --target=test --parallel=3 --exclud... ✅ Succeeded 2s View ↗
nx affected --target=lint --parallel=3 ✅ Succeeded 38s View ↗
nx-cloud record -- nx format:check ✅ Succeeded 2s View ↗

☁️ Nx Cloud last updated this comment at 2026-02-26 20:51:57 UTC

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a useful feature to ngxControlError, allowing it to accept a control name as a string in addition to an AbstractControl instance. The implementation is solid, with comprehensive tests covering various scenarios, including error handling. The documentation has also been updated accordingly. I have one suggestion to improve the clarity of the directive's API, which I've detailed in a review comment.

@Dafnik Dafnik changed the title feat(control-error): accept control name feat(control-error): accept control name REBASE Feb 17, 2026
@Dafnik
Copy link
Contributor Author

Dafnik commented Feb 24, 2026

Ping @eneajaho

@eneajaho eneajaho changed the title feat(control-error): accept control name REBASE feat(control-error): accept control name Feb 26, 2026
@eneajaho eneajaho force-pushed the feat/ngx-control-error-form-control-name branch from ed6a25e to 9b0fed3 Compare February 26, 2026 20:50
@eneajaho eneajaho merged commit 099eea2 into ngxtension:main Feb 26, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow NgxControlError accept control name instead of instance

2 participants