Repository navigation
[Due for payment 2025-05-30] [Better Expense Report View] Use the same component for Transaction row in Search / Reports / Inbox #61512
Description
Follow up from #59804 (comment)
Lets use the same component for transaction in Search and in the new expense report view
Issue Owner
Current Issue Owner: @trjExpensifyMetadata
Metadata
Labels
Type
Projects
- Status
Activity
melvin-bot commentedon May 6, 2025
Triggered auto assignment to @NicMendonca (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.nabi-ebrahimi commentedon May 6, 2025
Proposal
Please re-state the problem that we are trying to solve in this issue.
Currently, we use different components to render the same type of transaction row across the Search, Reports, and Inbox views. This inconsistency increases the maintenance burden and causes visual or behavioral discrepancies between views.
What is the root cause of that problem?
When new views like the expense report were introduced, instead of reusing the existing component logic used in Search and Inbox, new implementations were created. This led to duplicated code and design inconsistencies.
What changes do you think we should make in order to solve the problem?
We should create a single shared
TransactionRowcomponent that encapsulates the common UI and behavior logic for transaction rows. This component should be flexible enough to handle contextual differences via props (e.g., for highlighting, tap actions, or contextual icons). Then we can refactor the Search, Inbox, and Expense Report views to use this shared component.What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
Rendering a transaction row with and without additional context (e.g., receipts, policy icons, etc.).
Verifying that the shared component renders correctly in Search, Inbox, and Report views.
Ensuring props like
isSelected,onPress,highlightColor, andshowReceiptIconare respected.Testing edge cases like:
Visual regression tests to ensure consistent UI across all views
What alternative solutions did you explore? (Optional)
An alternative would be to keep separate components and sync styles and logic across them, but this would be more error-prone and increase long-term maintenance costs.
sumo-slonik commentedon May 7, 2025
Hi, I'm Kuba from SWM, and I'll take care of this.
melvin-bot commentedon May 12, 2025
@sumo-slonik Eep! 4 days overdue now. Issues have feelings too...
13 remaining items
mountiny commentedon May 22, 2025
Both of those demoted and assigned @sumo-slonik and @DylanDylann
[-][Better Expense Report View] Use the same component for Transaction row in Search / Reports / Inbox[/-][+][Due for payment 2025-05-30] [Better Expense Report View] Use the same component for Transaction row in Search / Reports / Inbox[/+]melvin-bot commentedon May 23, 2025
Reviewinglabel has been removed, please complete the "BugZero Checklist".melvin-bot commentedon May 23, 2025
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.50-0 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2025-05-30. 🎊
For reference, here are some details about the assignees on this issue:
melvin-bot commentedon May 23, 2025
@DylanDylann @trjExpensify @DylanDylann The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
trjExpensify commentedon May 29, 2025
This is on prod, so I think we can close it right?
trjExpensify commentedon May 30, 2025
Closing then.