-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
[HOLD for payment 2023-04-07] [$4000] Inconsistent behaviour for Manage Member's search & Invite member's search #15661
Comments
Triggered auto assignment to @anmurali ( |
Bug0 Triage Checklist (Main S/O)
|
@anmurali Whoops! This issue is 2 days overdue. Let's get this updated quick! |
Job added to Upwork: https://www.upwork.com/jobs/~011d403a6a3312983b |
Current assignee @anmurali is eligible for the External assigner, not assigning anyone new. |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @sobitneupane ( |
Triggered auto assignment to @iwiznia ( |
This is where the issue was previously discussed |
It is not really inconsistent behaviour. If you go back from the 'manage members' page, the search text will get cleared. |
ProposalPlease re-state the problem that we are trying to solve in this issue.The issue at hand pertains to inconsistent behavior observed in Manage Member's search and Invite Member's search, where the inputs are sometimes empty, and sometimes carry over their previous value. This inconsistency needs to be resolved. What is the root cause of that problem?The root cause of this issue is related to memory management in React. While this behavior is not necessarily problematic, it is expected that a visited page will be stored for easy access when a user revisits it. In this case, when a user inputs text in the text input, the current page (i.e., members page) and all its values are stored. When the user navigates to the next page (i.e., invite members), the browser mounts the invite members page with all its components. When the user navigates back from invite to members, the browser uses the saved copy of the page. What changes do you think we should make in order to solve the problem?To ensure consistency and resolve the issue, it is suggested to clear the data ( input value) in the Manage Member's search in the componentWillUnmount(). This solution is chosen because users expect that no data will be saved in a search bar when they leave a page. App/src/pages/workspace/WorkspaceMembersPage.js Lines 380 to 384 in 7e8e8a1
|
ProposalPlease re-state the problem that we are trying to solve in this issue.The current issue is that when a user navigates back from the What is the root cause of that problem?The cause of this issue is that the current component What changes do you think we should make in order to solve the problem?To address the root cause of the problem, we can temporarily save the search term state in the local storage. Here's what we can do:
Screen.Recording.2023-03-08.at.2.04.14.PM.movWhat alternative solutions did you explore? (Optional)No alternative solutions were explored. |
@sobitneupane - thoughts on these proposals? |
ProposalPlease re-state the problem that we are trying to solve in this issue.Inconsistent behaviour for Manage Member's search & Invite member's search What is the root cause of that problem?When we move into the Invite Page, the Member Page is still mounted so the search value remains. But when back from the invite Page, the invite Page is unmounted immediately so the search value in the invite page doesn't remain What changes do you think we should make in order to solve the problem?We should clear the input value when clicking the Invite Button
ResultScreen.Recording.2023-03-13.at.15.07.55.movWhat alternative solutions did you explore? (Optional)We also could save the search value in the invite page, and the member page,... as a draft value (and save it in ONYX storage) like how we save the draft value in the composer EDIT: This is more detail for this solution
Then in /App/src/pages/workspace/WorkspaceInvitePage.js whenever we update the searchValue we also update the draft value in the ONYX by the above function (consider using debound for this function). Also, we will get the draft value in the invite page
and update the draftSearchValue in the constructor if the
We also could update the draftSearchValue in ComponentDidMount ResultScreen-Recording-2023-03-14-at-09.25.02.mp4This is my draft implementation on the invite page, We could do the same on other pages like the manage member Page,... |
Why would we want to remove the search value after navigating forward? The expected behavior only mentioned "Behavior should be consistent for all sections" but does not tell which behavior. Looking at the last step, they expect the search value at invite members page is saved. Saving/clearing the search value seems like a feature request to me which should be discussed whether it is required because it affects the UX of the app. Edit: why I think it is a feature request. |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.2.92-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-04-07. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
|
@iwiznia, @anmurali, @sobitneupane, @situchan Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
1 similar comment
@iwiznia, @anmurali, @sobitneupane, @situchan Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
@sobitneupane - can you take care of your checklist items? |
https://expensify.slack.com/archives/C049HHMV9SM/p1681186634307459 |
Regression Test Proposal
Do we agree 👍 or 👎 |
@iwiznia, @anmurali, @sobitneupane, @situchan Uh oh! This issue is overdue by 2 days. Don't forget to update your issues! |
@sobitneupane agree with that regression test (I now realize I should've commented and not reacted to your comment). Can you take care of creating that new regression test? @anmurali I think you need to pay here? |
Did we pay this already? If so, can we close this? |
Sent contracts to them all, will pay and close this once they accept them |
@anmurali Thanks. Accepted the offer. |
@anmurali accepted, thanks! |
Everyone's paid |
Not sure if timeline bonus is applicable here. Based on https://ex-syt.glitch.me/?issue=15813&pr=16603: Here's the Issue timeline analysis: 💰 Timeline Bonus/Penalty: 50% Bonus! 🎉 |
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Action Performed:
Expected Result:
Behavior should be consistent for all sections
Actual Result:
Different behavior is being observed
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: 1.2.78-0
Reproducible in staging?: y
Reproducible in production?: y
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:
manage-vs-invite.mp4
Recording.1627.mp4
Expensify/Expensify Issue URL:
Issue reported by: @daraksha-dk
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1677844622336169
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: