Angular Template Type Checking with Custom Validators

This challenge focuses on implementing robust type checking for data within an Angular component's template using custom validation logic. This is crucial for building user-friendly forms and ensuring data integrity before it's submitted or used in complex UI interactions.

Problem Description

Your task is to create an Angular component that displays a form with several input fields. These fields need to be validated not only by Angular's built-in validators but also by custom validation rules that enforce specific data types and formats. The component should visually indicate to the user whether an input is valid, invalid, or has not yet been touched.

Key Requirements:

• Create an Angular component with at least three input fields:
  • An email address input.
  • A numeric input (must be a positive integer).
  • A date input (must be a valid date string in YYYY-MM-DD format).
• Implement custom validators for each input field:
  • Email: Validate that the input string strictly matches a standard email pattern (e.g., user@domain.com).
  • Numeric: Validate that the input is a positive integer.
  • Date: Validate that the input string can be parsed into a valid Date object and adheres to the YYYY-MM-DD format.
• Use Angular's ReactiveForms module for form management.
• Display clear visual feedback to the user:
  • A "valid" indicator (e.g., green border/icon) when the input is valid and has been touched.
  • An "invalid" indicator (e.g., red border/icon) when the input is invalid and has been touched.
  • No specific indicator (or a neutral one) when the input has not been touched.
• Conditionally display error messages when an input is invalid and has been touched.

Expected Behavior:

• As the user types, the validation status should update in real-time.
• When a field is valid, it should look "good."
• When a field is invalid, it should be clearly highlighted as such, and a specific error message should be shown.
• The form should only be considered "valid" when all fields pass their respective custom and built-in validations.

Edge Cases to Consider:

• Empty inputs (should be handled by built-in Validators.required if applicable, or by custom logic).
• Inputs that are partially typed but not yet fully valid (e.g., an incomplete email address).
• Invalid date formats (e.g., "2023-13-01" or "2023-01-32").
• Non-numeric input for the numeric field.
• Negative numbers or zero for the numeric field.

Examples

Example 1: Valid Input

Input:
User types "test@example.com" into the email field, "123" into the numeric field, and "2023-10-27" into the date field. All fields are marked as touched.

Output:
- Email input: Styled as valid (e.g., green border). No error message.
- Numeric input: Styled as valid (e.g., green border). No error message.
- Date input: Styled as valid (e.g., green border). No error message.

Explanation: All inputs meet their respective custom validation criteria and have been touched, so they are displayed as valid.

Example 2: Invalid Input

Input:
User types "invalid-email" into the email field, "abc" into the numeric field, and "2023-02-30" into the date field. All fields are marked as touched.

Output:
- Email input: Styled as invalid (e.g., red border). Error message: "Please enter a valid email address."
- Numeric input: Styled as invalid (e.g., red border). Error message: "Please enter a positive integer."
- Date input: Styled as invalid (e.g., red border). Error message: "Please enter a date in YYYY-MM-DD format."

Explanation: Each input fails its custom validation, and the corresponding error messages are displayed.

Example 3: Untouched Input

Input:
The form loads, and no fields have been interacted with yet.

Output:
- Email input: No specific styling indicating validity or invalidity.
- Numeric input: No specific styling indicating validity or invalidity.
- Date input: No specific styling indicating validity or invalidity.

Explanation: Until a user interacts with an input and it becomes "touched," no validation status styling is applied.

Constraints

• Angular version: v16 or later.
• TypeScript version: 5.0 or later.
• All custom validators must be implemented as standalone functions or class methods.
• The solution should be implemented using Angular's Reactive Forms.
• The styling for valid/invalid states should be achieved using CSS classes applied by the component.
• The solution should be reasonably performant for real-time validation.

Notes

• You will need to import ReactiveFormsModule into your Angular module.
• Consider using Angular's built-in Validators.required in conjunction with your custom validators.
• For the date validation, you'll need to parse the input string into a Date object and then reformat it to check for consistency. Be mindful of how JavaScript Date objects handle invalid inputs.
• The email validation pattern can be a standard regex; you don't need to cover every single RFC-compliant edge case, but it should be robust enough for common formats.
• Think about how to trigger the "touched" state in your form.