adjust NgxCVA to be usable with field directive and new signal-based forms - #679
adjust NgxCVA to be usable with field directive and new signal-based forms#679ptandler wants to merge 5 commits into
Conversation
This reverts commit 88e9f2e.
Summary of ChangesHello, 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 enhances the Highlights
Using Gemini Code AssistThe 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
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 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. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request addresses an Angular NG0203 injection context bug within the NgxControlValueAccessor by refactoring value$ and disabled$ to use linkedSignal with untracked for initialization, and capturing default values during construction. New regression tests have been added to verify the fix. The review comments suggest improving the clarity of JSDoc comments regarding the use of untracked and removing a trailing whitespace character.
| /** | ||
| * We need to use untracked here to avoid that the linkedSignal | ||
| * is initialized again. | ||
| * @ignore | ||
| */ |
There was a problem hiding this comment.
The comment here is misleading. untracked does not prevent linkedSignal from being re-initialized; it prevents dependency tracking on signals read within its scope. This clarification is important for future maintainability. Let's update the comment to accurately reflect what untracked does in this context.
/**
* We use `untracked` to prevent `linkedSignal` from creating a dependency
* on any signals that might be read here. This ensures the source function
* is for initialization only and doesn't re-run unexpectedly.
* @ignore
*/| /** | ||
| * We need to use untracked here to avoid that the linkedSignal | ||
| * is initialized again. | ||
| * @ignore | ||
| */ |
There was a problem hiding this comment.
Similar to a previous comment, this explanation for using untracked is misleading. It's important for code clarity and maintainability that comments accurately describe the behavior. Let's update this one as well to correctly state that untracked is used to prevent dependency tracking.
/**
* We use `untracked` to prevent `linkedSignal` from creating a dependency
* on any signals that might be read here. This ensures the source function
* is for initialization only and doesn't re-run unexpectedly.
* @ignore
*/| * Whether this is disabled. If a control is present, it reflects it's disabled state. | ||
| * | ||
| * @remarks Internally, this uses a `linkedSignal` to delay the initialization until | ||
| * the host component's inputs are set to avoid runtime exceptions. */ |
There was a problem hiding this comment.
|
Hi @ptandler |
Fixes #654 see there for details