Repository navigation
Detect split request based on the route params - #33482
Conversation
|
@parasharrajat 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] |
| } | ||
| IOU.updateMoneyRequestTypeParams(routes, newIouType.current); | ||
| newIouType.current = null; | ||
| }, [routes, participants]); |
There was a problem hiding this comment.
I decided to update the route params, ONLY after the participant onyx is updated.
There was a problem hiding this comment.
Are you safe guarding the case where participants are failed to update in Onyx due to some unexpected reason?
There was a problem hiding this comment.
Nope. This is to help reduce the lag where the participant Onyx is late to update, so I want to make sure the participant is updated first. But somehow, this morning I retested it (updating both params and participant at the same time), and the flow works really smoothly and fast.
I don't know exactly what happened with the performance when I worked on the PR, but I think we can keep this.
There was a problem hiding this comment.
Let's add a comment explaining the logic purpose.
There was a problem hiding this comment.
// Participants can be added as normal or split participants. We want to wait for the participants' data to be updated before
// updating the money request type route params reducing the amount of work at the same time.
Do you think this is enough?
There was a problem hiding this comment.
@parasharrajat looks like we got no answer from the internal team yet, but let's say we are not allowed to do it, I have another alternative.
We will use the useEffect back. Then, how do we fix the case where the selected participants are the same? We can update the params immediately knowing the participants' onyx won't be updated.
What do you think?
There was a problem hiding this comment.
@parasharrajat So, the conclusion is we are not allowed to do the promise chaining. This left us with the alternate option above
There was a problem hiding this comment.
That looks feasible to me. let's do it. I wasn't sure of action chaining but had doubts. Thanks for bringing this to Slack, it will help us keep code clear and minimize refactor efforts.
There was a problem hiding this comment.
let's reset the newIouType after calling the updateRouteParams in addparticipant and keep updateRouteParams clean.
|
Unit test failing on main too |
|
@bernhardoj Please merge the main when you can. I think those tests are fixed now. |
|
Done |
|
@parasharrajat I found an issue, please hold |
|
@parasharrajat In case you missed it, here is the issue that I mean |
|
Thanks for sharing. I was about to ask that. |
I actually still don't understand which part is not consistent. Can you explain it more? Maybe we have a different understanding. Not updating the |
On the first page of Request money with the tab switcher, whenever we switch to Manual, Scan or Distance, the title remains "Request money" regardless of which tab is active. Since this is the case for all the tabs, it's more consistent to keep the title as "Request money" before the user moves on to the next page with the participants selector, where the title can change to "Split" for split request, or remain as "Manual" for a regular manual request. Hope this makes sense. |
|
@bernhardoj For additional context, this is the page I'm referring to. If I return to this page while a split participant is still selected, the title changes to "Split bill", but it should remain "Request money" since the other tabs maintain the same title as well. |
The title is not the tab title, but the start page title. App/src/pages/iou/request/IOURequestStartPage.js Lines 147 to 150 in cfa0ae3 When you switch tabs, we reset the data (and params), so you see "Request money" again. This will happen if we change that behavior. Screen.Recording.2024-02-27.at.19.56.51.mov |
|
@bernhardoj I see. I realise the tab titles are from the previous flow prior to the money request tabs being added ("Split bill" used to be a separate menu item in the FAB iirc). One feasible approach would be to set the corresponding start page title for App/src/pages/iou/request/IOURequestStartPage.js Lines 74 to 78 in cfa0ae3 |
Reviewer Checklist
Screenshots/VideosAndroid: Native33482-android-native.mp4Android: mWeb Chrome33482-android-chrome.mp4iOS: Native33482-ios-native.mp4iOS: mWeb Safari33482-ios-safari.mp4MacOS: Chrome / Safari33482-web.mp4MacOS: Desktop33482-desktop.mp4 |
|
Screen.Recording.2024-02-28.at.04.02.22.mov |
|
Checking |
|
Fixed. The problem is we reset the I decided to only reset the |
| Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(nextStepIOUType, transactionID, selectedReportID.current || reportID)); | ||
| }, [iouType, transactionID, reportID]); | ||
| const goToNextStep = useCallback( | ||
| (isSplit) => { |
There was a problem hiding this comment.
Is this param really needed? It seems like iouType gets updated from the route once we tab 'split' on a participant. Simply using iouType here seems to work fine. Can you double check pelase?
There was a problem hiding this comment.
I think it would be nice if we removed it, or find a way to make this onFinish(true); less ambiguous, it's not immediately obvious what the boolean is doing there.
There was a problem hiding this comment.
It's to cover a case where the iouType is not updated yet when goToNextStep is called.
- Add a participant to split. At this point,
iouTypeis split - Press the participant. When
goToNextStepis called,iouTypeis still split, but it should be a request.
find a way to make this onFinish(true); less ambiguous,
addParticipant also has isSplit on the param, maybe we can pass the iou type instead of boolean?
const goToNextStep = useCallback(
(selectedIouType) => {
const isSplit = selectedIouType === CONST.IOU.TYPE.SPLIT;
There was a problem hiding this comment.
- Add a participant to split. At this point, iouType is split
- Press the participant. When goToNextStep is called, iouType is still split, but it should be a request.
Nice, yeah I knew I was missing something :D.
addParticipant also has isSplit on the param, maybe we can pass the iou type instead of boolean?
Yeah this looks better, thanks!
Nice thanks, that fixed it. |
youssef-lr
left a comment
There was a problem hiding this comment.
Thanks for the changes!
|
✋ 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/youssef-lr in version: 1.4.45-0 🚀
|
|
This seems to have introduced this issue It also seems it is not possible to request splits twice from the same user when it is a new user, as the app tries to generate a new chat and it errors out |
|
🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.45-6 🚀
|
| {({didScreenTransitionEnd}) => ( | ||
| <MoneyRequestParticipantsSelector | ||
| participants={participants} | ||
| participants={isSplitRequest ? participants : []} |
There was a problem hiding this comment.
Mark for reference.
| // When going back to the participants step, if the iou is a "request" (not a split), then the participants need to be cleared from the | ||
| // transaction so that the participant can be selected again. | ||
| if (iouType === CONST.IOU.TYPE.REQUEST) { | ||
| IOU.setMoneyRequestParticipants_temporaryForRefactor(transactionID, []); | ||
| } |
There was a problem hiding this comment.
Mark for reference.
| ); | ||
|
|
||
| const goToNextStep = useCallback(() => { | ||
| const nextStepIOUType = numberOfParticipants.current === 1 ? iouType : CONST.IOU.TYPE.SPLIT; |
There was a problem hiding this comment.
This is only mark for reference (Not for this PR author).
nextStepIOUType will not be relevant now. Please use iouType directly for navigation to confirmation page.


Details
After the money request was refactored, we lost the split request flag. This flag is used to change the title to Split if it's a split request and allow the user to split with 1 participant. In this PR, we update the iouType params everytime we do a split request.
Fixed Issues
$ #32912
PROPOSAL: #32912 (comment)
Tests
Same as QA Steps
Offline tests
Same as QA Steps
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.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)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel so the design team can review the changes.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
Android: Native
Screen.Recording.2023-12-22.at.16.18.36.mov
Android: mWeb Chrome
Screen.Recording.2023-12-22.at.16.13.43.mov
iOS: Native
Screen.Recording.2023-12-22.at.16.12.42.mov
iOS: mWeb Safari
Screen.Recording.2023-12-22.at.16.14.34.mov
MacOS: Chrome / Safari
Screen.Recording.2023-12-22.at.16.10.43.mov
MacOS: Desktop
Screen.Recording.2023-12-22.at.16.11.55.mov