Aller au contenu
login
arrow_backRetour aux issues
StellarLock/StellarLock #502

LP lock links omit the /token|lp/ URL segment, causing wrong-type lookups on the detail page

ecoDébutant bug good first issue frontend Maybe Rewarded GrantFox OSS Third Campaign

descriptionDescription

## Summary Lock detail links should include the lock's kind in the URL, e.g. `/app/lock/lp/:id` or `/app/lock/token/:id` — that's how `src/pages/LockDetail.tsx` (line 53) decides whether to fetch a token lock or an LP lock. `src/components/locks/LockTable.tsx:110` does this correctly (`` `/app/lock/${lock.kind ?? "token"}/${lock.id}` ``), but two other call sites don't: - `src/components/locks/LockCard.tsx:114` — links to `` `/app/lock/${lock.id}` `` with no kind segment - `src/components/locks/CreateLpLockForm.tsx:182` — navigates to `` `/app/lock/${id}` `` right after creating an LP lock, with no kind segment ## Problem Both cases fall through to the fallback route `/app/lock/:id` in `src/App.tsx` (line 54), and `LockDetail.tsx` defaults anything not matching `/app/lock/lp/` to `"token"` (line 53). So an LP lock opened via a `LockCard`, or the redirect right after creating one, gets looked up as if it were a token lock — wrong contract, wrong/missing data. ## Task Include the kind segment in both links, matching the `LockTable.tsx` pattern: - `LockCard.tsx:114`: `` `/app/lock/${lock.kind ?? "token"}/${lock.id}` `` - `CreateLpLockForm.tsx:182`: since this form only ever creates LP locks, `` `/app/lock/lp/${id}` `` ## Acceptance Criteria - [ ] Clicking an LP lock's `LockCard` opens its detail page with correct LP data - [ ] Creating an LP lock navigates to its detail page with correct LP data, not the token-lock view
codeOuvre sur GitHub