[Distance] IOU Distance - Recent list disappears after clearing address field, leaving a big space

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Issue found when executing PR #25990

Action Performed:

1. Go to staging.new.expensify.com
2. Go to + > Request money > Distance
3. Click Start > Use current location
4. Go to Start again
5. Highlight the address field
6. Clear the input

Expected Result:

The recent address list will not disappear

Actual Result:

The recent address list disappears, leaving a huge space between the address field and Use current location button

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.61-1

Reproducible in staging?: Yes

Reproducible in production?: No

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

Bug6184883_bandicam_2023-09-01_17-41-32-773.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

[OSBotify]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

Triggered auto assignment to @grgia (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[Pujan92]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On clearing the text list shows empty space

What is the root cause of that problem?

On input change within AddressSearch we set the displayListViewBorder to false when the text is empty.

App/src/components/AddressSearch/index.js

Lines 336 to 339 in 5db2445

	// If the text is empty, we set displayListViewBorder to false to prevent UI flickering
	if (_.isEmpty(text)) {
	setDisplayListViewBorder(false);
	}

Based on displayListViewBorder value we are applying a style to scale down to 0 which is causing the issue.

App/src/components/AddressSearch/index.js

Line 346 in 5db2445

listView: [StyleUtils.getGoogleListViewStyle(displayListViewBorder), styles.overflowAuto, styles.borderLeft, styles.borderRight],

App/src/styles/StyleUtils.js

Lines 1190 to 1192 in 5db2445

	return {
	transform: [{scale: 0}],
	};

What changes do you think we should make in order to solve the problem?

When predefinedPlaces is available we don't need to scale to 0, for that we need to update the condition

if (_.isEmpty(text) && _.isEmpty(props.predefinedPlaces)) {

Result

Screen.Recording.2023-09-01.at.21.25.21.mov

[huzaifa-99]

I will be fixing this with a new PR (taking changes from #25990)

cc: @hayata-suenaga @narefyev91

[Pujan92]

@huzaifa-99 I think this issue is not due to your PR as we are passing predefinedPlaces earlier too.
cc: @grgia

[huzaifa-99]

@Pujan92 Yes its directly not related to my changes. But i am not sure if we should treat it as regression or bug here since this issue was not visible before my changes.

cc: @hayata-suenaga @narefyev91

[Pujan92]

It exists from this PR, but at that moment we don't have any other content below that so not easily caught. Since you added the current location option below that which highlights the issue.

After checkout the mentioned PR commit

Screen.Recording.2023-09-01.at.21.48.40.mov

[luacmartins]

We reverted the offending PR. Removing the blocker label.

[hayata-suenaga]

@huzaifa-99 when you open the new PR, please link this issue there

[huzaifa-99]

@hayata-suenaga sure. Thanks

[Pujan92]

@hayata-suenaga just to inform this issue is not from the reverted PR.
proposal - #26482 (comment)
issue still persists - #26482 (comment)

If you still think it needs to be considered with the @huzaifa-99 PR, I am fine but wanted to highlight it! :)

[huzaifa-99]

There were 2 ways to solve this

When text in search is empty

1. We still show the suggestion list if there are predefined suggested places (which we have in this case), this is similar to as suggested by @Pujan92
2. We hide the suggestions list.

I believe if places are predefined then 1 looks good, so I will be implementing that.

cc: @hayata-suenaga @Pujan92

[hayata-suenaga]

@huzaifa-99 I don't have much background why displayListViewBorder is needed and why UI flickering occurs in the first place without it.

Based on displayListViewBorder value we are applying a style to scale down to 0 which is causing the issue.

What are we scaling down? GooglePlacesAutocomplete? And how that is related to the gap that is observed?

[huzaifa-99]

@huzaifa-99 I don't have much background why displayListViewBorder is needed and why UI flickering occurs in the first place without it.

I am not entirely sure about the UI flickering either, but the predefinedPlaces here displays the suggestion and it gets displayed whenever there is a predefined places and the text input for address search is focused. And when text is an empty string, then we apply transform: [{scale: 0}] to the suggestions dropdown i.e listView of address search here.

I don't have much background why displayListViewBorder is needed and why UI flickering

I will do more digging into this and update.

[Pujan92]

@huzaifa-99 I don't have much background why displayListViewBorder is needed and why UI flickering occurs in the first place without it.

@hayata-suenaga displayListViewBorder is used to decide whether to show the hint below the textinput or not. It means when we are showing the list we hide the hint otherwise list starts after the hint.

What are we scaling down? GooglePlacesAutocomplete? And how that is related to the gap that is observed?

It seems scaling down was added to avoid showing the empty area which created through padding when user searches but there aren't any options. Now we don't require scaling down part as we have a separate ListEmptyComponent.

If we remove the ListEmptyComponent and take out the scaling down then this issue occurs.

Screen.Recording.2023-09-02.at.18.07.06.mov

[hayata-suenaga]

ah yea I see that

@hayata-suenaga just to inform this issue is not from the reverted PR.
proposal - #26482 (comment)
issue still persists - #26482 (comment)

If you still think it needs to be considered with the @huzaifa-99 PR, I am fine but wanted to highlight it! :)

@huzaifa-99 unless you're already handling this in your second-attempt current location PR, @Pujan92 can work on the fix 👍

[huzaifa-99]

@hayata-suenaga Actually I already made a commit for this in the pr. Similar to what was suggested by @Pujan92

[Pujan92]

@huzaifa-99 still we need to make a change to get rid of displayListViewBorder for the styling part here as now we are providing ListEmptyComponent with not found text. I think we can make the entire change here if @hayata-suenaga agrees.

App/src/components/AddressSearch/index.js

Line 350 in 6b1a667

listView: [StyleUtils.getGoogleListViewStyle(displayListViewBorder), styles.overflowAuto, styles.borderLeft, styles.borderRight],

App/src/styles/StyleUtils.ts

Lines 1044 to 1057 in 6b1a667

	function getGoogleListViewStyle(shouldDisplayBorder: boolean): ViewStyle | CSSProperties {
	if (shouldDisplayBorder) {
	return {
	...styles.borderTopRounded,
	...styles.borderBottomRounded,
	marginTop: 4,
	paddingVertical: 6,
	};
	}
	return {
	transform: [{scale: 0}],
	};
	}

[huzaifa-99]

I think we can make the entire change here

@Pujan92 Sounds good to me

[Pujan92]

We need still scaling for the smooth transition for hiding the hint and showing the list otherwise it flickers a bit. So @hayata-suenaga what @huzaifa-99 added in their PR seems fine to me.

Screen.Recording.2023-09-05.at.16.09.05.mov

[hayata-suenaga]

thank you for confirming!

[melvin-bot]

This issue has not been updated in over 15 days. @Pujan92, @hayata-suenaga eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[hayata-suenaga]

are we good to close this issue?

seems like @huzaifa-99 fixed this issue in their PR?

[huzaifa-99]

seems like @huzaifa-99 fixed this issue in their PR?

yes @hayata-suenaga