feat: Add count and spend total selectors to the Spend footer by truph01 · Pull Request #100674 · Expensify/App

truph01 · 2026-09-09T04:35:14Z

Explanation of Change

Adds the count and spend total selectors to the Spend footer, alongside the existing currency one, all three in a single display menu opened from the footer.

footerCount, footerTotal and footerCurrency are new search filters, so each selection persists with the search. Only footerTotal enters the query hash, since only it changes what the backend returns.
Count switches between the expense and report counts. Both already come back on every search, so it applies with no round trip.
Total offers Spend, Reimbursable, Non-reimbursable, Billable and Non-billable. With no selection the backend swaps the aggregate into search.total and the total shows a skeleton while it loads. With rows selected it is summed on the client from those rows.

Fixed Issues

$ #99452
PROPOSAL:

Tests

Go to Spend > Expenses > Choose any rows > Verify the footer shows a count, a total and a chevron.
Open the chevron. Verify rows for Count, Total and Currency.
Count > Reports > Apply. Verify the footer reads Reports: X.
Total > Reimbursable > Apply. Verify the total shows a reimbursable figure.

Verify that no errors appear in the JS console

Offline tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."
Same as tests

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

…the Spend footer

melvin-bot · 2026-09-09T04:35:20Z

Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

Look at the code and make sure there are no malicious changes.
Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx bun ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx bun ./scripts/generateTranslations.ts --compare-ref main

codecov · 2026-09-09T04:39:27Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/CONST/index.ts	`95.79% <ø> (ø)`
src/components/Search/SearchResultsProvider.tsx	`100.00% <100.00%> (ø)`
src/components/Search/index.tsx	`71.37% <100.00%> (+0.11%)`	⬆️
src/hooks/useSearchBulkActions.ts	`76.51% <100.00%> (ø)`
src/hooks/useSearchPageSetup.ts	`97.61% <100.00%> (+0.25%)`	⬆️
src/libs/SearchAutocompleteUtils.ts	`63.50% <100.00%> (+1.32%)`	⬆️
src/libs/SearchParser/searchParser.js	`85.31% <100.00%> (+0.30%)`	⬆️
src/libs/SearchQueryUtils.ts	`89.84% <100.00%> (+0.32%)`	⬆️
src/libs/SearchUIUtils.ts	`72.40% <100.00%> (+0.14%)`	⬆️
src/libs/actions/IOU/SearchUpdate.ts	`93.93% <100.00%> (ø)`
... and 10 more
... and 10 files with indirect coverage changes

melvin-bot · 2026-09-17T05:45:19Z

@mkhutornyi 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]

mkhutornyi · 2026-09-28T21:13:34Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

mkhutornyi · 2026-09-28T21:14:55Z

Please fix conflict

JS00001 · 2026-09-28T21:16:12Z

Bunch of conflicts @truph01

MelvinBot · 2026-09-28T21:40:26Z

Regression review at `a6cae54`

I found 2 new regressions from the latest commits. Four earlier findings are also still present. I read the code only: the live web session was blank before I could sign in, so none of this was reproduced in the app.

🟠 New since the last review

Changing Total (with nothing selected, or with select-all) replaces the whole list with the loading skeleton.
- SearchSelectionFooter.tsx:583-586 says "the page is told first so the rows stay on screen". No code does that anymore.
- SearchPage keeps the old rows only for a query marked with markQueryAsRefinement (SearchPage.tsx:144-148). 23d1b0f imported it and a6cae54 removed the unused import, so it is never called.
- Result: the new hash has no snapshot, so the list unmounts to SearchLoadingSkeleton. The footer returns null while metadata.count is empty, so your total skeleton never shows. After the remount, rows ticked outside the first loaded page may drop out of the selection (not verified in the app).
- Fix: call markQueryAsRefinement(nextQuery) in applyFooterSelection. Also pass the held metadata to the footer: it gets searchResults, not contentSearchResults.
To-do and grouped searches can show a blank "Reports:". a95a916 removed the typeof metadataReportCount === 'number' guard from shouldShowCountSelector. The comment above it still describes that guard.
- Submit, Approve, Pay and Export default to Reports. Their count comes from the stored server snapshot, not live Onyx data. So it is blank until the first response and while offline, and it doesn't update as you act on reports.
- Count → Reports on a grouped search reads the server's reportCount, which your earlier type comment said is absent there. I didn't confirm the backend response.

🟡 Still present from earlier reviews

Footer keys still count as filters. Picking any footer option changes existing behavior, and the menu has no way to remove the keys again:
- isDefaultExpensesQuery / isDefaultExpenseReportsQuery return false, so the strict default columns and the default empty state turn off.
- SearchUpdate.ts:99-106: an expense created offline no longer appears optimistically on type:expense footer-currency:EUR.
- The keys are missing from SKIPPED_SEARCH_FILTERS, so narrow layouts get the filter-bar top padding with no chips.
Switching back to "Total spend" writes footerTotal:total (SearchQueryUtils.ts:724-733). It enters the hash at :982-985, so you get a new snapshot, another request, and regression 1 again. Leave out default values.
The report count is wrong for part of a selection (:718-724). On a Reports search, ticking 1 of a report's 3 expenses shows "Reports: 0" beside a non-zero total. After select-all, unticking a report leaves the server's reportCount unchanged.
footerCurrency isn't checked against the currency list (:709). footer-currency:xyz requests a conversion to a currency that doesn't exist.

The Non-reimbursable crash, merge conflicts, and what checked clean

Crash: I found no remaining front-end crash path. 41d5498 fixed the likely cause (data[ → data?.[ in useSearchBulkActions.ts). But the reviewer's second report came from the adhoc build of exactly a6cae54 (run 36249744041), so a stale cache is unlikely. One path fits "consistent, survives a refresh": if Auth errors on footerTotal:non-reimbursable, Search shows its error view. The footer disappears with it, and footerTotal stays in the URL. A stack trace, or a note on which error screen appeared, would settle it.

Conflicts: 9 files conflict, all with [NoQA] [Insights] Add compare root key to search grammar. They are list additions: keep both sides, then regenerate searchParser.js and autocompleteParser.js from the merged .peggy files. Nothing on main changes the PR's approach.

Checked clean:

Queries without footer keys hash exactly as before, so saved searches and cached snapshots still match.
With no footerTotal, to-do totals from useTodoSearchResults match main.
The refetch skeleton (isLoading && offset === 0) is restored.
A footer-only change no longer clears the selection in useSearchPageSetup.
All translation keys exist in every locale.

Reply with @MelvinBot <feedback> to discuss any item.

view run · no recording available

truph01 · 2026-09-29T03:39:55Z

Changing Total (with nothing selected, or with select-all) replaces the whole list with the loading skeleton.

To-do and grouped searches can show a blank "Reports:". a95a916 removed the typeof metadataReportCount === 'number' guard from shouldShowCountSelector. The comment above it still describes that guard.

Resolved via a0430da

truph01 · 2026-09-29T04:42:22Z

Resolved

Footer keys still count as filters. Picking any footer option changes existing behavior, and the menu has no way to remove the keys again:

Switching back to "Total spend" writes footerTotal:total (SearchQueryUtils.ts:724-733). It enters the hash at :982-985, so you get a new snapshot, another request, and regression 1 again. Leave out default values.

Unable to reproduce:

The report count is wrong for part of a selection (:718-724). On a Reports search, ticking 1 of a report's 3 expenses shows "Reports: 0" beside a non-zero total. After select-all, unticking a report leaves the server's reportCount unchanged.

Currencies always come from CurrencyPopup, which only offers codes from the account's list — no free-text entry in the UI. footer-currency:xyz means hand-editing the URL, and the worst case is a stuck total skeleton on that search, cleared by picking any currency.

footerCurrency isn't checked against the currency list (:709). footer-currency:xyz requests a conversion to a currency that doesn't exist.

truph01 · 2026-09-29T04:50:46Z

@mkhutornyi Should we add a beta flag for this issue so QA can test it without needing to revert this PR, since it includes a lot of changes?

mkhutornyi · 2026-09-29T08:48:38Z

@mkhutornyi Should we add a beta flag for this issue so QA can test it without needing to revert this PR, since it includes a lot of changes?

Agree

JmillsExpensify · 2026-09-29T09:54:32Z

Also agree. Let's be careful on this one.

JS00001 · 2026-09-29T12:52:05Z

Yeah we can do a FE beta here, works for me 👍🏻

truph01 · 2026-09-29T16:19:51Z

@mkhutornyi I added beta flag

mkhutornyi · 2026-09-30T05:53:54Z

-                )}
+            <View style={[shouldUseNarrowLayout ? styles.justifyContentStart : styles.justifyContentEnd, styles.flexRow, styles.alignItemsCenter]}>
+                <FilterPopupButton
+                    PopoverComponent={renderFooterPopup}


Changing the footer currency now takes an extra step for non-beta users

Without the spendFooterSelectors beta, open Spend > Expenses and select 2 expenses.

Press the total in the footer.

Expected: the currency list, as on production.
Actual: a one-row menu reading "Currency", which has to be pressed to reach the list. The whole footer row, including "Expenses: 2", is also now the press target for non-beta users.

Gate the menu on the beta too, falling back to CurrencyPopup when it is off

Screen.Recording.2026-09-29.at.10.51.34.PM.mov

mkhutornyi · 2026-09-30T06:29:04Z

Bug: sometimes footer disappears (00:04s) or selection is cleared (00:19s) when select Total

Reporting because not reproducible when change Currency

Screen.Recording.2026-09-30.at.9.25.07.AM.mov

mkhutornyi · 2026-09-30T06:37:50Z

Bug: On Drafts tab, footer Total switch stays on the skeleton forever

Screen.Recording.2026-09-30.at.9.36.38.AM.mov

MelvinBot · 2026-09-30T06:39:33Z

Fresh regression review at `f51b7a3`

I found 2 regressions that reach users without the spendFooterSelectors beta, and 6 bugs for beta users. Everything comes from reading the code, except the non-beta footer menu, which I reproduced on web.

🔴 Without the beta (ships to everyone)

The footer UI has no beta gate. The gate only covers the data in SearchSelectionFooter. SearchPageFooter.tsx:155-217 always renders the new single button and SearchFooterPopup. This confirms mkhutornyi's inline comment, and it causes more than the extra step:
- Pressing the total, or "Expenses: 2", opens a menu with one "Currency" row (SearchFooterPopup.tsx:111-118). The currency list only opens after a second press, and it now has a back button. Reproduced on web.
- The dropdown also shows when there's no total (hasTotal at :174 now hides only the amount).
- While the total loads, the button stays pressable, and the Currency row is inert (interactive={!isTotalLoading}), so the menu leads nowhere. The labels also shift sideways around the fixed-width skeleton bar.
- Offline, the whole row dims to 50%, not just the amount.
- Fix: when the beta is off, render the footer as main does, with CurrencyPopup directly on the amount.
Footer keys are still parsed, hashed and applied for users without the beta. If a non-beta user opens a shared link or saved search with footer-total:reimbursable, they get a separate snapshot. The breakdown figure then shows under the "Total spend" label, because totalType is undefined (SearchPageFooter.tsx:143-144). On to-do searches the total is filtered on the client with no beta check (SearchResultsProvider.tsx:52-53). Fix: ignore footer keys in the provider and hash when the beta is off.

Web evidence (account without the beta)

Currency conversion still works ($30.00 → €26.46), footer-currency stays out of the search bar, and the router shows no footer autocomplete suggestions.

🟠 With the beta

Changing Total still clears the selection once the new results arrive. a0430da keeps the old rows on screen, but Search isn't remounted. Its cleanup at Search/index.tsx:586-598 then sees the held hash differ from currentSearchHash, so it clears the selection and exits selection mode.
- Repro: tick 3 expenses → Total → Billable. The subtotal shows, then the selection and the bulk bar vanish when the search returns.
To-do searches get stuck on the skeleton after a Total change. The footer-only hold at SearchPage.tsx:157-169 has no timeout. Nothing requests the new hash for live data (useSearchPageSetup.ts:93), and live results carry hash: 0 (SearchResultsProvider.tsx:61), so the query never resolves.
- Repro: Spend > Approve → Total → Reimbursable. The total skeleton never ends, and the list freezes on the old data.
Rows go missing after paging. Search keeps its old offset, so when the hold ends it requests the new query at that offset (index.tsx:505-512). Load 3 pages, then change Total: rows 51–100 never load.
onlyFromFilter still counts footer keys (SearchUpdate.ts:110). bdd82b0 fixed hasNoFlatFilters but missed this line. On "My expenses" (from:me) with a footer currency, a new offline expense doesn't appear.
Selecting whole groups shows "Total spend" over the breakdown figure. Group selection hides both selectors, so the label falls back to "Total spend" while the amount is still the footerTotal:billable aggregate (SearchSelectionFooter.tsx:324-338).
The report count ignores exclusions under select-all (SearchSelectionFooter.tsx:734). Reports > select all > untick one report: "Reports: N" stays the same while the expense count and total drop.

Lower severity, the crash, and what checked clean

Lower:

With select-all, an excluded report, a custom currency and a non-default Total, each excluded report's full converted total is subtracted, not just the matching part (SearchSelectionFooter.tsx:656-657). The total can go negative.
The Total selector has no type check (:338), so it appears on invoice and trip searches with a selection.
Sorting during a hold uses the held query, which silently drops the new Total.

Crash: I found no remaining front-end crash on the Total-change path. 41d5498 fixed the likely cause (data[ → data?.[ in useSearchBulkActions). If the backend rejects a footerTotal value, Search shows its error screen, and footerTotal stays in the URL. That would fit a "crash" that survives a refresh. A console stack trace would settle it.

Fix verdicts:

1371ca6 is correct. footerTotal:total is left out of the query and the hash.
bdd82b0 is correct except for Convert the store to using promises #6.
a0430da only partly works: the rows stay, but Add Expensify eslint #3–Fix babel build on master #5 remain.

Checked clean: queries without footer keys hash exactly as before. Recent and similar hashes exclude footer keys. Currency conversion for non-beta users matches main. The to-do total math in useTodoSearchResults is correct. Translations exist in every locale.

Reply with @MelvinBot <feedback> to discuss any item.

view run · no recording available

truph01 · 2026-10-01T06:56:31Z

Bug: sometimes footer disappears (00:04s) or selection is cleared (00:19s) when select Total

I fixed it via 1241b3c

mkhutornyi · 2026-10-01T07:40:07Z

One more potential bug not mentioned by Melvin:

Bug: selection is still cleared after a Total switch when the selected expenses are beyond the first page (root cause might be same as Melvin's #5 bug)

Precondition: spendFooterSelectors beta enabled, account with more than 50 expenses.

Go to Spend > Expenses.
Scroll down until more expenses load (past the first 50).
Select two expenses from the newly loaded ones, below the first 50.
Click the chevron in the footer.
Click Total > Billable > Apply.

Expected: Both expenses stay selected and the footer shows their billable total.
Actual: The selection is cleared and the footer and bulk actions disappear once the search finishes loading. If expenses from both pages are selected, only the ones in the first 50 stay selected.

truph01 added 3 commits September 9, 2026 10:20

feat: add footerCount, footerTotal and footerCurrency query keys for …

6afbc11

…the Spend footer

feat: add the count selector to the Spend footer

29c3230

feat: add the count and spend total selectors to the Spend footer

510bcb1

melvin-bot Bot assigned truph01 Sep 9, 2026

truph01 added 4 commits September 11, 2026 09:29

fix: conflicts

e9a0dde

fix: conflicts

94dd759

fix: typecheck

493916d

fix: move the footer selections into the query filters the backend reads

c888775

truph01 mentioned this pull request Sep 11, 2026

Add count and spend total selectors to the Spend footer to let customers choose the data they see #99452

Open

truph01 added 4 commits September 11, 2026 23:26

fix: conflicts

45dbf72

fix: conflicts

4c98c49

fix: conflicts

15789f3

fix: reduce scope of this PR

f53a2ac

truph01 marked this pull request as ready for review September 17, 2026 05:45

truph01 requested review from a team as code owners September 17, 2026 05:45

melvin-bot Bot requested review from JmillsExpensify and mkhutornyi and removed request for a team September 17, 2026 05:45

melvin-bot Bot removed the request for review from a team September 17, 2026 05:45

github-actions Bot reviewed Sep 17, 2026

View reviewed changes