Skip to content

IBX-10471: [Inputs] Inputs Validators Base #14

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

GrabowskiM
Copy link
Contributor

🎫 Issue IBX-10471

Description:

For QA:

Documentation:

@GrabowskiM GrabowskiM requested a review from Copilot August 7, 2025 14:32
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR introduces a validation system for input components with a base validator architecture. It establishes the foundation for validating user inputs with support for internationalization through translators.

  • Implements a BaseValidator abstract class that serves as the foundation for all validators
  • Creates a ValidatorManager to orchestrate multiple validators and collect validation results
  • Provides a React hook for easy integration of the validation system in components
  • Includes an example IsEmptyStringValidator for string validation

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File Description
BaseValidator.ts Abstract base class defining the validator interface with translator support
ValidatorManager.ts Manager class that handles multiple validators and aggregates validation results
IsEmptyStringValidator.ts Concrete validator implementation for checking empty strings
useValidatorManager.ts React hook for creating and managing validator instances

export default abstract class BaseValidator {
protected _translator!: TranslatorType;

setTranslator(translator: TranslatorType) {
Copy link
Preview

Copilot AI Aug 7, 2025

Choose a reason for hiding this comment

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

Using the definite assignment assertion (!) on _translator without initialization could lead to runtime errors if setTranslator() is not called before accessing the translator. Consider making the translator a required constructor parameter or providing a default value.

Suggested change
setTranslator(translator: TranslatorType) {
protected _translator: TranslatorType;
constructor(translator: TranslatorType) {

Copilot uses AI. Check for mistakes.

this._validators = this._validators.filter((savedValidator) => savedValidator !== validator);
}

validate(value: unknown) {
Copy link
Preview

Copilot AI Aug 7, 2025

Choose a reason for hiding this comment

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

The validate method lacks a return type annotation. Adding ': { isValid: boolean; messages: string[] }' would improve type safety and API clarity.

Suggested change
validate(value: unknown) {
validate(value: unknown): { isValid: boolean; messages: string[] } {

Copilot uses AI. Check for mistakes.

@GrabowskiM GrabowskiM requested a review from a team August 7, 2025 14:37
@ezrobot ezrobot requested review from tischsoic, dew326, OstafinL, RopRaptor and albozek and removed request for a team August 7, 2025 14:37
@@ -0,0 +1,14 @@
import BaseValidator from '../../validators/BaseValidator';

export interface ValidateReturnType {

Choose a reason for hiding this comment

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

I think we should avoid naming return types as ...ReturnType because this decreases flexibility. E.g. it may feel strange later to create something like:

const alwaysTrueValidation: ValidateReturnType = {...}

I think we should name it e.g. ValidationResult:

Suggested change
export interface ValidateReturnType {
export interface ValidationResult {

Comment on lines +10 to +11
.filter((validator: BaseValidator<T>) => !validator.validate(value))
.map((validator: BaseValidator<T>) => validator.getErrorMessage());

Choose a reason for hiding this comment

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

I guess this is somewhat fine, but it feels wrong to call filter first and then map to collect error messages :D

Suggested change
.filter((validator: BaseValidator<T>) => !validator.validate(value))
.map((validator: BaseValidator<T>) => validator.getErrorMessage());
.reduce((errors , validator) => {
const isValid = validator.validate(value);
if (isValid) {
continue;
}
return [...errors, validator.getErrorMessage()];
}, [])

this is longer but faster to read. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants