App
App copied to clipboard
Expensify
[$1000] Web - Connect Bank Account - Inconsistent behaviour in the same page where adding spaces before the 'Tax Number' behaves differently unlike the behaviour shown by the company website field.
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:
- Go to staging dot on web chrome
- Go to any workspace > Connect bank account manually> Fill all the details
- Now in the company website field as well as in the tax number field , try to add multiple spaces before the text
- Click on back button and again go the same page
- See that the spaces have been removed from the company website's field but the spaces are not removed from the Tax number field.
Expected Result:
To maintain consistency between the fields, the spaces added before the tax number field should be removed
Actual Result:
In the same page , the spaces added before the company website field is removed , while the spaces added before the tax number field is not removed
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [ ] Android / native
- [ ] Android / Chrome
- [ ] iOS / native
- [ ] iOS / Safari
- [x] MacOS / Chrome / Safari
- [ ] MacOS / Desktop
Version Number: 1.3.2.3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/233436533-5c5a99e6-13d3-4f9b-b489-3763c6612c1f.mp4
https://user-images.githubusercontent.com/93399543/233436577-1e9bf9a4-ccbf-4f95-aeb9-f00bb587136c.mp4
Expensify/Expensify Issue URL:
Issue reported by: @avi-shek-jha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1681905290839009
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~01d5f5fca93a2703df
- Upwork Job ID: 1650538299630120960
- Last Price Increase: 2023-04-24
Triggered auto assignment to @bfitzexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Bug0 Triage Checklist (Main S/O)
- [x] This "bug" occurs on a supported platform (ensure
Platformsin OP are ✅) - [x] This bug is not a duplicate report (check E/App issues and #expensify-bugs)
- If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
- [x] This bug is reproducible using the reproduction steps in the OP. S/O
- If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
- If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
- [x] This issue is filled out as thoroughly and clearly as possible
- Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
- [x] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync
Sorry for opening this bug. It should be on hold as per this slack comment. Will reopen if it is needed.
@bfitzexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Current assignee @bfitzexpensify is eligible for the External assigner, not assigning anyone new.
Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (External)
Triggered auto assignment to @pecanoro (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.
We just have to trim the Tax Number input.
This can be solved as part of this PR. If everyone agrees, I can include this change there.
Please re-state the problem that we are trying to solve in this issue.
when user inputs the space in the textbox of Tax Number, app allows user to enter the spaces first.
What is the root cause of that problem?
TextBox has no already validations to add the space in the staring of any word.
What changes do you think we should make in order to solve the problem?
we should add a trim into the base component. it will reflect in every field that will not allow user to enter the space.
in src/components/TextInput/index.js
line no. 54 would look like
<TextInput {...props} value={props?.value?.trimStart()} innerRef={ref} />
it would not affect existing functionality, it will not allow user to add the space in the TextInput
What alternative solutions did you explore? (Optional)
we can user trim() function in the submit method of Form Component at line no 150. in src/pages/ReimbursementAccount/CompanyStep.js.
it will look companyTaxID: values.companyTaxID.replace(CONST.REGEX.NON_NUMERIC, '')?.trimStart(),
📣 @jaymangukiya0001! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork. Please follow these steps:
- Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
- Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
- Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>
Contributor details Your Expensify account email: [email protected] Upwork Profile Link: https://www.upwork.com/freelancers/~010b0577d6702d97a8
✅ Contributor details stored successfully. Thank you for contributing to Expensify!
Proposal
Please re-state the problem that we are trying to solve in this issue.
Connect bank account form has inconsistent trimming of fields
What is the root cause of that problem?
The root cause for the inconsistency is that for website field, we're setting type of the input as url. When this type is set, the value of the field is shown without the spaces. This can be confirmed in the following screenshot as well.
In reality, we are not trimming any of the field in the Company information form. It's just the native browser behaviour that is causing this inconsistency.
What changes do you think we should make in order to solve the problem?
We can trim all the fields in this form such that the behaviour is consistent across the form. This can be done by creating a utility function in this component that trims the content of all inputs.
trimValues(values) {
const trimmedStringValues = {};
_.each(values, (inputValue, inputID) => {
if (_.isString(inputValue)) {
(trimmedStringValues[inputID] = inputValue.trim());
} else {
trimmedStringValues[inputID] = inputValue;
}
});
return trimmedStringValues;
}
We can use this function when initialising the state here.
...this.trimValues(props.draftValues),
This will just display the values as trimmed instead of actually saving the values as trimmed.
We can also expose the above functionality via a form prop / or field prop so that this behaviour happens on some forms / fields only.
What alternative solutions did you explore? (Optional)
We can make the form such that it saves the trimmed values as well. Instead of above, we can add the following here:
FormActions.setDraftValues(this.props.formID, {[inputKey]: typeof value === 'string' ? value.trim() : value});
If we don't want to trim any of the fields, then we can change the input type of the website field to text. This will cause the whitespaces to show up in the field making it consistent with others.
If we don't want to trim any of the fields, then we can change the input type of the website field to text. This will cause the whitespaces to show up in the field making it consistent with others.
I think this is the best thing to do as per our design doc on Form(unchanged user input).
@allroundexperts What does the virtual keyboard look like on mweb and native if change the type form url to text?
@parasharrajat Uploaded the pics on mobile web and native.
Without URL type
With URL type
Without URL type
With URL type
Without URL type
With URL type
With URL type
Without URL type
@jaymangukiya0001 Your proposal is against our design philosophy. https://github.com/Expensify/App/blob/main/contributingGuides/FORMS.md#modifying-user-input-on-change
@pecanoro What do you think will be best to do here?
There are two ways to solve this.
- Trim the content before we save the draft in the Form state.
- change the type of input so that it does not trim the starting spaces.
1 goes against our Form policy of unrestricted user input and 2 takes way advantage of the custom system keyboard for the URLs.
After testing this, I think we should trim all values, I don't see any purpose of leaving them untrimmed unless we are either using the composer or any other component that would make more sense, like a textarea type of component.
Got it. Now the question is when should we trim these values? Trimming the values while the user is typing is bad which we are trying to get away from all our the App.
Yeah, let's trim the values after either moving forward or moving back and saving them as drafts, there is no need to trim them while typing.
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
I am still figuring this out.
Let's trim the values after either moving forward or moving back and saving them as drafts,
That will not always solve the problem. For example, the user can close the page but drafts are still saved.
That will not always solve the problem. For example, the user can close the page but drafts are still saved.
Whenever we save the drafts 🤷♀️ Or wouldn't that be doable?
@pecanoro @parasharrajat @bfitzexpensify this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!