Add Enabled/Disabled status filter to multi-layer tags table

[MelvinBot]

Explanation of Change

Adds an Enabled / Disabled status filter to the multi-layer tags per-list view (WorkspaceViewTagsTable).
Previously this table only had a free-text "Find tag" search, so admins with long tag lists had no way to narrow the table down to just enabled or just disabled tags.

The shared Table component already supports dropdown filtering out of the box via the filters (FilterConfig) + isItemInFilter props (the same mechanism Members and Company Cards use). This table simply never wired them up. Each row already carries an enabled: boolean, so no upstream data changes were needed — this is a pure UI wiring change:

• Added a single-select status filter config (Enabled / Disabled) and an isItemInFilter predicate that matches rows against item.enabled.
• Passed filters and isItemInFilter to the existing <Table>. The filter trigger and selected-filter chip render automatically inside the FilterBar that was already there.
• The filter is gated on shouldShowEnabledColumn (= !hasDependentTags), so it is not offered for dependent multi-layer tags — those intentionally have no per-tag enabled column/toggle. This matches the confirmed design decision on the issue.

Fixed Issues

$ #96965
PROPOSAL: #96965 (comment)

Tests

1. Open a workspace with multi-level (independent) tags.
2. Click any parent tag to see multiple child tags in different states (Enabled and Disabled).
3. Verify that status filter icon (Enabled | Disabled) is shown next to the "Find tag" search box.
4. Verify that you are able to filter the list to display only enabled or disabled tags.

• Verify that no errors appear in the JS console

Offline tests

Same as Tests

QA Steps

Same as Tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover 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 tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (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 followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• 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 new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• 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.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user 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 verified that similar component doesn't exist in the codebase
• I verified that all props are defined accurately and each prop has a /** comment above it */
• I verified that each file is named correctly
• I verified that each component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
• I verified that the only data being stored in component state is data necessary for rendering and nothing else
• In component if we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
• 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)
• I verified that component 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)
• I verified that all JSX used for rendering exists in the render method
• I verified that each 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

[codecov]

Codecov Report

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

Files with missing lines	Coverage Δ
...components/Tables/WorkspaceViewTagsTable/index.tsx	83.72% <92.85%> (+83.72%)	⬆️
... and 19 files with indirect coverage changes

[mkhutornyi]

@codex review

[mkhutornyi]

@MelvinBot review

[MelvinBot]

There's nothing for me to fix here — no code-related check is failing.

Only failing check: PR Author Checklist / checklist. It fails because the checklist boxes aren't ticked (0 out of 38 checklist items completed), not because of a code problem. That's a manual step for the PR author — please check every box in the description to clear it. I intentionally don't fill out the author checklist on your behalf.

All substantive checks are green, including typecheck, Bun tests, ESLint check, Oxfmt check, React Compiler Compliance, and the builds. I verified the new filter symbols this PR uses all resolve correctly:

• FilterConfig, IsItemInFilterCallback are exported from src/components/Table/types.ts and the filters/isItemInFilter props are accepted by Table.tsx.
• CONST.TABLES.FILTER_TYPE.SINGLE_SELECT exists in src/CONST/index.ts.

The baseline-perf-tests / branch-perf-tests jobs were still queued/running at the time of writing — those are performance-comparison jobs, not code checks, so there's nothing for me to push there.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: a6d181005b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

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".

[MelvinBot]

Review

The change is correct and minimal — it wires the shared Table's existing filters + isItemInFilter props into WorkspaceViewTagsTable, exactly as the approved proposal describes. The implementation mirrors the proven WorkspaceCompanyCardsTable pattern (same status / SINGLE_SELECT / Enabled|Disabled shape), so I'm confident in the wiring.

Verified:

• FilterConfig / IsItemInFilterCallback are used correctly; filterValues is the flat per-key value array, and the empty/no-selection case (length === 0) correctly returns all rows so clearing the filter restores the full list.
• Reuses existing translation keys common.status / common.enabled / common.disabled — no new copy added.
• CONST.TABLES.FILTER_TYPE.SINGLE_SELECT is valid. SINGLE_SELECT was the right call over MULTI_SELECT (matches the approved proposal).
• Correctly gated on shouldShowEnabledColumn (= !hasDependentTags), so dependent multi-layer lists — which hide the enabled column/switch — don't get a filter for a status they can't see or toggle. This is the confirmed design decision.

Minor (non-blocking):

1. The filterValues.includes('all') branch in isItemInFilter (index.tsx:80) is dead code — no all option is ever provided in options, so the UI never emits that value. It's harmless and consistent with WorkspaceCompanyCardsTable's defensive pattern, so fine to leave, but it could be dropped for clarity.

2. isItemInFilter is passed unconditionally while filters is conditional (index.tsx:130-131). When filters is undefined the predicate is never invoked, so this is a no-op — no change needed.

3. No unit test was added for this table. The filter middleware itself is well-covered by tests/ui/TableTest.tsx, so behavior is exercised generically, but the approved proposal listed table-specific tests (Enabled shows only enabled, Disabled shows only disabled, dependent list shows no filter). Worth considering adding those to lock in the gating logic, though not a blocker given the framework-level coverage.

Overall this looks good to me. The Tests/QA sections still need the human co-author to fill in and attach the all-platform screenshots before this moves to ready-for-review.

[mkhutornyi]

@MelvinBot "all" filter is needed? Asking because I don't see this in UI. Only "Reset" button.

[MelvinBot]

You're right — it's not needed. The SINGLE_SELECT filter has no "All" option in the UI; clearing is done via the Reset button, which sets filterValues to an empty array, already handled by the filterValues.length === 0 check above. Nothing ever emits an 'all' value, so that branch was dead code (I'd copied it from WorkspaceCompanyCardsTable's defensive pattern).

Removed it in f9808f6.

[MelvinBot]

The only failing checks are the PR Author Checklist and PR Reviewer Checklist — every actual CI check (tests, build, ESLint, typecheck, Storybook, perf, etc.) is passing. ✅

These two "checklist" checks aren't code or CI failures I can fix by pushing a commit. They fail by design and stay red until a human completes them:

• PR Author Checklist → tick the checklist items in the PR description's Author Checklist section.
• PR Reviewer Checklist → gets satisfied once a reviewer runs through the reviewer checklist.

So no code change is needed — the branch itself is green. Once the checklist boxes are filled in, these will pass.

[mkhutornyi]

@MelvinBot add unit test

[MelvinBot]

Nothing has changed since my last comment — the only two red checks are still the PR Author Checklist and PR Reviewer Checklist. Every real CI check (tests, build, ESLint, typecheck, Storybook, perf, spellcheck) passes; the ones showing as pending right now are just re-running after the retrigger, not failing.

These two checklist checks aren't code/CI failures and can't be fixed with a commit — they stay red until a human completes them:

• PR Author Checklist → tick the checklist items in the PR description's Author Checklist section.
• PR Reviewer Checklist → satisfied once a reviewer completes the reviewer checklist.

So there's no fix for me to push — the branch is green.

[MelvinBot]

Still the same situation — the only failing checks are PR Author Checklist and PR Reviewer Checklist. Every real CI check (tests, build, ESLint, typecheck, Storybook, etc.) is green; the perf tests are still running, not failing.

There's no code fix I can push here. These two checks fail by design and only turn green when a human completes them:

• PR Author Checklist → tick the checklist items in the PR description's Author Checklist section.
• PR Reviewer Checklist → satisfied once a reviewer completes the reviewer checklist.

The branch itself is healthy — no commit needed from me.

[mkhutornyi]

Details

Explanation of Change

Adds an Enabled / Disabled status filter to the multi-layer tags per-list view (WorkspaceViewTagsTable).
Previously this table only had a free-text "Find tag" search, so admins with long tag lists had no way to narrow the table down to just enabled or just disabled tags.

The shared Table component already supports dropdown filtering out of the box via the filters (FilterConfig) + isItemInFilter props (the same mechanism Members and Company Cards use). This table simply never wired them up. Each row already carries an enabled: boolean, so no upstream data changes were needed — this is a pure UI wiring change:

• Added a single-select status filter config (Enabled / Disabled) and an isItemInFilter predicate that matches rows against item.enabled.
• Passed filters and isItemInFilter to the existing <Table>. The filter trigger and selected-filter chip render automatically inside the FilterBar that was already there.
• The filter is gated on shouldShowEnabledColumn (= !hasDependentTags), so it is not offered for dependent multi-layer tags — those intentionally have no per-tag enabled column/toggle. This matches the confirmed design decision on the issue.

Fixed Issues

$ #96965
PROPOSAL: #96965 (comment)

Tests

1. Open a workspace with multi-level (independent) tags.
2. Click any parent tag to see multiple child tags in different states (Enabled and Disabled).
3. Verify that status filter icon (Enabled | Disabled) is shown next to the "Find tag" search box.
4. Verify that you are able to filter the list to display only enabled or disabled tags.

• Verify that no errors appear in the JS console

Offline tests

Same as Tests

QA Steps

Same as Tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover 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 tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (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 followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• 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 new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• 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.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user 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.

@MelvinBot please set the PR body to the content in the details section above

[MelvinBot]

Added unit tests for the Status filter in tests/ui/WorkspaceViewTagsTableTest.tsx. Both pass locally (2 passed).

Coverage — renders the real WorkspaceViewTagsTable (no mocked Table) so the filter runs end-to-end through the actual FilterBar → popover → isItemInFilter pipeline:

1. Gating — the Status filter trigger is offered for non-dependent tags and is absent for dependent tags (covers the new filters={shouldShowEnabledColumn ? filterConfig : undefined} line).
2. Filtering — selecting Disabled shows only disabled rows, selecting Enabled shows only enabled rows, and Reset restores every row.

Notes

• The test drives the narrow layout on purpose: the wide-layout popover positions via native measureInWindow, whose callback never fires under react-test-renderer, so the popover would never open. Narrow layout resolves the position synchronously (usePopoverPosition.ts:64-65).
• The table is wrapped in a stubbed ScreenWrapperStatusContext because rows read the screen transition status, which is normally supplied by the hosting ScreenWrapper.
• Ran npm run fmt, eslint, and typecheck-tsgo on the change — all clean.

The human co-author still owns the Tests/QA sections and the all-platform screenshots.

[MelvinBot]

Re-checked after the latest commit (3a28737 adding tests/ui/WorkspaceViewTagsTableTest.tsx). Every real CI check passes ✅ — all 8 test jobs, typecheck (I waited for it to finish), ESLint, Oxfmt, Storybook, Bun tests, React Compiler, spellcheck, etc. Perf tests are still running but passed on the prior run.

The only red check is the PR Author Checklist, which is on MelvinBot's ignore list. It's not a code/CI failure I can fix by pushing — it stays red by design until the checklist items in the PR description are ticked. Once those boxes are checked, it'll go green.

So there's no fix to push here; the branch is otherwise green.

[MelvinBot]

✅ Updated the PR body with the content you provided.

[mkhutornyi]

@MelvinBot mark as ready for review

[melvin-bot]

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

[MelvinBot]

Done — marked PR #97048 as ready for review. 🎀

One heads-up: the Tests, QA Steps, and all-platform screenshot sections in the PR body still have // TODO placeholders that need a human co-author to fill in and attach. Those aren't something I can complete on anyone's behalf.

[MelvinBot]

Still the same situation: the only failing check is the PR Author Checklist, which isn't a code or CI failure I can fix with a commit. Every real check (tests, build, ESLint, Oxfmt, typecheck, Storybook, perf) is passing. ✅

The Author Checklist stays red until the checklist items in the PR description's Author Checklist section are ticked. There's no code change to push here — please complete those boxes and the check will go green.

[mkhutornyi]

Details

Explanation of Change

Adds an Enabled / Disabled status filter to the multi-layer tags per-list view (WorkspaceViewTagsTable).
Previously this table only had a free-text "Find tag" search, so admins with long tag lists had no way to narrow the table down to just enabled or just disabled tags.

The shared Table component already supports dropdown filtering out of the box via the filters (FilterConfig) + isItemInFilter props (the same mechanism Members and Company Cards use). This table simply never wired them up. Each row already carries an enabled: boolean, so no upstream data changes were needed — this is a pure UI wiring change:

• Added a single-select status filter config (Enabled / Disabled) and an isItemInFilter predicate that matches rows against item.enabled.
• Passed filters and isItemInFilter to the existing <Table>. The filter trigger and selected-filter chip render automatically inside the FilterBar that was already there.
• The filter is gated on shouldShowEnabledColumn (= !hasDependentTags), so it is not offered for dependent multi-layer tags — those intentionally have no per-tag enabled column/toggle. This matches the confirmed design decision on the issue.

Fixed Issues

$ #96965
PROPOSAL: #96965 (comment)

Tests

1. Open a workspace with multi-level (independent) tags.
2. Click any parent tag to see multiple child tags in different states (Enabled and Disabled).
3. Verify that status filter icon (Enabled | Disabled) is shown next to the "Find tag" search box.
4. Verify that you are able to filter the list to display only enabled or disabled tags.

• Verify that no errors appear in the JS console

Offline tests

Same as Tests

QA Steps

Same as Tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover 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 tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (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 followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• 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 new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• 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.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user 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 verified that similar component doesn't exist in the codebase
• I verified that all props are defined accurately and each prop has a /** comment above it */
• I verified that each file is named correctly
• I verified that each component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
• I verified that the only data being stored in component state is data necessary for rendering and nothing else
• In component if we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
• 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)
• I verified that component 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)
• I verified that all JSX used for rendering exists in the render method
• I verified that each 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

@MelvinBot please set the PR body to the content in the details section above

[mkhutornyi]

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.mov

Android: mWeb Chrome

iOS: HybridApp

ios.mov

iOS: mWeb Safari

MacOS: Chrome / Safari

web.mov

[MelvinBot]

✅ Updated the PR description to the content you provided.

[JmillsExpensify]

LGTM at a high level, though we should get screen recordings in this PR.

[mkhutornyi]

Screen recordings were added in Reviewer Checklist