Skip to content
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

#6547 add continious deletion of IOU amount on long press #6626

Merged
merged 15 commits into from
Dec 13, 2021

Conversation

dklymenk
Copy link
Contributor

@dklymenk dklymenk commented Dec 7, 2021

Details

This PR adds a long press handler to delete button on mobile numpad that starts continuous deletion of characters until it is released.

Fixed Issues

$ #6547

Tests / QA Steps

  1. Navigate to a conversation
  2. Start the Request money flow
  3. Type some amount with several digits
  4. Press and hold the delete button (or Backspace key on web and desktop)
  5. The amount should be continuously deleted until the key is released

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web

Mobile Web

Simulator.Screen.Recording.-.iPhone.12.-.2021-12-08.at.12.02.18.mp4

Desktop

iOS

Simulator_Screen_Recording_iPhone_12_2021_12_07_at_22_05_53.mp4

Android

6547-android.mp4

@dklymenk dklymenk marked this pull request as ready for review December 8, 2021 09:07
@dklymenk dklymenk requested a review from a team as a code owner December 8, 2021 09:07
@MelvinBot MelvinBot removed the request for review from a team December 8, 2021 09:07
@dklymenk
Copy link
Contributor Author

dklymenk commented Dec 8, 2021

Applied the changes suggested by @parasharrajat

parasharrajat
parasharrajat previously approved these changes Dec 8, 2021
Copy link
Member

@parasharrajat parasharrajat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM and tests well.

All yours @iwiznia

*
* @param {String} key
*/
handleLongPressNumberPad(key) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm shouldn't all this logic be on the BigNumberPad component? Do we expect any BigNumberPad were we don't want long presses to work? I would think we always want this behavior, so reimplementing it on each caller sounds worse than just incorporating it to that component.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I was thinking the same but had doubts.

Copy link
Member

@parasharrajat parasharrajat Dec 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, my point was Continues keypress event timer logic should be inside the BigNumberPad. This callback should just be doing side-effect.

So that each key reflect the same behaviour and we can choose to execute only on < for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that component doesn't have any state itself, it is simply responsible to passing the callbacks to the buttons.

Or do you think we should pass some 'deleteSingleChar' prop to the number pad and call it with setInterval inside the BigNumberPad?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, so you just need to trigger the passed callback as you do now. But longPress will trigger that multiple times.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I got you. There is no need for a new prop, I need to call the one that is already used for single press. 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@parasharrajat @iwiznia
I have updated the PR with the change you requested, please review.

Copy link
Member

@parasharrajat parasharrajat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dklymenk
Copy link
Contributor Author

dklymenk commented Dec 9, 2021

Do not follow StyleGuide. Please have a read of https://github.com/Expensify/App/blob/main/STYLING.md and https://github.com/Expensify/App/blob/main/STYLE.md.

Do you want me to rewrite the component as class component? Before committing I have checked for usages of useState in the app and found at least one component that uses it, so it didn't seem like I am breaking the rules.

Anyway, just let me know if that's what you meant. I am slightly confused by you referencing the styling doc where this PR doesn't touch any styles whatsoever.

Thanks.

@parasharrajat
Copy link
Member

parasharrajat commented Dec 9, 2021

Do you want me to rewrite the component as class component? Before committing I have checked for usages of useState in the app and found at least one component that uses it, so it didn't seem like I am breaking the rules.

Yeah, this should be converted to the class component. You should follow styleGuide as much as possible. Exceptions could be made but do you think that is necessary here. I am sure you read the comment on the component

// Do not convert to class component! It's been tried before and presents more challenges than it's worth.
.

@dklymenk
Copy link
Contributor Author

dklymenk commented Dec 9, 2021

Ah, no. I missed that comment, sorry. I will try to update the BigNumberPad to use React.Component.

Thank you.

@dklymenk
Copy link
Contributor Author

Updated PR with requested change: rewrite BigNumberPad as class component. Please review. @parasharrajat @iwiznia

Comment on lines +36 to +38
if (key !== '<') {
return;
}
Copy link
Member

@parasharrajat parasharrajat Dec 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be part of BigNumberPad. This should be handled in the parent component. The only job of this method should be to call the long press callback on time intervals emitting continuous long-press.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but I don't quite understand. There is no more long press callback in that context. I think we have agreed that this entire logic should be moved to BigNumberPad component.

I have just reread the thread above and @iwiznia clearly says "shouldn't all this logic be on the BigNumberPad component". If we are to do

        if (key !== '<') {
            return;
        }

inside parent component we would need to also pass some new arg to callback to indicate that the keyPress was started by the timer. And overall moving it to parent component would mean that we'll have timers on every button and not just the <.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @dklymenk, not sure why would anyone want to handle the long presses differently. But even if at some point we do want that, we can extract the logic then.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I give it a go for now. I still feel that all keys should have the same behaviour irrespective of the Key. If we only want to handle long-press for < then it should be a parent to control that.

dklymenk and others added 2 commits December 10, 2021 13:18
@iwiznia
Copy link
Contributor

iwiznia commented Dec 10, 2021

I think this solution is good, but will let @parasharrajat merge or keep engaging on the discussion above.

Copy link
Member

@parasharrajat parasharrajat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. we are good to merge @iwiznia .

@iwiznia iwiznia merged commit aae379c into Expensify:main Dec 13, 2021
@OSBotify
Copy link
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @iwiznia in version: 1.1.20-3 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 failure ❌
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

🚀 Deployed to production by @Julesssss in version: 1.1.21-1 🚀

platform result
🤖 android 🤖 failure ❌
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants