fix: logic for waypoint validation#26591
Conversation
|
reviewing this one based on @hayata-suenaga's request |
If there are |
|
@ntdiary What error do you get? |
This is the main fix from this PR. |
|
@allroundexperts after validation filter, keys should be rearranged. waypoint1 instead of waypoint3
|
error.mp4Did you not try clicking |
Should be related to #26591 (comment) |
Yeah, this is the error I mentioned, and it only needs to be rearranged when creating the request (not when selecting locations), otherwise it will cause the second stop waypoint and finish waypoint to become the same location. duplicate.mp4 |
|
The issue mentioned above has been fixed @situchan! |
| const validWaypoints = _.reduce( | ||
| waypointValues, | ||
| (acc, currentWaypoint, index) => { | ||
| const previousWaypoint = waypointValues[index - 1]; | ||
| // Check if the waypoint has a valid address | ||
| if (!currentWaypoint || !currentWaypoint.address || typeof currentWaypoint.address !== 'string' || currentWaypoint.address.trim() === '') { | ||
| return acc; | ||
| } | ||
|
|
||
| // Check for adjacent waypoints with the same address | ||
| if (previousWaypoint && currentWaypoint.address === previousWaypoint.address) { | ||
| return acc; | ||
| } | ||
|
|
||
| const lastIndex = Math.max(..._.map(_.keys(acc), (key) => parseInt(key.replace('waypoint', ''), 10))); | ||
| return {...acc, [`waypoint${reArrangeIndexes && lastIndex > -1 ? lastIndex + 1 : index}`]: currentWaypoint}; | ||
| }, | ||
| {}, | ||
| ); |
There was a problem hiding this comment.
I think we can refactor this code to be more readable.
How about changing to array first using _.filter and then back to object?
This won't require calculating key names in complex way.
There was a problem hiding this comment.
Doing so will not preserve the keys. We want to not preserve the keys only when creating the distance request.
There was a problem hiding this comment.
Doing so will not preserve the keys. We want to not preserve the keys only when creating the distance request.
I also commented here. But did you find any issue without preserving keys on Request money page before creating request?
There was a problem hiding this comment.
Doesn't work. Ref:
Screen.Recording.2023-09-03.at.4.39.48.PM.mov
There was a problem hiding this comment.
What's the root cause? I thought waypoints is used to display routes, not validatedWaypoints
There was a problem hiding this comment.
No. The route is calculated via the validatedWaypoints. The response from the getRoute request gets stored into onyx. Since the response has the same keys as the waypoints supplied in the request body, therefore, the above error occurs.
There was a problem hiding this comment.
App/src/components/DistanceRequest.js
Line 174 in 388ddc8
There was a problem hiding this comment.
FYI, I have simplified the logic for calculating the new indexes!
| createdIOUReportActionID, | ||
| reportPreviewReportActionID: reportPreviewAction.reportActionID, | ||
| waypoints: JSON.stringify(transaction.comment.waypoints), | ||
| waypoints: JSON.stringify(TransactionUtils.getValidWaypoints(transaction.comment.waypoints, true)), |
There was a problem hiding this comment.
I don't think 2nd param is needed.
This will also be used in GetRoute api. And doesn't affect displaying routes.
There was a problem hiding this comment.
I think we need this logic to reorganize indices to be consecutive (i.e. we need to pass true)
There was a problem hiding this comment.
yes, I meant to reorganize always without needing to pass 2nd param but later I realized it should be conditional
|
Branch conflicts now |
|
@situchan I did the NAB changes and it would be great if you could do a final sanity check! |
| * @param {Object} waypoint | ||
| * @returns {Boolean} Returns true if the address is valid | ||
| */ | ||
| function waypointHasValidAddress(waypoint) { |
There was a problem hiding this comment.
hasWaypointValidAddress is better name
Looks good |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
I realized a problem with this PR (there is no regression yet from this one, and I doubt that there will be) the reducer function for waypoints to filter out invalid waypoints is assuming that But the ordering of values are not guaranteed. So we have to sort the waypointValues based on the index that is included in the key If you agree, can you make a follow up PR @allroundexperts 🙇 ? |
|
@hayata-suenaga you mean initial |
I haven't found any case where this doesn't happen. Checking now |
|
I think |
That's an interesting thing. In my impression, JS does not promise the order of properties in an object. I noticed this before, but after testing there did not seem to be any abnormal cases, so I did not report it. Also, I was curious before why |
|
🚀 Deployed to staging by https://github.com/hayata-suenaga in version: 1.3.63-0 🚀
|
|
PR for sorting: #26705 |
This is a very good point that I also noticed. We should do a cleanup eventually. I first need to ask the engineer who came up with this design to see if there was a particular reason we went this way though |
|
🚀 Deployed to production by https://github.com/mountiny in version: 1.3.63-2 🚀
|
|
🚀 Deployed to staging by https://github.com/hayata-suenaga in version: 1.3.64-0 🚀
|
|
🚀 Deployed to production by https://github.com/mountiny in version: 1.3.64-2 🚀
|






Details
This PR fixes the logic to check the start and end way points of a distance request.
Fixed Issues
$ #26583
PROPOSAL: #26583 (comment)
Tests
+icon in the LHN.Verify that the route is shown correctly.
Offline tests
N/A
QA Steps
+icon in the LHN.Verify that the route is shown correctly.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)Avataris modified, I verified thatAvataris working as expected in all cases)ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Web
Screen.Recording.2023-09-03.at.4.23.29.AM.mov
Mobile Web - Chrome
Screen.Recording.2023-09-03.at.4.31.22.AM.mov
Mobile Web - Safari
Screen.Recording.2023-09-03.at.4.32.47.AM.mov
Desktop
Screen.Recording.2023-09-03.at.4.26.04.AM.mov
iOS
Screen.Recording.2023-09-03.at.4.33.27.AM.mov
Android
Screen.Recording.2023-09-03.at.4.34.30.AM.mov