-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Conversation
There was a problem hiding this 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 🎉 🎉
Updated! |
Found some issues with the solution. Converting to draft! |
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) |
Updated! |
maybe we should leave comment in the code, so we don't accidentally convert it to class component |
There was a problem hiding this 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)
There was a problem hiding this 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
Outdated
// 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); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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. 🙇
Updated! |
There was a problem hiding this 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
Updated! |
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, |
There was a problem hiding this comment.
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 😞
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- User starts typing and we fetch results. The height of the dropdown changes and it becomes visible.
- 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 😄
There was a problem hiding this comment.
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:
We would just have to add something like: dataSource.length &&
. It work right away and would save a bunch of time spent on workarounds.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Ok, given the discussing around this issue, should we:
Curious to hear what people think. |
Yea, I'd be fine with that. |
There was a problem hiding this 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!
There was a problem hiding this 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)
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by @aldo-expensify in version: 1.1.14-5 🚀
|
The accessibility issues found in this PR:
Android |
🚀 Deployed to production by @AndrewGable in version: 1.1.15-15 🚀
|
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
/bank-account/company
asdasdas
QA Steps
Steps above.
Tested On
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