-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Start using new new RequestCall Onyx-optimized API command instead of Inbox_CallUser #9573
Conversation
3bdfb77
to
1e08c0b
Compare
1e08c0b
to
b9df3b1
Compare
… update with success or fail data
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 looks really good and it works well. I have a question about how we render the confirmation page, and we also need to have the blocking form implemented.
src/pages/RequestCallPage.js
Outdated
<Button | ||
success | ||
pressOnEnter | ||
onPress={this.onSubmit} | ||
style={[styles.w100]} | ||
text={this.props.translate('requestCallPage.callMe')} | ||
isLoading={this.props.requestCallForm.loading} | ||
isDisabled={isBlockedFromConcierge} | ||
/> |
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.
To implement offline UX pattern C we need to disable this button, prevent the form from submitting, and show the user that they are offline.
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.
Ah yes. Using FormAlertWithSubmitButton
to fix this. Thanks!
4349eac
to
f3f6aab
Compare
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.
Awesome, good to go from me. Let's see what @marcaaron has to say.
} | ||
const data = []; | ||
|
||
// Make sure we have a response (i.e. this isn't a promise being passed down to us by a failed retry request and responseData is undefined) |
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.
// Make sure we have a response (i.e. this isn't a promise being passed down to us by a failed retry request and responseData is undefined) | |
// Make sure we have response data (i.e. response isn't a promise being passed down to us by a failed retry request and responseData is not undefined) |
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.
Not sure if I get this comment. response
and not responseData
is the part that would be a promise passed down to us by a failed retry request?
if (request.successData) { | ||
data.push(...request.successData); | ||
} | ||
const data = []; |
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.
const onyxUpdates = [];
// Make sure we have a response (i.e. this isn't a promise being passed down to us by a failed retry request and responseData is undefined) | ||
if (responseData) { | ||
// Handle the request's success/failure data (client-side data) | ||
if (responseData.jsonCode === 200 && request.successData) { |
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.
It looks like if we have request.failureData
, but no request.successData
and the responseData.jsonCode === 200
then the failureData
will be pushed.
const data = []; | ||
|
||
// Make sure we have a response (i.e. this isn't a promise being passed down to us by a failed retry request and responseData is undefined) | ||
if (responseData) { |
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.
NAB, I think this would be a little cleaner if we just returned early with the responseData
if it's not defined.
src/libs/actions/Inbox.js
Outdated
Navigation.goBack(); | ||
return; | ||
} | ||
// Set loading spinner as we wait for the request to complete |
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.
NAB, these details feel like something the UI should worry about. Not sure if the comments here help since the context is somewhere else.
src/libs/actions/Inbox.js
Outdated
onyxMethod: 'merge', | ||
key: ONYXKEYS.ACCOUNT, | ||
value: { | ||
success: true, |
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 success: true
for? Is this ACCOUNT
data supposed to be 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.
Yeah this will show the confirmation that the call was requested here:
https://github.com/Expensify/App/pull/9573/files#diff-2950751ea6e5a3b24fe47d391faa69d373aa4ee9d27dfdda253d7857beb1b9faR300-R303
This is similar to how the PasswordPage does it (and where I copied from):
App/src/pages/settings/PasswordPage.js
Lines 156 to 161 in 53431af
/> | |
{!_.isEmpty(this.props.account.success) | |
? ( | |
<PasswordConfirmationScreen /> | |
) : ( | |
<> |
src/pages/RequestCallPage.js
Outdated
/** Holds information about the users account that is requesting the call */ | ||
account: PropTypes.shape({ | ||
/** Success state to show confirmation of requesting a call */ | ||
success: PropTypes.boolean, |
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.
Would it be better to use requestCallForm
to store this? account
is pretty generic.
account.success
doesn't really scream "Success state to show confirmation of requesting a call"
Maybe we can err on the side of being specific here and make it requestCallForm.didRequestCallSucceed
or something?
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.
Ah okay, sorry, this is carrying over from your comment above.
Yeah that works as an alternative for me 👍
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.
LGTM thanks for the changes!
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.
Good to go.
✋ 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 @yuwenmemon in version: 1.1.81-0 🚀
|
🚀 Deployed to production by @roryabraham in version: 1.1.82-5 🚀
|
if (!responseData) { | ||
return; | ||
} | ||
|
||
// Handle the request's success/failure data (client-side data) | ||
if (responseData.jsonCode === 200 && request.successData) { | ||
onyxUpdates.push(...request.successData); | ||
} else if (responseData.jsonCode !== 200 && request.failureData) { | ||
onyxUpdates.push(...request.failureData); | ||
} |
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.
cc @yuwenmemon
I'm not sure if this case matters, but if a requests hits the back end with a command that is not implemented, the backend returns a 404. I would have expected that the failureData
to be pushed into Onyx, but it isn't because responseData
is undefined so I ended up without feedback in the UI. Could this happen in a real case? like if we try to send a request about a workspace or a chat that doesn't exist anymore?
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 see what you mean because the response for that case does not come via jsonCode
: https://github.com/Expensify/Web-Expensify/blob/30edfabd582f9ac70ec59cef3172a5bf25657efa/api.php#L2761-L2766
Maybe we can add a parameter that indicates if this call to the Middleware is coming from a failed retry request or not? Maybe checking the retryCount? Or check the HTTP response code somehow? The original issue was that if a request was a failed retry (i.e. could not connect to the Server), we'd have no responseData
and thus get an undefined error.
However I don't really think this case matters too much right? Why would we want to support error messages for non-existent API commands? We shouldn't be calling non-existent API commands in the production App ever, right? Any "feedback in the UI" would solely be serving developers and that's it, no?
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.
However I don't really think this case matters too much right? Why would we want to support error messages for non-existent API commands? We shouldn't be calling non-existent API commands in the production App ever, right? Any "feedback in the UI" would solely be serving developers and that's it, no?
I completely agree that this doesn't matter if it only happens when a command doesn't exist, but I had my doubt if this could happen with other crashes like and exception being thrown. I'll test and let you know.
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, retested throwing an exception in the web API, we get a jsonCode = 666
, responseData
is not undefined, and the failureData
is applied correctly. I think this is the case that matters and works fine.. so lets do nothing :)
@marcaaron, @neil-marcellini please review
HOLD ON https://github.com/Expensify/Web-Expensify/pull/34119
Details
Keeps the functionality pretty much the same, however, we now show a confirmation screen upon successfully requesting a call as opposed to a Growl.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/213428
Tests/QA
1243
PR Review Checklist
Contributor (PR Author) Checklist
### Fixed Issues
section aboveTests
sectionQA steps
sectiontoggleReport
and notonIconClick
)src/languages/*
filesSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)/** comment above it */
displayName
propertythis
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)PR Reviewer Checklist
### Fixed Issues
section aboveTests
sectionQA steps
sectiontoggleReport
and notonIconClick
).src/languages/*
filesSTYLE.md
) were followed/** comment above it */
displayName
propertythis
properly so there are no scoping issues (i.e. foronClick={this.submit}
the methodthis.submit
should be bound tothis
in the constructor)this
are necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);
ifthis.submit
is never passed to a component event handler likeonClick
)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Screenshots
Web
Kapture.2022-06-27.at.16.32.40.mp4
Mobile Web
Kapture.2022-06-27.at.16.49.03.mp4
Desktop
Kapture.2022-06-27.at.16.35.53.mp4
iOS
Kapture.2022-06-27.at.17.28.08.mp4
Android