-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
feat: Add distance label on map route #55517
Conversation
@shubham1206agra Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
The screenshot/videos are looking pretty good to me. I'm going to try to spin up a test build so we can hopefully get a feel for it in real life. |
🚧 @dannymcclain has triggered a test build. You can view the workflow run here. |
🧪🧪 Use the links below to test this adhoc build on Android, iOS, Desktop, and Web. Happy testing! 🧪🧪 |
Nice—looking good and working well to me! |
I think the confirmation screen is basically showing like the "final receipt" - so I think we just need to determine if we think the final receipt should have it or not? Part of me thinks it doesn't need it since the total distance is written in text below as well as when you click into the receipt to view the whole image. No strong feelings though, I could also get down with showing it. Great review of the other small design bugs though! |
I almost said something about this, but since the path changes based on stops and zoom level, it seems like something that we're never going to be able to get perfect 100% of the time. Great catches with the blue dot and typeface!! I think subconsciously something felt off about the typeface but I wasn't confident enough in the feeling to say anything 😂 As far as the confirmation screen goes, I could go either way. I basically feel exactly this:
|
I updated PR. Here is the result: ![]() |
Visually looks good. Did we have more controls over where to place the label itself to avoid overlap on the path @truph01 ? |
I did consider this option when implementing the PR, but there’s no way to guarantee the distance label won’t overlap the path. As someone mentioned earlier, "it feels like something we’re never going to get perfectly right 100% of the time." |
Alright. Happy to merge then 👍 |
@truph01 The unit of distance is not changing if I change the unit of distance from another device. Can you please fix this? |
I think we need to confirm the expected behavior here. Below are steps:
We should go with Option 1 because consistency is key. If Device A continues to display km until it refreshes or re-fetches data, it ensures a stable user experience without unexpected UI changes. Instantly switching to mi could be confusing, especially if the user isn't aware of the setting change from Device B. Keeping the current unit until an intentional refresh makes the behavior predictable and user-friendly. cc @dubielzyk-expensify |
@truph01 Can you fix the tests here? |
I don't think this is a huge use case that we need to do much about. I do think the km/mi should always reflect the workspace settings but I don't think we need to fetch the data mid-flow. Basically I don't think we need to build anything specifically for this usecase. cc @Expensify/design for vis |
@shubham1206agra The reassure performance test error isn't related to our code changes. |
Reviewer Checklist
Screenshots/Videos |
@truph01 Can you address this last comment? |
@shubham1206agra I updated PR to address comment. |
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.
Looking good! Nice job!
✋ 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 https://github.com/Gonals in version: 9.0.95-0 🚀
|
🚀 Deployed to production by https://github.com/Julesssss in version: 9.0.95-6 🚀
|
// Find the index of the middle element | ||
const middleIndex = Math.floor(length / 2); |
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.
Coming from #56531 checklist: We can enhance the logic by finding the closest point to the center of the waypoints instead of using the middle index, which may hide the distance label in some cases.
style={{marginRight: 100}} | ||
> | ||
<View style={styles.distanceLabelWrapper}> | ||
<View style={styles.distanceLabelText}> {DistanceRequestUtils.getDistanceForDisplayLabel(distanceInMeters, distanceUnit)}</View> |
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.
This was supposed to display a text value, wrapping it in a view caused #56603
Explanation of Change
Fixed Issues
$ #53421
PROPOSAL: #53421 (comment)
Tests
Offline tests
QA Steps
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Screen.Recording.2025-01-22.at.01.50.39.mov
Android: mWeb Chrome
Screen.Recording.2025-01-22.at.01.22.55.mov
iOS: Native
Screen.Recording.2025-01-22.at.01.10.21.mov
iOS: mWeb Safari
Screen.Recording.2025-01-22.at.01.21.08.mov
MacOS: Chrome / Safari
Screen.Recording.2025-01-22.at.01.16.09.mov
MacOS: Desktop
Screen.Recording.2025-01-22.at.01.22.07.mov