feat: add escrow detail page#207
Merged
sotoJ24 merged 1 commit intoJun 23, 2026
Merged
Conversation
Contributor
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
📝 WalkthroughWalkthroughAdds a dynamic escrow detail page at ChangesEscrow Detail Page with Status-Driven Views
Sequence Diagram(s)sequenceDiagram
participant Browser
participant EscrowDetailPage
participant ApolloClient
participant resolveView
participant SubView
Browser->>EscrowDetailPage: GET /dashboard/escrow/id
EscrowDetailPage->>EscrowDetailPage: validate UUID, skip if invalid
EscrowDetailPage->>ApolloClient: useQuery GET_ESCROW_BY_ID
ApolloClient-->>EscrowDetailPage: loading / error / EscrowDetail
EscrowDetailPage->>resolveView: escrow.status + invoiceAcknowledged
resolveView-->>EscrowDetailPage: ViewMeta with kind, step, headerStatus
EscrowDetailPage->>SubView: renderView to pending/invoice/status/released
SubView-->>EscrowDetailPage: rendered JSX
EscrowDetailPage-->>Browser: InvoiceHeader + SubView + NotesPanel + ProcessStepper
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip CodeRabbit can use SkillSpector to scan AI agent skill manifests and MCP configurations for security risks.SkillSpector analyzes |
Contributor
Author
|
1 task
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
apps/frontend/src/app/dashboard/escrow/[id]/page.tsx (3)
148-149: 💤 Low valueMixed styling approach: Tailwind classes and inline styles.
The page uses Tailwind utility classes (e.g.,
className="flex items-center justify-center py-16"at line 148,className="grid grid-cols-1 lg:grid-cols-3"at line 185) alongside inlinestyleobjects throughout the rest of the component.For consistency and maintainability, consider using a single styling approach across the entire page. If Tailwind is available, the inline styles could be replaced with utility classes; alternatively, inline styles could replace the Tailwind classes.
Also applies to: 185-186
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/frontend/src/app/dashboard/escrow/`[id]/page.tsx around lines 148 - 149, The component mixes two styling approaches: Tailwind utility classes (such as in the loading spinner div at line 148 with className="flex items-center justify-center py-16" and the grid layout at line 185) and inline style objects throughout the rest of the component. To improve maintainability and consistency, standardize the styling approach across the entire page by converting all inline style objects to their equivalent Tailwind utility classes, since Tailwind is already being used in the component. Audit the entire page.tsx file, identify all instances of inline styles, and replace them with appropriate Tailwind classes that achieve the same visual result.
72-113: ⚡ Quick winDefault fallback in
resolveViewmay mask unexpected status values.The
defaultcase (lines 106-112) silently maps any unrecognized status to the "invoice" view. If the database or API introduces a new status value (e.g.,"cancelled","disputed"), users will see the invoice view without any indication that something is unexpected.Consider logging unrecognized statuses to aid debugging:
default: + console.warn(`Unexpected escrow status: "${status}". Falling back to invoice view.`); return { kind: "invoice",Or, for stricter handling, return a dedicated error/unknown view that surfaces the unexpected status to the user.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/frontend/src/app/dashboard/escrow/`[id]/page.tsx around lines 72 - 113, The default case in the resolveView function silently maps any unrecognized status value to the invoice view without logging or surfacing the unexpected value. To fix this, add console logging or error tracking in the default case to capture and report when an unexpected status is encountered (this helps with debugging when new statuses are introduced), and optionally return a dedicated error or unknown view configuration instead of defaulting to the invoice view, so users get visual feedback that something unexpected occurred rather than silently showing the invoice view.
179-181: 💤 Low valueDate formatting without explicit timezone may display unexpected dates.
The
toLocaleDateString()call formats the date in the user's local timezone. Ifescrow.updated_atorescrow.created_atrepresents a UTC timestamp, users in different timezones may see different calendar dates (e.g., 11:00 PM on Jan 1 UTC displays as Jan 1 for UTC users but Dec 31 for users in earlier timezones).If you want to display the date in a specific timezone (e.g., UTC) regardless of user location, pass explicit options:
new Date(escrow.updated_at ?? escrow.created_at).toLocaleDateString('en-US', { timeZone: 'UTC', day: 'numeric', month: 'long', year: 'numeric' })Or, if you intend to show the local date, this is working as designed.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/frontend/src/app/dashboard/escrow/`[id]/page.tsx around lines 179 - 181, The paidAt prop assignment uses toLocaleDateString() without explicit timezone options, which causes the date to be formatted in each user's local timezone. If the underlying timestamp values (escrow.updated_at or escrow.created_at) are in UTC, different users will see different calendar dates depending on their timezone. To fix this, add explicit timezone options to the toLocaleDateString() method call, specifying 'UTC' as the timeZone option along with day, month, and year formatting options if you want all users to see the same date regardless of location, or remove these options if the current behavior of showing the user's local date is intentional.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/frontend/src/components/escrow/NotesPanel.tsx`:
- Around line 60-70: The useEffect hook and handleSave function in
NotesPanel.tsx access localStorage without error handling, which can throw
exceptions in private browsing modes, when storage quota is exceeded, or when
disabled by security policies. Wrap both the window.localStorage.getItem call in
the useEffect and the window.localStorage.setItem call in the handleSave
function with try-catch blocks to gracefully handle these exceptions, ensuring
the component continues to render even if localStorage operations fail.
In `@apps/frontend/src/components/escrow/views/EscrowPendingView.tsx`:
- Line 21: The ownerAddress assignment in EscrowPendingView uses owner?.id as a
fallback, but this is a database UUID not a Stellar wallet address. Update the
GraphQL query to fetch the owner's primary wallet address from the user_wallets
table, then replace the owner?.id fallback with the actual wallet_address field.
Apply the same fix to EscrowStatusView (line 55) and EscrowReleasedView (line
38) where the same pattern exists, ensuring all three files properly retrieve
and use the Stellar wallet address instead of the database UUID.
In `@apps/frontend/src/components/escrow/views/EscrowStatusView.tsx`:
- Around line 34-38: The textarea element with placeholder "Description…" in
EscrowStatusView.tsx is uncontrolled and only has a defaultValue prop without a
corresponding value prop or onChange handler, meaning user changes will not be
persisted. Either convert this textarea to a controlled component by adding a
value prop (bound to state) and an onChange handler to track changes (following
the pattern used in EscrowReleasedView.tsx for claims textarea or NotesPanel.tsx
for notes), or if this field should be read-only in this view, replace the
textarea with a paragraph/div element displaying the description or add the
readOnly attribute to make non-editability explicit.
---
Nitpick comments:
In `@apps/frontend/src/app/dashboard/escrow/`[id]/page.tsx:
- Around line 148-149: The component mixes two styling approaches: Tailwind
utility classes (such as in the loading spinner div at line 148 with
className="flex items-center justify-center py-16" and the grid layout at line
185) and inline style objects throughout the rest of the component. To improve
maintainability and consistency, standardize the styling approach across the
entire page by converting all inline style objects to their equivalent Tailwind
utility classes, since Tailwind is already being used in the component. Audit
the entire page.tsx file, identify all instances of inline styles, and replace
them with appropriate Tailwind classes that achieve the same visual result.
- Around line 72-113: The default case in the resolveView function silently maps
any unrecognized status value to the invoice view without logging or surfacing
the unexpected value. To fix this, add console logging or error tracking in the
default case to capture and report when an unexpected status is encountered
(this helps with debugging when new statuses are introduced), and optionally
return a dedicated error or unknown view configuration instead of defaulting to
the invoice view, so users get visual feedback that something unexpected
occurred rather than silently showing the invoice view.
- Around line 179-181: The paidAt prop assignment uses toLocaleDateString()
without explicit timezone options, which causes the date to be formatted in each
user's local timezone. If the underlying timestamp values (escrow.updated_at or
escrow.created_at) are in UTC, different users will see different calendar dates
depending on their timezone. To fix this, add explicit timezone options to the
toLocaleDateString() method call, specifying 'UTC' as the timeZone option along
with day, month, and year formatting options if you want all users to see the
same date regardless of location, or remove these options if the current
behavior of showing the user's local date is intentional.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 475603b3-98b5-4665-8f98-737cbe3ddca4
📒 Files selected for processing (8)
apps/frontend/src/app/dashboard/escrow/[id]/page.tsxapps/frontend/src/components/escrow/NotesPanel.tsxapps/frontend/src/components/escrow/views/EscrowInvoiceView.tsxapps/frontend/src/components/escrow/views/EscrowPendingView.tsxapps/frontend/src/components/escrow/views/EscrowReleasedView.tsxapps/frontend/src/components/escrow/views/EscrowStatusView.tsxapps/frontend/src/components/escrow/views/escrow-view-utils.tsxapps/frontend/src/types/escrow.ts
Jonatan-Chaverri
force-pushed
the
feat/add-escrow-details-page
branch
from
cd65111 to
2bec3b6
Compare
sotoJ24
approved these changes
Jun 23, 2026
sotoJ24
left a comment
sotoJ24
left a comment
Contributor
There was a problem hiding this comment.
well done @Jonatan-Chaverri
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #188
Summary by CodeRabbit