Updated add tokens UX#1406
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughTokenSelect now merges local DB tokens and Jupiter-verified tokens into a single ranked searchResults list, shows Jupiter-verified badges/links, and renders Add-button wiring; schema and server persist isVerifiedOnJupiter on tokens. ChangesUnified Token Search and Jupiter Integration
Sequence Diagram (high-level flow) sequenceDiagram
participant User
participant TokenSelect
participant TokenListAPI
participant PrismaDB
User->>TokenSelect: open/search tokens
TokenSelect->>TokenListAPI: fetch local tokens + verified Jupiter tokens
TokenListAPI->>PrismaDB: query token metadata (includes isVerifiedOnJupiter)
PrismaDB-->>TokenListAPI: return token records
TokenListAPI-->>TokenSelect: return combined sources
User->>TokenSelect: click "Add" on Jupiter token
TokenSelect->>TokenListAPI: addVerifiedJupiterToken(upsert mint)
TokenListAPI->>PrismaDB: upsert token (set isVerifiedOnJupiter = true)
PrismaDB-->>TokenListAPI: upsert result
TokenListAPI-->>TokenSelect: return persisted token
TokenSelect-->>User: show token selected/loader cleared
🎯 3 (Moderate) | ⏱️ ~22 minutes
🚥 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 docstrings
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx (2)
52-68: ⚡ Quick winUse explicit
| undefined(and readonly-by-default) in TS object types.This file introduces optional properties via
?in type definitions. The repo guideline requires explicitproperty: Type | undefinedto avoid accidental omission; these object fields should also bereadonlyunless intentionally mutable.As per coding guidelines, “Use
property: Type | undefinedinstead ofproperty?: Typefor TypeScript type definitions” and “Usereadonlyproperties for object types by default in TypeScript.”🤖 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 `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx` around lines 52 - 68, The type declarations (JupiterToken, TokenSearchResponse, AddTokenResponse) use optional properties with ?; change each optional property to explicit unions (e.g., icon: string | null | undefined) and any optional top-level properties to Type | undefined instead of ?. Also make object fields readonly by default (prepend readonly to each property) unless a field is intentionally mutable (leave those mutable and document why). Update references to Token if it has optional fields the same way. Ensure the new readonly/| undefined shapes compile with usages in TokenSelect.tsx and adjust any mutations accordingly.Source: Coding guidelines
320-323: 🏗️ Heavy liftAvoid exception-driven flow; use a Result pattern helper for fetch paths.
Both async flows throw inside
tryand then handle incatch. The TS guideline asks to use a Result-style return instead of manual throw/catch flow for predictable error handling.As per coding guidelines, “Use Result type pattern instead of throwing errors for code that requires manual try-catch blocks.”
Also applies to: 362-364
🤖 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 `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx` around lines 320 - 323, In TokenSelect (the fetch block that currently does `if (!response.ok) { throw new Error('Failed to search Jupiter tokens'); }`) replace the exception-driven path with the project's Result pattern: instead of throwing, return a failure Result (e.g., Result.fail(...) or the project's equivalent) containing an error message and any response info; propagate that Result to the caller so callers can handle success/failure without try/catch. Do the same for the second occurrence at lines ~362-364 (the other fetch response.ok check) so both search/fetch helper functions return Result.ok(data) or Result.fail(error) rather than throwing. Ensure callers of the fetch functions are updated to check the Result and handle errors accordingly.Source: Coding guidelines
🤖 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 `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx`:
- Around line 102-109: Replace the non-semantic clickable elements with
accessible controls: wrap the ShieldCheck icon and the clickable <p> text in
proper interactive elements (e.g., a <button> or an <a> with role and href) or
convert their wrappers to <button> so they are focusable and keyboard-operable;
ensure keyboard activation calls the same handler
(openJupiterTokenPage(mintAddress)) and add appropriate aria-label and visible
focus styles. Update both the ShieldCheck click handler usage in TokenSelect and
the other clickable text block (the code near lines referencing the second
clickable <p>) to use the same pattern so keyboard, screen reader, and mouse
users trigger openJupiterTokenPage consistently. Also remove
event.stopPropagation only if it breaks keyboard behavior or ensure it doesn’t
prevent default keyboard activation.
- Around line 136-137: TokenSearchLabel is always rendering JupiterVerifiedIcon
(using mintAddress) which incorrectly labels local/DB tokens as
Jupiter-verified; update TokenSearchLabel (and usages in TokenSelect and the DB
token render block around the lines referencing mintAddress) to conditionally
render JupiterVerifiedIcon only when the token is actually a Jupiter token
(e.g., pass a boolean prop like isJupiterVerified or check a token.source/type
flag), and ensure TokenSelect/DB token rendering supplies that flag instead of
unconditionally rendering <JupiterVerifiedIcon mintAddress={mintAddress} />.
---
Nitpick comments:
In `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx`:
- Around line 52-68: The type declarations (JupiterToken, TokenSearchResponse,
AddTokenResponse) use optional properties with ?; change each optional property
to explicit unions (e.g., icon: string | null | undefined) and any optional
top-level properties to Type | undefined instead of ?. Also make object fields
readonly by default (prepend readonly to each property) unless a field is
intentionally mutable (leave those mutable and document why). Update references
to Token if it has optional fields the same way. Ensure the new readonly/|
undefined shapes compile with usages in TokenSelect.tsx and adjust any mutations
accordingly.
- Around line 320-323: In TokenSelect (the fetch block that currently does `if
(!response.ok) { throw new Error('Failed to search Jupiter tokens'); }`) replace
the exception-driven path with the project's Result pattern: instead of
throwing, return a failure Result (e.g., Result.fail(...) or the project's
equivalent) containing an error message and any response info; propagate that
Result to the caller so callers can handle success/failure without try/catch. Do
the same for the second occurrence at lines ~362-364 (the other fetch
response.ok check) so both search/fetch helper functions return Result.ok(data)
or Result.fail(error) rather than throwing. Ensure callers of the fetch
functions are updated to check the Result and handle errors accordingly.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f1525ef2-baa1-4f5d-b6a4-bf3c5cd6b956
📒 Files selected for processing (1)
src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx
| <ShieldCheck | ||
| className="h-3.5 w-3.5 text-[#1C4CE7]" | ||
| aria-label="Verified on Jupiter" | ||
| onClick={(event) => { | ||
| event.stopPropagation(); | ||
| openJupiterTokenPage(mintAddress); | ||
| }} | ||
| /> |
There was a problem hiding this comment.
Interactive icon/text are not keyboard-accessible controls.
Clickable ShieldCheck and <p> rely on onClick only. Keyboard users cannot reliably trigger these actions. Use semantic <button>/<a> elements (or add full keyboard handlers + focus styles).
Also applies to: 144-149
🤖 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 `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx`
around lines 102 - 109, Replace the non-semantic clickable elements with
accessible controls: wrap the ShieldCheck icon and the clickable <p> text in
proper interactive elements (e.g., a <button> or an <a> with role and href) or
convert their wrappers to <button> so they are focusable and keyboard-operable;
ensure keyboard activation calls the same handler
(openJupiterTokenPage(mintAddress)) and add appropriate aria-label and visible
focus styles. Update both the ShieldCheck click handler usage in TokenSelect and
the other clickable text block (the code near lines referencing the second
clickable <p>) to use the same pattern so keyboard, screen reader, and mouse
users trigger openJupiterTokenPage consistently. Also remove
event.stopPropagation only if it breaks keyboard behavior or ensure it doesn’t
prevent default keyboard activation.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx (2)
102-109:⚠️ Potential issue | 🟠 Major | ⚖️ Poor tradeoffKeyboard users still cannot trigger the Jupiter link.
This issue was previously flagged: the
ShieldCheckicon'sonClickhandler fires on mouse click but not on keyboard Enter press. The Tooltip's button handles keyboard Enter by toggling the tooltip open/closed, preventing the child's onClick from executing. Keyboard users see the tooltip but cannot open the Jupiter token page.🤖 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 `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx` around lines 102 - 109, The ShieldCheck icon's click only works for mouse users; make it keyboard-accessible by adding a focusable role and key handler: ensure the ShieldCheck element has tabIndex={0} and role="button" (or equivalent props) and implement an onKeyDown that listens for Enter and Space, calls event.stopPropagation(), and invokes openJupiterTokenPage(mintAddress) just like the onClick handler; keep the existing aria-label for accessibility and ensure the Tooltip button no longer prevents the child's key handling by stopping propagation in the icon's handlers.
148-156:⚠️ Potential issue | 🟠 Major | ⚖️ Poor tradeoffKeyboard users still cannot trigger the Jupiter link.
This issue was previously flagged: the mint address
<p>element'sonClickhandler fires on mouse click but not on keyboard Enter press. The Tooltip's button handles keyboard Enter by toggling the tooltip, preventing the child's onClick from executing. Keyboard users see the tooltip but cannot open the Jupiter token page.🤖 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 `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx` around lines 148 - 156, The mint address <p> in TokenSelect is only clickable with mouse; make it keyboard-accessible by replacing or enhancing it to behave like a button: ensure the element with truncatePublicKey(mintAddress, 6) is focusable (tabIndex=0 or use a <button>), add an onKeyDown handler that calls event.stopPropagation() and invokes openJupiterTokenPage(mintAddress) for Enter/Space, and keep the existing onClick behavior; update the element referenced in TokenSelect.tsx (the element rendering truncatePublicKey and using mintAddress and openJupiterTokenPage) so keyboard users can open the Jupiter token page.
🤖 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 `@prisma/schema.prisma`:
- Line 166: The isVerifiedOnJupiter field currently uses `@default`(true) which
will mark all existing tokens as Jupiter-verified; change the schema to remove
or flip the default (e.g., set isVerifiedOnJupiter Boolean `@default`(false) or no
default) in the Prisma model containing isVerifiedOnJupiter, then add a data
migration script that queries tokens and sets isVerifiedOnJupiter = true only
for tokens actually imported/marked from Jupiter (use whatever provenance flag
or import source you have), or alternatively document that the migration
intentionally marks all existing tokens as verified if you choose that route.
In `@src/constants/tokenList.ts`:
- Line 13: The property declaration is wrong: replace the optional
`isVerifiedOnJupiter?: boolean` with a non-optional `isVerifiedOnJupiter:
boolean` (or `isVerifiedOnJupiter: boolean | undefined` if you intentionally
want undefined) in the client TypeScript type in src/constants/tokenList.ts so
it follows the "property: Type | undefined" guideline and — since the server
always provides this field — matches the server Token interface; update the
interface/type that contains `isVerifiedOnJupiter` so clients and server types
align.
---
Duplicate comments:
In `@src/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsx`:
- Around line 102-109: The ShieldCheck icon's click only works for mouse users;
make it keyboard-accessible by adding a focusable role and key handler: ensure
the ShieldCheck element has tabIndex={0} and role="button" (or equivalent props)
and implement an onKeyDown that listens for Enter and Space, calls
event.stopPropagation(), and invokes openJupiterTokenPage(mintAddress) just like
the onClick handler; keep the existing aria-label for accessibility and ensure
the Tooltip button no longer prevents the child's key handling by stopping
propagation in the icon's handlers.
- Around line 148-156: The mint address <p> in TokenSelect is only clickable
with mouse; make it keyboard-accessible by replacing or enhancing it to behave
like a button: ensure the element with truncatePublicKey(mintAddress, 6) is
focusable (tabIndex=0 or use a <button>), add an onKeyDown handler that calls
event.stopPropagation() and invokes openJupiterTokenPage(mintAddress) for
Enter/Space, and keep the existing onClick behavior; update the element
referenced in TokenSelect.tsx (the element rendering truncatePublicKey and using
mintAddress and openJupiterTokenPage) so keyboard users can open the Jupiter
token page.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a8b65b52-6140-42ad-8ff1-1191a3bd021c
📒 Files selected for processing (4)
prisma/schema.prismasrc/constants/tokenList.tssrc/features/listing-builder/components/Form/Rewards/Tokens/TokenSelect.tsxsrc/server/tokenList.ts
| decimals Int | ||
| sortOrder Int @default(0) | ||
| isActive Boolean @default(true) | ||
| isVerifiedOnJupiter Boolean @default(true) |
There was a problem hiding this comment.
Incorrect default value for Jupiter verification flag.
The @default(true) will mark ALL existing tokens as Jupiter-verified after migration, even if they were manually curated or imported from non-Jupiter sources. This contradicts the stated purpose of tracking Jupiter verification status.
When the migration runs, existing tokens that were NOT verified on Jupiter will incorrectly show verification badges in the UI (as seen in TokenSearchLabel downstream).
🔧 Recommended fix
- isVerifiedOnJupiter Boolean `@default`(true)
+ isVerifiedOnJupiter Boolean `@default`(false)Then either:
- Write a data migration to set
isVerifiedOnJupiter = trueonly for tokens that were actually added from Jupiter, or - Document that all existing tokens are considered Jupiter-verified by design
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| isVerifiedOnJupiter Boolean @default(true) | |
| isVerifiedOnJupiter Boolean `@default`(false) |
🤖 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 `@prisma/schema.prisma` at line 166, The isVerifiedOnJupiter field currently
uses `@default`(true) which will mark all existing tokens as Jupiter-verified;
change the schema to remove or flip the default (e.g., set isVerifiedOnJupiter
Boolean `@default`(false) or no default) in the Prisma model containing
isVerifiedOnJupiter, then add a data migration script that queries tokens and
sets isVerifiedOnJupiter = true only for tokens actually imported/marked from
Jupiter (use whatever provenance flag or import source you have), or
alternatively document that the migration intentionally marks all existing
tokens as verified if you choose that route.
| decimals: number; | ||
| sortOrder?: number; | ||
| isActive?: boolean; | ||
| isVerifiedOnJupiter?: boolean; |
There was a problem hiding this comment.
TypeScript property definition violates coding guideline and creates type mismatch.
Two issues:
-
Guideline violation: Uses
isVerifiedOnJupiter?: booleaninstead ofisVerifiedOnJupiter: boolean | undefined. As per coding guidelines, "Useproperty: Type | undefinedinstead ofproperty?: Typefor TypeScript type definitions to force explicit property passing and prevent bugs from accidentally omitting required properties." -
Type mismatch with server: The server Token interface (src/server/tokenList.ts line 12) declares this field as required (
isVerifiedOnJupiter: boolean), and the server always returns it (included in tokenSelect + has schema default). The client type should match.
🔧 Recommended fix
- isVerifiedOnJupiter?: boolean;
+ isVerifiedOnJupiter: boolean | undefined;Or if the server guarantees this field is always present (which it does via the schema default):
- isVerifiedOnJupiter?: boolean;
+ isVerifiedOnJupiter: boolean;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| isVerifiedOnJupiter?: boolean; | |
| isVerifiedOnJupiter: boolean | undefined; |
🤖 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 `@src/constants/tokenList.ts` at line 13, The property declaration is wrong:
replace the optional `isVerifiedOnJupiter?: boolean` with a non-optional
`isVerifiedOnJupiter: boolean` (or `isVerifiedOnJupiter: boolean | undefined` if
you intentionally want undefined) in the client TypeScript type in
src/constants/tokenList.ts so it follows the "property: Type | undefined"
guideline and — since the server always provides this field — matches the server
Token interface; update the interface/type that contains `isVerifiedOnJupiter`
so clients and server types align.
Source: Coding guidelines
1 participant
What does this PR do?
isVerifiedOnJupiterfield in TokenMetadataWhere should the reviewer start?
How should this be manually tested?
Any background context you want to provide?
What are the relevant issues?
Screenshots (if appropriate)
Summary by CodeRabbit