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

Fix: input alignment & error border for input #5805

Merged
merged 29 commits into from
Nov 30, 2021

Conversation

parasharrajat
Copy link
Member

@parasharrajat parasharrajat commented Oct 13, 2021

Details

Follow up #5742.

  1. I have removed the manual translation from the label on ExpensiInput. Previously, It was required to pass custom translateX prop based on the label length. It was hectic and error-prone.

Fixed Issues

$ #5462

Tests | QA Steps

  1. Label and value alignment should be correct for input and Select input.
  2. When a field has an error it should show a red border.

Tested On

  • Web
  • Mobile Web
  • Desktop
  • iOS
  • Android

Screenshots

Web | Mobile Web | Desktop

Screenshot 2021-10-15 at 02-43-50 New Expensify

iOS

Screenshot 2021-10-15 02:44:18

Android

Screenshot 2021-10-15 02:43:26

@parasharrajat parasharrajat requested a review from a team as a code owner October 13, 2021 14:58
@MelvinBot MelvinBot requested review from MariaHCD and removed request for a team October 13, 2021 14:59
@parasharrajat parasharrajat changed the title fix: input alignment & error border for input [WIP] Fix: input alignment & error border for input Oct 13, 2021
@parasharrajat
Copy link
Member Author

cc @shawnborton. I will update the screens shortly.

@parasharrajat parasharrajat mentioned this pull request Oct 13, 2021
5 tasks
Copy link
Contributor

@aldo-expensify aldo-expensify left a comment

Choose a reason for hiding this comment

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

The "focus" border can apply at the same time as the red outline, which looks weird. I think it should be just one border:

Screen Shot 2021-10-13 at 9 37 43 AM

@parasharrajat
Copy link
Member Author

Strange, I did tested that. Let me check again.

@aldo-expensify
Copy link
Contributor

Strange, I did tested that. Let me check again.

My guess is that you may still be applying it to the outer container. The "focus" border looks extra thick for the ExpensiPicker

Screen Shot 2021-10-13 at 9 46 13 AM

meanwhile, for other inputs, it looks thinner:

Screen Shot 2021-10-13 at 9 47 19 AM

@parasharrajat
Copy link
Member Author

Done.

@aldo-expensify
Copy link
Contributor

Done.

Tested it again in web/android, it is looking good.

Is this still WIP?

@shawnborton
Copy link
Contributor

I think we want to keep the :focus styles for accessibility purposes right?

@shawnborton
Copy link
Contributor

But that being said, maybe we want the :focus style on an input with an error border to look different? It seems like a pretty standard :focus outline is to take the :focus color, reduce the opacity, and apply it as a thicker drop shadow (with no blur) around the input.. GH for example:
image

@shawnborton
Copy link
Contributor

But actually if we just have a better :focus style for inputs, we don't need to worry about making it match the error red border... another example from GH:
image

@parasharrajat parasharrajat changed the title [WIP] Fix: input alignment & error border for input Fix: input alignment & error border for input Oct 13, 2021
@parasharrajat
Copy link
Member Author

Sorry didn't notice the title. I was waiting for Shawn's review.

@parasharrajat
Copy link
Member Author

@shawnborton What do you want me to change here? I didn't get your comments clearly.

@shawnborton
Copy link
Contributor

@parasharrajat in this screenshot here:
image

It feels like the "He/him" is over to the right by 1px too far. Can you inspect that one for me and show me the bounding boxes?

@aldo-expensify
Copy link
Contributor

aldo-expensify commented Oct 13, 2021

But actually if we just have a better :focus style for inputs, we don't need to worry about making it match the error red border... another example from GH: <image>

I agree on that following those styles for focused inputs and errors is the right path, but this may be out of the scope of the original GH issue and the regression this is PR is trying to fix.

@shawnborton
Copy link
Contributor

Fair point @aldo-expensify - let's save these for a separate issue.

@parasharrajat just see my comment above... the first screenshot feels a bit off, but the second screenshot you posted in the first comment seems okay.

@parasharrajat
Copy link
Member Author

@shawnborton I noticed it. Let me check.

paddingBottom: 8,
paddingHorizontal: 11.5,
paddingHorizontal: 12,
Copy link
Contributor

Choose a reason for hiding this comment

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

I thought we discussed changing this to 11?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, I forget that point while figuring out other issues. I will update it.

@parasharrajat
Copy link
Member Author

So there won't be any alignment issues in the future. All inputs are now calculating their own label placement position so I am sure it would be 99.999% perfect.
For outline issues that Aldo mentioned

Please let me know if there is something remaining. This PR thread has so many comments I could have missed some points. But I think fixed all along the way.

I didn't expect that this issue would take this much time as I didn't think the original input implementation has issues and used the wrong props (use of translate props as it is). Now I decided to refactor it.

@shawnborton
Copy link
Contributor

Sounds good to me!

shawnborton
shawnborton previously approved these changes Nov 29, 2021
@parasharrajat
Copy link
Member Author

Maria is in a different time zone. Please give it 🟢 🚦 for merge.

@shawnborton
Copy link
Contributor

I think it's okay if Maria merges this tomorrow once she sees it and gets a chance to review. Thanks for your patience!

@parasharrajat
Copy link
Member Author

@MariaHCD Please review it.

@parasharrajat
Copy link
Member Author

I don't think Maria is available. I see no other reason for holding this. Just not looking for more merge conflicts. cc: @aldo-expensify

@shawnborton
Copy link
Contributor

Yup - looks like Maria is OOO this week, so I think we can go ahead and merge.

@parasharrajat
Copy link
Member Author

Well...well...well. Look what we got here....conflicts 🤦‍♂️

@aldo-expensify
Copy link
Contributor

Well...well...well. Look what we got here....conflicts 🤦‍♂️

:( :( :( :( thanks @parasharrajat , had a laugh with your gif, it was perfect 😆

@aldo-expensify
Copy link
Contributor

I guess we wait for the E2E tests and then merge?

@aldo-expensify
Copy link
Contributor

Merging, @MariaHCD is OOO this week

@aldo-expensify aldo-expensify merged commit eddcc0f into Expensify:main Nov 30, 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

OSBotify commented Dec 7, 2021

🚀 Deployed to staging by @aldo-expensify in version: 1.1.17-8 🚀

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

@OSBotify
Copy link
Contributor

OSBotify commented Dec 8, 2021

🚀 Deployed to production by @roryabraham in version: 1.1.18-3 🚀

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

color: themeColors.text,
height: '100%',
paddingTop: 25,
paddingTop: 23,
Copy link
Member

@rushatgabhane rushatgabhane Mar 21, 2023

Choose a reason for hiding this comment

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

Dropping a friendly note that expensiTextInputLabelBackground has height of 25px.

And expensiTextInput's paddingTop was changed to 23px.

This caused issue - #14674 because the paddingTop and height of the label were misaligned.

image

inputRange: [styleConst.ACTIVE_LABEL_SCALE, styleConst.INACTIVE_LABEL_SCALE],
outputRange: [-(this.state.width - (this.state.width * styleConst.ACTIVE_LABEL_SCALE)) / 2, 0],
}),
this.props.labelScale,
Copy link
Contributor

Choose a reason for hiding this comment

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

Dropping a friendly note that this has caused a regression in #17715.
There is a detailed explanation here, but in short, on Android, onLayout was firing after the screen animation, setting this.state.width and moving thelabel. This resulted in labels jumping horizontally right after the screen animation on Android

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.

6 participants