Fix: Settings page: remove code preventing rendering before currentUserPersonalDetails is ready #22329
Conversation
|
@aimane-chnaif 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] |
Reviewer Checklist
Screenshots/VideosWebMobile Web - ChromeMobile Web - SafariDesktopdesktop.moviOS
Android |
| const avatarPlaceholderSize = StyleUtils.getAvatarSize(CONST.AVATAR_SIZE.LARGE); | ||
| const avatarPlaceholderRadius = avatarPlaceholderSize / 2; | ||
| const headlineMarginTop = 16; | ||
| const headlineSize = variables.fontSizeXLarge; |
There was a problem hiding this comment.
desktop.mov
There's a little height difference because height of TextView is actually lineHeight, not fontSize.
The correct height should be variables.lineHeightXXLarge.
But according to #18569 (comment), I am not too much concerned about this inconsistency and this is not a blocker.
There was a problem hiding this comment.
I think there's enough of a height difference that we should address it.
The skeleton has a height of 155:
And once loaded it's 162:
Furthermore, const headlineMarginTop = 16; and const labelMarginTop = 4; are kind of "magic" numbers at the moment and could get out of sync if we were to change the styles of the real components.
I think it'd be better to replace these 2 with something more precise, e.g. instead of headlineMarginTop, do something like:
const spaceBetweenAvatarAndHeadline = styles.mb3.marginBottom + styles.mt1.marginTop + ((variables.lineHeightXXLarge - variables.fontSizeXLarge)/ 2);
and then similarly for labelMarginTop, with some comments explaining the calculations.
Thoughts?
There was a problem hiding this comment.
I think there's enough of a height difference that we should address it.
The reason why I didn't persist to fix this because we don't know exact height of TextView when lineHeight is not set. fontSize itself cannot determine the height. i.e. textLabelSupporting. Dynamic calculation (i.e. onLayout callback) is the only way. Or set lineHeight for this purpose, which will change design.
I think it'd be better to replace these 2 with something more precise, e.g. instead of
headlineMarginTop, do something like:
I also thought about that but that code feels like unused pattern in our codebase. But I don't see any harm with this and so agree with suggestion.
| const avatarPlaceholderSize = StyleUtils.getAvatarSize(CONST.AVATAR_SIZE.LARGE); | ||
| const avatarPlaceholderRadius = avatarPlaceholderSize / 2; | ||
| const headlineMarginTop = 16; | ||
| const headlineSize = variables.fontSizeXLarge; |
There was a problem hiding this comment.
I think there's enough of a height difference that we should address it.
The skeleton has a height of 155:
And once loaded it's 162:
Furthermore, const headlineMarginTop = 16; and const labelMarginTop = 4; are kind of "magic" numbers at the moment and could get out of sync if we were to change the styles of the real components.
I think it'd be better to replace these 2 with something more precise, e.g. instead of headlineMarginTop, do something like:
const spaceBetweenAvatarAndHeadline = styles.mb3.marginBottom + styles.mt1.marginTop + ((variables.lineHeightXXLarge - variables.fontSizeXLarge)/ 2);
and then similarly for labelMarginTop, with some comments explaining the calculations.
Thoughts?
|
@amyevans sounds good, I'm implementing it. |
kowczarz
force-pushed
the
fix/18569-settings-page-remove-code-blocking-rendering
branch
from
002c8f4 to
1529447
Compare
There was a problem hiding this comment.
Looks good! Going to merge since @aimane-chnaif has already approved
|
✋ 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/amyevans in version: 1.3.41-0 🚀
|
|
🚀 Deployed to production by https://github.com/Julesssss in version: 1.3.41-3 🚀
|
|
🚀 Deployed to staging by https://github.com/amyevans in version: 1.3.42-0 🚀
|
|
🚀 Deployed to production by https://github.com/Julesssss in version: 1.3.41-3 🚀
|
|
🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.3.42-26 🚀
|
Details
I removed the code that previously prevented the Settings screen from rendering before currentUserPersonalDetails was ready.
Fixed Issues
$ #18569
PROPOSAL: #18569(COMMENT)
Tests
Offline tests
Same as above
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)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)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
Web
web.mov
Mobile Web - Chrome
android.web.mov
Mobile Web - Safari
iOS.web.mp4
Desktop
desktop.mov
iOS
iOS.native.mp4
Android
android.native.mov