-
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
#2821 add up arrow to edit feature #3157
#2821 add up arrow to edit feature #3157
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.
Nice, this is looking great and testing well!
All yours @thienlnam |
Object.keys(this.props.reportActions).reverse(), | ||
key => this.props.reportActions[key].actorEmail === this.props.session.email, |
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 this the correct way to do it. You should sort by the sequenceNumber
.
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 can see that report actions are being sorted by sequenceNumber
here:
https://github.com/Expensify/Expensify.cash/blob/9f305176681385f2aa80f43de06fc6dffa7f0b83/src/pages/home/report/ReportActionsView.js#L243-L255
Is this a requirement, however? In my local storage for any ReportActions_<report_id>
sequenceNumber
always matches the key of a report action.
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 do you mean? This code just loops though the reportActions
backwards and finds the first one where the actor email is the current user.
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.
Objects keys are not sequential. so keys' order could be discrete.
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.
All the keys in my localstorage are ordered and identical to sequenceNumber
. If one can't trust this order, I think running sortBy
on entire object for every action trigger would not be very efficient. It would be better to have some storage for sorted list shared with ReportActionsView.js
in that case.
@roryabraham I noticed one thing may be not related to this issue. We can see the edit action on IOU actions but not edit box open for them and this PR will try to follow the same when user will press the |
@parasharrajat Thanks for reviewing! Good point about not filtering out IOU actions! Check out these lines from the So what we should do is:
|
Ok, I see. I do the check for reportActionID, that's enough to avoid editing the newly created message, but I see the need to have a separate function for that since it's such a widely used check. So I create a new file Also since that PR is not merged yet, I can't really "move" the function to separate library, so i'll just add a function and won't touch the original implementation. |
I think |
Agreed, in this PR we can just add a function to |
Updated the PR with change regarding the new function. I also took the liberty of adding the |
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.
Two other suggestions:
- I noticed that you didn't import & use your new function in
ReportActionContextMenu
here. Let's do that to DRY this up. - Instead of using
withOnyx
and passing in thesessionEmail
as a parameter to thecanEditReportAction
function, you could instead useOnyx.connect
directly inreportUtils
to keep a local reference to the current user's email. That way we have one Onyx subscription to theSESSION
key instead of 2+
src/libs/reportUtils.js
Outdated
function canEditReportAction(reportAction, sessionEmail) { | ||
return reportAction.actorEmail === sessionEmail | ||
&& reportAction.reportActionID | ||
&& reportAction.actionName !== 'IOU' |
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.
&& reportAction.actionName !== 'IOU' | |
&& reportAction.actionName === 'ADDCOMMENT' |
Also, you could optionally add a const to CONST.js called REPORT_ACTION.ACTION_TYPES
so that we're not using a string literal here.
Here's an example of what I mean by using Onyx.connect directly in the library function instead of using |
…se Onyx.connect directly in reportUtils + add CONST.REPORT_ACTION + check for ADDCOMMENT
I've applied requested changes. @roryabraham, please check. Thank you. |
src/CONST.js
Outdated
@@ -47,6 +47,7 @@ const CONST = { | |||
TYPE: { | |||
CHAT: 'chat', | |||
IOU: 'iou', | |||
ADDCOMMENT: 'ADDCOMMENT', |
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.
You've created REPORT.TYPE.ADDCOMMENT
here, but we want REPORT.ACTION.TYPE.ADDCOMMENT
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.
sorry, fixed
Fixed 2 merge conflicts. Please make sure this change is ok with you: |
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 broken after your last merge. To fix it, I think you'll need to:
- Remove the
canEdit
member function fromReportActionContextMenu
(including from the constructor) - Replace it's current usage in the
shouldShow
fordeleteComment
with() => canEditReportAction(this.props.reportAction)
Please be careful to retest locally before each new request for review, especially if you had to resolve merge conflicts.
this.canEdit() | ||
&& !isReportMessageAttachment(this.getActionText()) | ||
), | ||
shouldShow: canEditReportAction(this.props.reportAction), |
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.
shouldShow: canEditReportAction(this.props.reportAction), | |
shouldShow: () => canEditReportAction(this.props.reportAction), |
My bad on this one. For some reason I did not think that conflict resolution would break stuff. Applied your suggestions. Thanks. |
@dklymenk Sorry, there are more merge conflicts now 😞 |
Resolved the conflict. Tested. Everything should be ok. |
looks good and tests well 👍 |
@thienlnam All yours for the merge after E2E tests are done 👍 |
Since Jack approved a previous version of this pull request, and I think this might resolve this deploy blocker, I'm going to go ahead and merge this. |
@dklymenk We found this issue in mWeb mWeb - Up arrow not enabled for edit featureExpected ResultThe edit box for your last message should appear. Actual ResultArrow up is disabled and unable to select by tapping Action Performed
PlatformmWeb ✔️ Notes/images/video Bug5094951_Up_arrow.mp4 |
@isagoico Those "arrow keys" on your video are grayed out(inactive,disabled). Tapping them doesn't provide any feedback to user nor does it send any events to browser. Moreover, those are not actually arrow keys. A quick online search told me, that they behave more like Tab and Shit+Tab to jump between inputs on a form. Simulator_Screen_Recording_iPhone_11_2021_06_02_at_08_33_10.mp4I used https://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_submit, but any form with proper html should do the trick. Now I don't have a real iPhone, and to my understanding you cannot install apps from app store on a simulator, so if you can install some third-party full 5 row keyboard from store, try with that and it won't work, I'll try to get my hands on one to fix the issue. @roryabraham The video I showed for mobile web is from video_2021-06-02_09-11-59.mp4test.mp4Hopefully, this clears up the confusion and the issue can be closed again. Thanks. EDIT: I meant "the HOLD for payment can be added back", and not "the issue can be closed again". EDIT2: Corrected the origin of demo mWeb video in the first post of the PR. |
I agree with @dklymenk |
Thanks @dklymenk! |
Details
In addition to solution described in my original proposal, code in this PR should be faster because it doesn't loop over all messages to filter the ones where user is the author, but instead it loops over the list in reverse order and stops on the first matching result.
Please note that this feature is not present on native apps, the same way the shortcut for sending message (Enter/Return key) is not working on native apps.
Fixed Issues
Fixes #2821
Tests / QA Steps
Web and Desktop:
Android and iOS:
Tested On
Screenshots
Web
2021-05-26.09-57-07.mp4
Mobile Web
Simulator.Screen.Recording.-.iPhone.11.-.2021-05-26.at.10.27.42.mp4
Desktop
Screen.Recording.2021-05-26.at.10.33.13.mov
iOS
Android