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

Bug - custom validation (validateEmail) overwritten by initialEmailAddress function. #170

Open
Elnatanv opened this issue Feb 11, 2024 · 0 comments

Comments

@Elnatanv
Copy link
Contributor

Elnatanv commented Feb 11, 2024

Description

The issue arises when utilizing the validateEmail prop with a custom validation in react-multi-email. The library returns the email only if it passes its internal validation, thereby overwriting the custom validation. This occurs within the initialEmailAddress function, which executes within a useEffect with the emails array as a dependency. Consequently, each time a user adds emails, the function fires and overrides the custom validation. The culprit is in the filter function applied to the emails array, which forces validation via isEmailFn, thus disregarding the custom validation.

const initialEmailAddress = (emails?: string[]) => {
  if (typeof emails === 'undefined') return [];

  const validEmails = emails.filter(email => isEmailFn(email));
  return validEmails;
};

Fix suggestion

Move initialEmailAddress function inside the component. right under the useStates.
And change the function to look like this:

const initialEmailAddress = (emails?: string[]) => {
  if (typeof emails === 'undefined') return [];

  const validEmails = emails.filter(email => validateEmail ? validateEmail(email) : isEmailFn(email));
  return validEmails;
};

Steps to Reproduce

  1. Add the validateEmail prop with a custom validation.
  2. Input an email that passes the custom validation but fails the library's isEmail validation.
  3. Observe that the component removes the email instead of adding it.

Expected Behavior

The component should respect the user's intention to employ a custom validation.

Actual Behavior

The component fails to respect the custom validation and instead prioritizes the library's isEmail validation.

Additional Notes

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

No branches or pull requests

1 participant