Skip to content
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

Form-Level Validation Rule #121

Open
eraps7 opened this issue Mar 7, 2024 · 3 comments
Open

Form-Level Validation Rule #121

eraps7 opened this issue Mar 7, 2024 · 3 comments
Labels
feature A new feature or request p3 Issues that we currently consider unimportant

Comments

@eraps7
Copy link

eraps7 commented Mar 7, 2024

Is your feature request related to a problem? Please describe.
Currently, the formz package excels at validating individual form fields and separating the validation logic. However, it lacks the ability to define a validation rule that applies to the entire form.

For instance, consider a use case where the user can look up a an employee by any 3 fields: phone number, first name, and last name. While formz allows validation for individual fields (e.g., ensuring phone number has 10 digits and names have at least two characters), there's no way to enforce that at least one field must be filled before submitting the search.

Describe the solution you'd like
One possible solution would involve introducing a mechanism to define form-level validation rules that can orchestrate the execution of individual field validators. In the example above, the form level validator would perform validation that least one of the three fields (phone number, first name, or last name) has a value before allowing form submission then to orchestrate the execution of individual field validators.

\\Something like
\\Form - Level validator
overide
ValidationError? validator(String value) {
  if (isAllSearchParametersEmpty(firstName: firstName, lastName: lastName, phone: phone)) {
    return AtLeastOneFieldNeededError();
  }
  //This idea
  // Directly call field validators here
  final phoneError = phone.validator();
  final firstNameError = firstName.validator();
  final lastNameError = lastName.validator();

  // Combine errors for a holistic form-level validation result
  return ... (logic to aggregate errors and return a representative error)
}
tiny code
/// ValidationError is an abstract class that is used to implement the builder pattern to create a validation error(s).
abstract class ValidationError {
  final String message;

  ValidationError(this.message);
}

I am happy create a pull request and discuss peoples thoughts on the best way to implement this

@codakkk
Copy link

codakkk commented Oct 13, 2024

Up

@tomarra
Copy link
Contributor

tomarra commented Oct 15, 2024

Hi @eraps7 & @codakkk 👋 Thanks for opening this issue!

Overall it seems like what you're proposing here is actually doable with the formz as it exists today. Can we get a summary of the proposed implementation that you would be expecting? That way we can talk through a potential change before anyone invests time in writing code.

I'm going to label this as a P3 given that we don't have any use case driving this need but if either of you would like to help with an implementation and contribute it back I can find cycles from the VGV team to help review.

@tomarra tomarra added feature A new feature or request p3 Issues that we currently consider unimportant labels Oct 15, 2024
@codakkk
Copy link

codakkk commented Oct 22, 2024

Hi @eraps7 & @codakkk 👋 Thanks for opening this issue!

Overall it seems like what you're proposing here is actually doable with the formz as it exists today. Can we get a summary of the proposed implementation that you would be expecting? That way we can talk through a potential change before anyone invests time in writing code.

I'm going to label this as a P3 given that we don't have any use case driving this need but if either of you would like to help with an implementation and contribute it back I can find cycles from the VGV team to help review.

Well taking the following as example:

part 'exercise_form.freezed.dart';

@freezed
class ExerciseForm with _$ExerciseForm, FormzMixin {
  const ExerciseForm._();

  const factory ExerciseForm({
    @Default(ExerciseInput.pure()) ExerciseInput exercise,
    @Default(SetListInput.pure()) SetListInput sets,
    @Default(ExerciseNoteInput.pure()) ExerciseNoteInput note,
  }) = _ExerciseForm;

  @override
  List<FormzInput<dynamic, dynamic>> get inputs => [
        exercise,
        sets,
        note,
      ];
}

@freezed
class SetForm with _$SetForm, FormzMixin {
  const SetForm._();

  const factory SetForm({
    @Default(RepTypeInput.pure()) RepTypeInput type,
    @Default(RepValueInput.pure()) RepValueInput value,
    @Default(false) bool isAMAP, // As Many As Possible
    @Default('') String note,
  }) = _RepsForm;

  @override
  List<FormzInput<dynamic, dynamic>> get inputs => [
        type,
        value,
      ];
}

enum SetFormListInputError {
  empty,
}

class SetFormListInput
    extends FormzInput<List<SetForm>, SetFormListInputError> {
  const SetFormListInput.pure([super.value = const []]) : super.pure();

  const SetFormListInput.dirty(super.value) : super.dirty();

  @override
  SetFormListInputError? validator(List<SetForm> value) {
    return value.isEmpty ? SetFormListInputError.empty : null;
  }
}

I have a SetForm which describes a form for a single set in an exercise. Then I have a ExerciseForm which contains a SetFormListInput. The latter just checks whether the SetFormListInput's List<SetForm> is not empty. However, an ExerciseForm is valid only if ExerciseInput, SetListInput, ExerciseNoteInput are valid, thus adding them to the inputs get in ExerciseForm. To ensure accuracy, the SetFormListInput items should also be validated.. Is the following approach correct? Is the SetFormListInput a valid FormzInput?

  @override
  List<FormzInput<dynamic, dynamic>> get inputs => [
        exercise,
        sets,
        for (final input in sets.value) ...input.inputs,
        note,
      ];

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new feature or request p3 Issues that we currently consider unimportant
Projects
Status: Needs Triage
Development

No branches or pull requests

3 participants