-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Remove unnecessary calls to OpenPrivatePersonalDetailsPage #37047
Conversation
useEffect(() => { | ||
const personalDetails = PersonalDetails.getPrivatePersonalDetails(); | ||
// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing | ||
if (network?.isOffline || (Boolean(personalDetails) && personalDetails?.isLoading !== undefined)) { | ||
return; | ||
} | ||
|
||
PersonalDetails.openPersonalDetails(); |
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. Remove leftovers PersonalDetails.getPrivatePersonalDetails
and PersonalDetails.openPersonalDetails
.
))} | ||
</> | ||
)} | ||
<> |
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. Remove react fragment
Deep linking into forms that relay on private personal details do not work correctly since default values are taken into consideration only on the first render Screen.Recording.2024-02-21.at.10.06.33.PM.mov |
Reviewer Checklist
Screenshots/VideosMacOS: Chrome / Safariweb.mov |
@s77rt I fixed the deep linking bug |
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.
@s77rt Im wondering about leaving this hook/function instead of deleting it for later if we need to load confidential data for some reason. What do you think? Or should we just add this back when we later need it
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.
We should just add it back when needed. It's always best to avoid unnecessary code hanging in the code base. FWIW I don't think we would ever need this hook again since we will always have the private data on OpenApp
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.
Although, I realize that currently logged in users wont have the data unless they log out and back in / reconnect
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.
Oh right! This is a breaking change for logged users. But it's a temporarily issue. Can we maybe send pusher events to all users to get their private 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.
@grgia Was there any discussion regarding this issue? or whether it's a blocker?
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'm not sure if it makes sense to keep the call for one page only, it may be better to do nothing and close the PR. However I'm inclined to remove the redundancy. I just realized something, how can a user upgrade the app and not call OpenApp
?
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 that's a good point. @marcaaron mind if I ask for your expertise here?
Essentially, we've added the privatePersonalDetails to openApp, so there's no need to send them on these pages. However, we're concerned that this is a breaking change for users until openApp is called when they log in / out. Is this something I need to worry about?
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.
@grgia can you help me understand the consequences of showing the stale data to the affected users?
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.
@marcaaron we didn't use to store these private personal details in ONYX, now we do via Open App. So any users who havent logged in yet or called OpenApp in awhile wouldnt have the data in ONYX to access.
So the question is, do we keep a call to the API 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.
Hmm I don't feel too passionate. It feels like we can remove it? Unless something major will break I would treat it as a minor bug affecting older app versions. We are going to force upgrade users to use a new version of the app eventually which should trigger an OpenApp call (at least in the case of native apps).
Tests well. @grgia Can you please complete the checklist? |
For the failing test, can you try merge |
Failing ts test is effecting all current open PRs (can be ignored) |
Thanks @s77rt for your patience while I was OOO! I'll work on updating this PR |
This comment has been minimized.
This comment has been minimized.
🧪🧪 Use the links below to test this adhoc build on Android, iOS, Desktop, and Web. Happy testing! 🧪🧪 |
@s77rt apologies for the delay on updating this, I've created an ADHOC build for testing |
@grgia Can you check the 2 above comments, they don't seem resolved |
Addressed comments @s77rt |
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.
Looks good!
@marcaaron would you like to review?
No need to block on me! |
✋ 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/grgia in version: 1.4.62-0 🚀
|
1 similar comment
🚀 Deployed to staging by https://github.com/grgia in version: 1.4.62-0 🚀
|
🚀 Deployed to staging by https://github.com/grgia in version: 1.4.62-0 🚀
|
🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.62-17 🚀
|
Details
We now return these details in OpenApp, so I'm removing extra calls to fetch this data.
Fixed Issues
$ #23873
$ #36647
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop