feat: add a feature flag for new field validation behavior

[vursen]

Description

This PR adds a feature flag for the new field validation behavior. The flag will be used by Flow field components. For more information about the new behavior, please refer to vaadin/platform#3066.

Part of vaadin/platform#3066

Type of change

• Feature

Checklist

• I have read the contribution guide: https://vaadin.com/docs/latest/guide/contributing/overview/
• I have added a description following the guideline.
• The issue is created in the corresponding repository and I have referenced it.
• I have added tests to ensure my change is effective and works as intended.
• New and existing tests are passing locally with my change.
• I have performed self-review and corrected misspellings.

[mshabarov]

Conflicts with master should be resolved.

By the way, where is this flag supposed to be checked? Does the Flow's Binder need to check it and behave accordingly?

[github-actions]

Unit Test Results

   916 files  +  9     916 suites  +9   51m 9s ⏱️ + 4m 19s
6 010 tests +11  5 956 ✔️ +11  54 💤 ±0  0 ❌ ±0 
6 228 runs  +  5  6 165 ✔️ +  5  63 💤 ±0  0 ❌ ±0 

Results for commit 54be8f1. ± Comparison against base commit 1bf5831.

♻️ This comment has been updated with latest results.

[vursen]

By the way, where is this flag supposed to be checked? Does the Flow's Binder need to check it and behave accordingly?

The flag is planned to be used only in Flow field components.

[vursen]

Here is an alternative naming for the flag suggested by @yuriy-fix: synchronizedValidation

[knoobie]

Another name could be (enforce) Field / Client Validation because it enables the field validation to run before the binder. I don't think a lot of people understand the concept of chaining and validation ordering.

[vursen]

@knoobie Good point, I agree that the current naming is rather not descriptive and that we need to find a better alternative.

Just want to point out that the field constraint validation has already been somewhat integrated into the binder validation through implementing getDefaultValidator and this is already available without feature flags, so the field validation is already enforced in a way. It is now more about enforcing client validation...

That being said, the above doesn't change things much and your suggested naming would still work, I think. I wonder how we should name the feature flag itself then: enforceClientFieldValidation? enforceClientValidation?

[knoobie]

and this is already available without feature flags, so the field validation is already enforced in a way.

Oh! I was expecting the whole epic (including the field changes) would be behind the feature flag and not just the client side. (Don't mind, was just unexpected)

enforceClientFieldValidation

I would think this describes it the best

[vursen]

As a result of an internal discussion, we came to the agreement that

• We will hide everything related to the new validation behavior behind a feature flag, including the recent getDefaultValidator changes
• We will name the feature flag enforceFieldValidation

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
10 Code Smells

No Coverage information
0.0% Duplication

[vaadin-bot]

This ticket/PR has been released with Vaadin 23.2.0.beta1 and is also targeting the upcoming stable 23.2.0 version.