Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat(search): Debounce and phone number validation #3124
feat(search): Debounce and phone number validation #3124
Changes from all commits
74f0c59
f1ee5ff
f9f000a
3effa64
cf25b91
2000719
8a8b1cf
4c41ecc
39581a4
429d9aa
cfb09ce
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we're going to have to move this into
OptionsListUtils
since the validation you're adding is going to apply to all pages that have account-search functionality. Can you figure out how we can reusegetSearchOptions
here (by editinggetOptions
)? I'm thinking we can havegetOptions
also returnheaderMessage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discussed this with you earlier. That my initial approach was to add the changes in
getOptions
only but it's not flexible enough and might require good amount of refactoring.Because there are a lot of things happening internally and the code is a bit messy and adding more code will increase the complexity and maintainability efforts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woah you did? I'm sorry I don't remember you bringing up that approach, maybe I misunderstood :O
Hmm I don't see why we can't refactor
getHeaderMessage
just a bit, and makegetOptions
also return something likeheaderMessage: getMeaderMessage(...)
. Here's why I'm thinking this will work (please let me know if you disagree on these points):getHeaderMessage
takes only a few parameters, and all of the params should be able to be calculated from other variables insidegetOptions
getOptions
is only used inOptionsListUtils
, which hasget...Options
functions for specific pages, all of those pages will need this type of functionality (the same type of logic forheaderMessage
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @Beamanator
I tried merging these changes into utils. So
getSearchOptions
&getHeaderMessage
are independent of each other. They both take thesearchValue
as one of the input. With this, we might end up hitting the phone number validation API twice.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm once you push your latest changes I can check and see if I can help come up with a way to only hit that validation API once 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this function, it looks like the only time we're using this
headerMessage
is if the the phone number is invalid, so I think it would be better if we just doheaderMessage: translate(preferredLocale, 'messages.noPhoneNumber')
directly in theelse
statement below - since this will only be displayed if themodifiedSearchValue
is an invalid phone number - we shouldn't need to callgetHeaderMessage
right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am keeping the call to
getHeaderMessage
because if we want to make any change in the underlying messaging part then we have only one place to change. Or a single source of truth.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, let's do something like
headerMessage: translate(preferredLocale, 'messages.noPhoneNumber')
hereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could be cleaner to just make this
else
anelse if (Str.isValidEmail(searchValue) && !Str.isDomainEmail(searchValue))
, whereheaderMessage
should always be''
, then add anelse
which displays thethis.props.translate('messages.noEmailOrPhone')
error message, what do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This validation is not required as it is done internally by
getSearchOptions