Skip to content
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

Remove lingering border from AddressSearch component #6115

Merged
merged 18 commits into from
Nov 9, 2021

Conversation

luacmartins
Copy link
Contributor

@luacmartins luacmartins commented Oct 29, 2021

Details

Not my favorite solution, but it's a temporary workaround to compensate for the limitations of the library.
Wrapped the AddressSearch component in a View to track it's hide and dynamically hide the lingering border.

cc @aldo-expensify @Luke9389

Fixed Issues

$ #5810

Tests

  1. On NewDot, navigate to /bank-account/company
  2. Type in an address that does not exist, e.g. asdasdas
  3. Verify that there is no lingering border below the input
  4. Now, type in an address that exists and select it from the dropdown.
  5. Click on the input again and verify that there is no lingering border.

QA Steps

Steps above.

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web

web.mov

Mobile Web

The component is failing to connect to www.expensify.com.dev on the simulator and returns no address results. We might be missing some config here. This is happening on the main branch as well.

Desktop

desktop.mov

iOS

ios.mov

Android

android.mov

@luacmartins luacmartins self-assigned this Oct 29, 2021
@luacmartins luacmartins marked this pull request as ready for review October 29, 2021 19:52
@luacmartins luacmartins requested a review from a team as a code owner October 29, 2021 19:52
@MelvinBot MelvinBot requested review from timszot and removed request for a team October 29, 2021 19:52
aldo-expensify
aldo-expensify previously approved these changes Oct 29, 2021
Copy link
Contributor

@aldo-expensify aldo-expensify left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must say that I'm a bit amazed with the clever way you found to solve this. The solution works. In other context I would have thought that this solution is too much of a workaround, but in this case I haven't seen any other solution (besides forking the library 🤮 ).

NAB 1: I feel like display state could have a better name.
NAB 2: Just for consistency, I think we stick to class components when we have states (style guide). Maybe it should be changed to a class component.

Tested on web/android both were working 🎉 🎉

src/components/AddressSearch.js Outdated Show resolved Hide resolved
@luacmartins
Copy link
Contributor Author

Updated!

@luacmartins luacmartins removed the request for review from timszot October 29, 2021 21:03
@luacmartins luacmartins marked this pull request as draft October 29, 2021 21:04
@luacmartins
Copy link
Contributor Author

Found some issues with the solution. Converting to draft!

@luacmartins
Copy link
Contributor Author

Apparently we might have to leave this one as a functional component to make use of setAddressText - FaridSafi/react-native-google-places-autocomplete#609 (comment)

@luacmartins luacmartins marked this pull request as ready for review October 29, 2021 21:27
@luacmartins luacmartins requested a review from a team October 29, 2021 21:27
@MelvinBot MelvinBot requested review from MariaHCD and removed request for a team October 29, 2021 21:27
@luacmartins
Copy link
Contributor Author

Updated!

@aldo-expensify
Copy link
Contributor

Apparently we might have to leave this one as a functional component to make use of setAddressText - FaridSafi/react-native-google-places-autocomplete#609 (comment)

maybe we should leave comment in the code, so we don't accidentally convert it to class component

@aldo-expensify
Copy link
Contributor

It is still breaking if the scroll bar appears because the error text wraps:

Screen Shot 2021-10-29 at 2 40 16 PM

aldo-expensify
aldo-expensify previously approved these changes Oct 29, 2021
Copy link
Contributor

@aldo-expensify aldo-expensify left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested on web and Android. It is working now including when there are error message (wrapping and not wrapping)

Copy link
Contributor

@Luke9389 Luke9389 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a tough issue. I've wrestled with it a lot myself. My suggestion could be hard to implement and don't break your back trying. Just give it a shot and see if it's feasible. We can discuss more.

src/components/AddressSearch.js Show resolved Hide resolved
Comment on lines 88 to 92
// The height of the input + wrapped error message is 112 pixels
<View
onLayout={(event) => {
const {height} = event.nativeEvent.layout;
return height > 112 ? setDisplayListViewBorder(true) : setDisplayListViewBorder(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know the answer to this question but it seems worth asking. Can we use a more dynamic way to measure the height? We have a ref to the <GooglePlacesAutoComplete> component so maybe we can use the measure function (mentioned here).

Copy link
Contributor Author

@luacmartins luacmartins Oct 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm we can definitely get the input's height dynamically. I'm not sure if it's worth it though, because we still have to manually compensate for the top margin and border width, so the conditional becomes something like this height > inputHeight + 6. Also, the solution is far from elegant 🤣

I'll spend a bit more time and see if I can come up with something better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually managed to move the onLayout prop to the GooglePlacesAutocomplete component and now the solution is independent of the text input height. Thanks for the tip @Luke9389!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, I'll review again

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh rad, nice work @luacmartins! I really appreciate you following through on that. 🙇

@luacmartins
Copy link
Contributor Author

Updated!

Copy link
Contributor

@aldo-expensify aldo-expensify left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a comment about style guidelines.

There is a few milliseconds flickering of the border when it opens in Android, not sure if it is worth trying to fix it. When we get the results, there is no rounded top border, and then it appears.

screen-20211101-114111_2.mp4

src/components/AddressSearch.js Outdated Show resolved Hide resolved
@luacmartins
Copy link
Contributor Author

Updated!

@luacmartins
Copy link
Contributor Author

luacmartins commented Nov 1, 2021

I noticed the flickering as well, but in all platforms. It seems like a delay between state update and component re-rendering. I put up a workaround to hide the element for those few milliseconds - it's not a pretty solution 😞

I would imagine that we will redo a few of these inputs as part of creating our new form component, and I would suggest that we create our own version of the AddressSearch component.

styles.borderTopRounded,
styles.borderBottomRounded,
styles.mt1,
!displayListViewBorder && styles.googleListView,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By doing this, we are applying transform: {[scale:0]} whenever displayListViewBorder is false correct? Is this what you were referring to here?

I put up a workaround to hide the element for those few milliseconds - it's not a pretty solution 😞

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! I used this workaround to prevent an UI flicker.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, gotcha. I know this has been a debugging marathon, but I think we should try and get to the bottom of why the top border flicker is happening.

I would imagine that we will redo a few of these inputs as part of creating our new form component, and I would suggest that we create our own version of the AddressSearch component.

I think the reality of this situation is that we are not guaranteed that we'll ever make our own AddressSearch component. And if we can fix it here and make it work perfectly for us, we'll never have to. I know it feels like we're wrestling with jankyness we didn't create (which is true) but we're so close to finally polishing off this component.

I'd be happy to help with debugging this. I won't have time to do that tonight, but I can check out this branch and poke around tomorrow if you'd like another pair of eyes on this.

Copy link
Contributor Author

@luacmartins luacmartins Nov 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough 👍 My best guess for why the flicker happens is:

  1. User starts typing and we fetch results. The height of the dropdown changes and it becomes visible.
  2. We detect the height change, set displayListViewBorder=true and apply the styles.

So I think that the component becomes visible before we can apply any style changes. This might be a limitation of my solution.

I explored other ways of preventing the flicker, but couldn't come up with anything. Another set of eyes are always appreciated. Feel free to take a look 😄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason we are not considering a fork and just add an extra condition in this if statement:

https://github.com/FaridSafi/react-native-google-places-autocomplete/blob/47d7223dd48f85da97e80a0729a985bbbcee353f/GooglePlacesAutocomplete.js#L751-L757

We would just have to add something like: dataSource.length &&. It work right away and would save a bunch of time spent on workarounds.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I have the answer to that question. Maybe @Luke9389 has more context here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far, we haven't been faced with a situation that requires a fork, but I'd support that if it were proposed. Would either of you like to spearhead that? I'm thinking it would probably come in the form of a Problem Solution statement.

@luacmartins
Copy link
Contributor Author

luacmartins commented Nov 8, 2021

Ok, given the discussing around this issue, should we:

  1. Merge this PR as a temporary fix, maybe with the hardcoded value until we hear back from the library maintainer or fork the library.
  2. Close this PR.

Curious to hear what people think.

@Luke9389
Copy link
Contributor

Luke9389 commented Nov 8, 2021

Yea, I'd be fine with that.

Copy link
Contributor

@MariaHCD MariaHCD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having this as a temporary fix makes sense to me!

Copy link
Contributor

@aldo-expensify aldo-expensify left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm (as temporary fix :P)

@aldo-expensify aldo-expensify merged commit 7b2e671 into main Nov 9, 2021
@aldo-expensify aldo-expensify deleted the cmartins-fixLingeringBorder branch November 9, 2021 19:48
@OSBotify
Copy link
Contributor

OSBotify commented Nov 9, 2021

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @aldo-expensify in version: 1.1.14-5 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@ogumen
Copy link

ogumen commented Nov 21, 2021

The accessibility issues found in this PR:
Web

  1. The company address search suggestions are not keyboard accessible - failure of WCAG SC 2.1.1
    https://user-images.githubusercontent.com/88733897/142782288-c1df84e5-b934-48eb-8809-0c60f9e604d3.mp4
  2. The presence and number of search suggestions is not conveyed by screen reader - failure of WCAG SC 4.1.3
    https://user-images.githubusercontent.com/88733897/142782382-315c01e1-b998-4694-8ccc-c1845bcd9024.mp4

Android

  1. The presence and number of search suggestions is not conveyed by screen reader - failure of WCAG SC 4.1.3
    Android_The presence and number of search suggestions are not conveyed by screen reader

@OSBotify
Copy link
Contributor

🚀 Deployed to production by @AndrewGable in version: 1.1.15-15 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants