Birth date selector - Adding a really old date (>150 years) gives incorrect error

[isagoico]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Navigate to https://staging.new.expensify.com/bank-account/personal-information
2. On the birth date selector select a date over 150 years old
3. Click on save and continue

Expected Result:

There should be an error mentioning the user to enter a valid date.

Actual Result:

There's an error mentioning the user is not over 18 years old (lol wat)

Workaround:

N/A visual issue (error not shown)

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number: 1.1.5-0

Reproducible in staging?: yes
Reproducible in production?: No

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:

Issue reported by: Applause
Slack conversation:

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @AndrewGable (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[OSBotify]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[parasharrajat]

Code has a check for 150 years range. But that error will not make sense ☺️ in both cases when age is:

1. greater than 150.
2. less than 18.

cc. @flodnv

[aldo-expensify]

We don't have a special error message for over 150 years. Currently we have kind of a workaround that doesn't scale well to handle having multiple errors for a single field, like 'Date of birth'.

To do this, using the "workaround" we would have to:

• Add a new error key for 'dob' here

  App/src/libs/ValidationUtils.js

  Lines 193 to 197 in 2330bb9

  	if (!isValidDate(identity.dob)) {
  	errors.dob = true;
  	} else if (!meetsAgeRequirements(identity.dob)) {
  	errors.dobAge = true;
  	}

• Add support for it in:
  

  App/src/pages/ReimbursementAccount/RequestorStep.js

  Lines 102 to 104 in 2330bb9

  	if (inputKey === 'dob') {
  	this.clearError('dobAge');
  	}

  
  

  App/src/pages/ReimbursementAccount/BeneficialOwnersStep.js

  Lines 143 to 146 in 2330bb9

  	// dob field has multiple validations/errors, we are handling it temporarily like this.
  	if (inputKey === 'dob') {
  	this.clearError(`beneficialOwnersErrors.${ownerIndex}.dobAge`);
  	}

  
  

  App/src/pages/ReimbursementAccount/IdentityForm.js

  Lines 76 to 78 in 2330bb9

  	// dob field has multiple validations/errors, we are handling it temporarily like this.
  	const dobErrorText = (errors.dob ? translate('bankAccount.error.dob') : '')
  	|| (errors.dobAge ? translate('bankAccount.error.age') : '');

Do we want add this new error for ages above 150 using this workaround? or do nothing until we design this better because the error is not very important?

[parasharrajat]

@aldo-expensify I would suggest limiting the calendar on the input to 150 years and showing the error only when age is less than 18.

[roryabraham]

This is an extreme edge case so I'm removing it as a deploy blocker.

[kidroca]

When I worked on the datepicker I noticed that form validation is applied separately in a "boilerplate fashion" where each form would handle it on it's own
It's a bit of a maintenance having to cover everything like that (like multiple errors per field)
Usually a validator is associated with a form and it would return a mapping of { field_name -> error_message }
How the validator actually works varies, but the key points are that it's called with the current form fields values (form state) and returns the error mapping.
Often no validation would be applied until the submit button is pressed, then if any errors are discovered validation runs on field change to remove fixed issues
Different libraries apply the full concept handling the entire form interaction (on focus, on submit, error visibility e.g. Formik) and hook directly with validators like yup (or custom ones if we have any). This works in react-native as well. Other libraries (like yup) provide just solutions regarding writing validation boilerplate encapsulating logic into a schema.

I think, if we have or we're going to have more forms, we should extract validation even if we don't use an external library and code it ourselves

[flodnv]

Indeed, @aldo-expensify changed my more generic error message to a more specific one (see here). I do agree that more specific error messages are better, and I do agree that this one is an extreme edge case (worth considering nonetheless).

I would suggest limiting the calendar on the input to 150 years

That wouldn't work in the case of manual (desktop keyboard) input, would it?

@kidroca -- @marcaaron is currently working on a plan to revamp our form error messages. @marcaaron what would you recommend our approach should be with regards to this edge case?

[marcaaron]

I think it might be fine to just do nothing in this case as 150 years is well above the average life expectancy for human beings and no one has ever lived that long as far as we know.

Honestly though, I think if we are doing this so that there's a useful message when the user is inputting an unintentionally large date that is very wrong we should always give them a message that makes sense.

Two ideas...

• tell them "Date of birth must be between 18-150 years"
• split into two separate messages if we feel that the more common case will be "Must be over 18"

Limiting the range of the calendar seems like a good idea, but not sure we should replace the messaging with that for the reason @flodnv is bringing up.

[mvtglobally]

Issue reproducible during KI retests.

[MelvinBot]

@AndrewGable Eep! 4 days overdue now. Issues have feelings too...

[mvtglobally]

Issue reproducible during KI retests.

[mvtglobally]

Issue reproducible during KI retests.

[mvtglobally]

Issue reproducible during KI retests

[AndrewGable]

I think it might be fine to just do nothing in this case

I agree, low priority. Let's close and reopen when we've fixed all the other bugs more important than this one.