You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[HOLD for payment 2023-12-06] [$500] Web - Profile - When selecting the last country or state extra space is displayed for a while #31660
Version Number: 1.4.1-7 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 Expensify/Expensify Issue URL: Issue reported by: Applause - Internal Team Slack conversation:
Action Performed:
Go to Settings > Profile > Personal details > Address.
Click on the country and select "Zimbabwe."
Click on the country again and notice space below.
Now, select "United States" and choose the last state.
Click on the state again and notice extra space for a while
Expected Result:
When selecting the last country or state, extra space should not be displayed below the country list or state
Actual Result:
When selecting the last country or state, extra space is displayed for a while below the list
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
changed the title [-]Web - Profile - When selecting the last country or state extra space is displayed for a while[/-][+][$500] Web - Profile - When selecting the last country or state extra space is displayed for a while[/+]on Nov 21, 2023
And since we select the last element
The list needs time to display the last elements
This is why we see bugs like this.
What changes do you think we should make in order to solve the problem?
To fix this bug we can increase this property from 5 to 15(for example) to Increase the list display speed
Also, we have initialNumToRender and windowSize. We can also use these properties for optimization.
As an alternative, we can pass these values like props from CountrySelectionPage, StateSelectorModal, and other screens
What alternative solutions did you explore? (Optional)
We can also make separate configs for different numbers of elements
And if the lists have more than 100 elements for example
We will increase the values (initialNumToRender, windowSize, maxToRenderPerBatch) to display elements better
Because the current values we use for long lists are not very suitable
Or at least we can use dynamic values that we will calculate depending on the number of visible elements using onLayout from SectionList. But I'm not sure this approach will work for all lists. so if we decide to use dynamic maxToRenderPerBatch, then it is better to create a new prop that will enable and disable dynamic maxToRenderPerBatch
We can update scrollToFocusedIndexOnFirstRender like
const [maxToRenderPerBatch, setMaxToRenderPerBatch] = useState(5);
const scrollToFocusedIndexOnFirstRender = useCallback(
(layout) => {
if(isDynamicMaxToRenderPerBatch) {
// I added 5(or we can multiply by 2) because the scrolling speed is higher than updating elements as tall as a list.
But this is more of an additional functionality
setMaxToRenderPerBatch((layout.nativeEvent.layout.height / layout.nativeEvent.layout.y) + 5); (optional Math.ceil())
}
if (!firstLayoutRef.current) {
return;
}
scrollToIndex(focusedIndex, false);
firstLayoutRef.current = false;
},
[focusedIndex, scrollToIndex],
);
It seems that the number of components being visually rendered is determined by maxToRenderPerBatch.
What changes do you think we should make in order to solve the problem?
To avoid hardcoding a bigger value to make sure the selection is initially filled, we can simply replace the value 5 with: Math.ceil((window.innerHeight - 129)/ 64).
Essentially this formula will calculate how much countries can be shown in the screen.
Why do we subtract window.innerHeight with 129?
129 is the pixel height of the Country Header component plus the height of the Search input for countries.
Why do we divide by 64?
64 is the height of a selectable country component
We then Math.ceil it since we want a whole number since if the quotient is a decimal, it would be impossible to render a component at a fraction. We use Math.ceil instead of Math.floor because in cases wherein the quotients decimal is near the value 1 (0.9, 0.8, etc), a space may still show if we decide to floor it.
The value we get from the formula Math.ceil((window.innerHeight - 129)/ 64) will give us the number of Country components that can fill the initial space.
What alternative solutions did you explore? (Optional)
Source of the Problem
The Initial Number of items being rendered for the list is small , not enough to fill the screen , causing this glitch while opening the country or state selection modal.
What is the root cause of that problem?
the specified number of selections to be rendered initially is 12 which is small and not enough to fill the screen on every device size causing a glitch effect.
initialNumToRender={12}
maxToRenderPerBatch={5}
It seems that the number of components being visually rendered is determined by maxToRenderPerBatch.
Fix for the problem
A bigger value can be passed to the section list.A number large enough to fill the screen that will stop this glitch from occuring that shows up for a while.
We can also avoid just passing a large number statically and pass a more dynamic number that would be optimal for all screen sizes the general formula used would be windowHeight/(height of countryItem)
.This will give us the exact number of items initally required to be rendered on the screen.
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.4-3 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-12-06. 🎊
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.
External issue reporter
Contributor that fixed the issue
Contributor+ that helped on the issue and/or PR
For reference, here are some details about the assignees on this 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:
[@burczu] The PR that introduced the bug has been identified. Link to the PR:
[@burczu] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[@burczu] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[@burczu] Determine if we should create a regression test for this bug.
[@burczu] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[@sonialiap] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:
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:
[@burczu] The PR that introduced the bug has been identified. Link to the PR:
[@burczu] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[@burczu] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
Not found
[@burczu] Determine if we should create a regression test for this bug.
I don't think it's worth adding regression test for this issue - it was just UX fix and there was no impact on any important flow.
[@burczu] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[@sonialiap] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:
Activity
melvin-bot commentedon Nov 21, 2023
Triggered auto assignment to @sonialiap (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.melvin-bot commentedon Nov 21, 2023
Job added to Upwork: https://www.upwork.com/jobs/~01e93d2572ea063da0
[-]Web - Profile - When selecting the last country or state extra space is displayed for a while[/-][+][$500] Web - Profile - When selecting the last country or state extra space is displayed for a while[/+]melvin-bot commentedon Nov 21, 2023
Bug0 Triage Checklist (Main S/O)
Platformsin OP are ✅)melvin-bot commentedon Nov 21, 2023
Triggered auto assignment to Contributor-plus team member for initial proposal review - @burczu (
External)erquhart commentedon Nov 21, 2023
@lanitochka17 the space looks uniform to me, am I missing something?
ZhenjaHorbach commentedon Nov 21, 2023
On macbook(Chrome) I have a bit different situation but looks similar
Screen.Recording.2023-11-21.at.23.09.02.mov
Proposal
Please re-state the problem that we are trying to solve in this issue.
Web - Profile - When selecting the last country or state extra space is displayed for a while
What is the root cause of that problem?
The main problem is how many elements we display when rendering the SectionList per batch
App/src/components/SelectionList/BaseSelectionList.js
Line 454 in da549c0
https://reactnative.dev/docs/optimizing-flatlist-configuration#maxtorenderperbatch
And since we select the last element
The list needs time to display the last elements
This is why we see bugs like this.
What changes do you think we should make in order to solve the problem?
To fix this bug we can increase this property from
5to15(for example) to Increase the list display speedAlso, we have
initialNumToRenderandwindowSize. We can also use these properties for optimization.App/src/components/SelectionList/BaseSelectionList.js
Lines 453 to 455 in da549c0
As an alternative, we can pass these values like props from
CountrySelectionPage,StateSelectorModal, and other screensWhat alternative solutions did you explore? (Optional)
We can also make separate configs for different numbers of elements
And if the lists have more than 100 elements for example
We will increase the values (
initialNumToRender,windowSize,maxToRenderPerBatch) to display elements betterBecause the current values we use for long lists are not very suitable
Or at least we can use dynamic values that we will calculate depending on the number of visible elements using
onLayoutfrom SectionList. But I'm not sure this approach will work for all lists. so if we decide to use dynamicmaxToRenderPerBatch, then it is better to create a new prop that will enable and disable dynamicmaxToRenderPerBatchWe can update
scrollToFocusedIndexOnFirstRenderlikeApp/src/components/SelectionList/BaseSelectionList.js
Lines 313 to 319 in 6c29cab
And then update this line like:
maxToRenderPerBatch={maxToRenderPerBatch}App/src/components/SelectionList/BaseSelectionList.js
Line 454 in 6c29cab
And since we only need this functionality for a certain number of screens
We can use
isDynamicMaxToRenderPerBatchWe can add this prop here
App/src/components/StatePicker/StateSelectorModal.js
Lines 95 to 104 in 6c29cab
And here
App/src/pages/settings/Profile/PersonalDetails/CountrySelectionPage.js
Lines 91 to 99 in 6c29cab
Fralalala commentedon Nov 22, 2023
Proposal
Change the
maxToRenderPerBatchvalue dependent on the window height.Please re-state the problem that we are trying to solve in this issue.
The number of initially rendered selection of countries is not enough to fill the screen.
What is the root cause of that problem?
According to the code below, the specified number of selections to be rendered initially is
12but for some reason is not visually being applied.App/src/components/SelectionList/BaseSelectionList.js
Lines 453 to 454 in da549c0
It seems that the number of components being visually rendered is determined by
maxToRenderPerBatch.What changes do you think we should make in order to solve the problem?
To avoid hardcoding a bigger value to make sure the selection is initially filled, we can simply replace the value
5with:Math.ceil((window.innerHeight - 129)/ 64).Essentially this formula will calculate how much countries can be shown in the screen.
Why do we subtract
window.innerHeightwith129?CountryHeader component plus the height of the Search input for countries.Why do we divide by
64?64is the height of a selectable country componentWe then Math.ceil it since we want a whole number since if the quotient is a decimal, it would be impossible to render a component at a fraction. We use Math.ceil instead of Math.floor because in cases wherein the quotients decimal is near the value
1(0.9, 0.8, etc), a space may still show if we decide to floor it.The value we get from the formula
Math.ceil((window.innerHeight - 129)/ 64)will give us the number of Country components that can fill the initial space.What alternative solutions did you explore? (Optional)
aum1618 commentedon Nov 22, 2023
Proposal : Fix for this Issue
Source of the Problem
The Initial Number of items being rendered for the list is small , not enough to fill the screen , causing this glitch while opening the country or state selection modal.
What is the root cause of that problem?
the specified number of selections to be rendered initially is 12 which is small and not enough to fill the screen on every device size causing a glitch effect.
It seems that the number of components being visually rendered is determined by maxToRenderPerBatch.
Fix for the problem
A bigger value can be passed to the section list.A number large enough to fill the screen that will stop this glitch from occuring that shows up for a while.
We can also avoid just passing a large number statically and pass a more dynamic number that would be optimal for all screen sizes the general formula used would be windowHeight/(height of countryItem)
.This will give us the exact number of items initally required to be rendered on the screen.
24 remaining items
melvin-bot commentedon Nov 29, 2023
Reviewinglabel has been removed, please complete the "BugZero Checklist".melvin-bot commentedon Nov 29, 2023
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.4-3 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-12-06. 🎊
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.
For reference, here are some details about the assignees on this issue:
melvin-bot commentedon Nov 29, 2023
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:
sonialiap commentedon Dec 7, 2023
@ZhenjaHorbach contributer $500 - paid ✔️
sonialiap commentedon Dec 7, 2023
@burczu please complete the checklist :)
burczu commentedon Dec 11, 2023
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:
#27767
https://github.com/Expensify/App/pull/27767/files#r1422160347
Not found
I don't think it's worth adding regression test for this issue - it was just UX fix and there was no impact on any important flow.
sonialiap commentedon Dec 11, 2023
Thanks, Bartek!