refactor: extract queue-derived pending-request state into PendingRequests module#96040
Conversation
adhorodyski
left a comment
There was a problem hiding this comment.
I think it's not really NIT but the naming could be improved for the pending stuff module.
|
@DylanDylann 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] |
|
@codex review |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
…moization parity across compilers
|
No product review needed. |
|
|
||
| return !!hasRelevantPersistedRequests || !!hasRelevantOngoingRequest; | ||
| } | ||
| export default useLoadingBarVisibility; |
There was a problem hiding this comment.
I would not reexport, but either put the implementation (that uses internals) directly there OR use the module itself. This file seems redundant then.
There was a problem hiding this comment.
Good call. Removed the re-export file and pointed the four consumers straight at the module (import {useLoadingBarVisibility} from '@hooks/useInFlightRequests'). Putting the implementation back in its own file is what reintroduced the compiler memoization divergence, so keeping it in the module is the way.
adhorodyski
left a comment
There was a problem hiding this comment.
NIT only, this is fine I think
…t from the module directly
…quests-module # Conflicts: # Mobile-Expensify
Reviewer Checklist
Screenshots/VideosMacOS: Chrome / SafariScreen.Recording.2026-07-16.at.17.17.05.mov |
|
🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
✋ 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/mountiny in version: 9.4.36-0 🚀
|
|
🤖 I reviewed the changes in this PR against Expensify's help site content under No help site changes are required. This PR is a purely internal code refactor. It extracts the queue-derived pending-request logic into a new There are no user-facing changes here — no new UI, settings, feature names, tab labels, or buttons, and no change to any documented behavior. The help site articles document customer-facing product functionality, so nothing in If a later PR in this series surfaces a user-visible behavior change, that would be the point to revisit the help site. |
Explanation of Change
Loading indicators that read from a stored boolean flag can get stuck on forever if the write that clears the flag is lost, for example when the app closes or reloads in the gap between a request finishing and the flag being cleared. The LoadingBar avoids this today by deriving its visibility straight from the request queue instead: a request is always removed from the queue when it resolves, so there is no separate flag that can go stale.
This PR extracts that pattern into
src/libs/PendingRequests, a module that answers "is a request of this kind currently in flight?" by reading the two Onyx keys behind the queue (PERSISTED_REQUESTSandPERSISTED_ONGOING_REQUESTS). It defines three command groups (app load, report load scoped byreportID, and the LoadingBar's own command set) and exposes one hook per group:useIsAppLoadPending(),useIsReportLoadPending(reportID), anduseIsLoadingBarPending(). No new Onyx writes or connections are added.useLoadingBarVisibilityis refactored to calluseIsLoadingBarPending()instead of keeping its own copy of the selectors. The behavior is unchanged, including the asymmetric offline filter (a persisted request initiated while offline does not count as pending, but the ongoing request always does).The other two hooks are not consumed yet. They exist so later PRs can move loading and skeleton gates that currently rely on stored flags onto the same queue-derived pattern, one call site at a time.
Fixed Issues
$ #96060
PROPOSAL:
Tests
Offline tests
QA Steps
Same as tests
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari