574 send nft wrapper #3611
574 send nft wrapper #3611
Conversation
WalkthroughAdds an NFT-specific two-step send flow (insertAddress → summary) with a new SendNFTContextProvider, feature-flagged navigation to a new SEND_NFT route, type/export changes to the Send context, theme color adjustments for step UI, and translation additions for send/step/receiver across many locales. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant UI as CollectiblesSendActionButton / NFTDetail
participant FF as FeatureFlags
participant Nav as Navigator
participant Screen as SendNFTScreen
participant Context as SendNFTContextProvider
participant Store as Redux
User->>UI: Tap "Send"
UI->>FF: read betterWorldFeature.balanceScreen.send.enabled
alt feature enabled
FF-->>Nav: route SEND_NFT(contractAddress, tokenId)
else feature disabled
FF-->>Nav: route INSERT_ADDRESS_SEND(contractAddress, tokenId)
end
Nav->>Screen: mount SendNFTScreen(params)
Screen->>Store: select/fetch NFT details
Store-->>Screen: NFT data
Screen->>Context: initialize flow with NFT
Note over Context: step = insertAddress
User->>Context: enter address (setFlowState)
User->>Context: goToNext()
Context-->>Context: step -> summary (animated transition)
User->>Context: review & confirm (trigger send)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ 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 |
paolampilla
requested review from
Doublemme,
HiiiiD,
Jonathansoufer and
hughlivingstone
as code owners
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/i18n/translations/ru.json (1)
1054-1156: Overall Russian send-flow translations look good; minor style tweak suggestionThe new/updated keys (
SEND_ACCOUNTS_*,SEND_COLLECTIBLE,SEND_CREATE_CONTACT_*,SEND_RECEIVER,SEND_RECENT_EMPTY_STATE_DESCRIPTION,SEND_STEP_OF,SEND_VOT3_WARNING) preserve placeholders and correctly describe the new send / NFT send UX.One small style suggestion for clarity:
- "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "Как только вы отправите на адрес, он появится здесь для быстрого доступа.", + "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "Как только вы отправите средства на этот адрес, он появится здесь для быстрого доступа.",This makes the object of “отправите” explicit and reads a bit more naturally in Russian.
🧹 Nitpick comments (20)
src/i18n/translations/pt.json (3)
1138-1138: Confirm SEND_RECENT_EMPTY_STATE_DESCRIPTION aligns with user expectations.The update from "...aparecerão aqui para acesso rápido" to "...aparecerá aqui para acesso rápido" refines the empty state messaging. Ensure this contextually matches when recent transactions/addresses are first displayed.
Consider checking the other 14 language files in this PR to confirm this wording pattern is consistent across locales (e.g., checking en.json, es.json, etc.).
1155-1155: Minor wording adjustment: "posteriormente" vs. prior phrasing.Line 1155 updates
SEND_VOT3_WARNINGto use "posteriormente" (later/subsequently). Confirm this matches the semantic intent from any prior version and aligns with terminology used for time-dependent actions elsewhere in the file.#!/bin/bash # Cross-check VOT3-related terminology for consistency rg -n -i 'vot3|converter|enviado' src/i18n/translations/pt.json | grep -i 'warning\|vot3'
1054-1054: Consistency check: "assim que forem adicionadas" phrasing.The update to
SEND_ACCOUNTS_EMPTY_STATE_DESCRIPTION("assim que forem adicionadas" vs. the prior "depois de adicionadas") is a subtle improvement. Verify this matches grammatical patterns used in similar empty-state messages throughout the file.src/Constants/Theme/Colors.ts (1)
370-382: Send screen color tokens: structure looks consistentMoving
stepText/stepBackgroundtosendScreen(parallel totokenAmountCard) makes sense for step-level styling, and theColorstype matches the light/dark implementations below. Just ensure any existing usages oftokenAmountCard.stepTextwere updated to the newsendScreen.stepTextpath.src/Components/Collectibles/CollectiblesSendActionButton.tsx (1)
16-32: GuardbetterWorldFeatureand hoist the flag into a local booleanThe logic is fine, but
betterWorldFeatureitself isn’t null‑safe:betterWorldFeature.balanceScreen?.send?.enabledwill throw ifbetterWorldFeatureis everundefined(e.g., partial flag payloads, future refactors). You can also avoid repeating the expression by hoisting it:- const { betterWorldFeature } = useFeatureFlags() + const { betterWorldFeature } = useFeatureFlags() + const isSendNftEnabled = betterWorldFeature?.balanceScreen?.send?.enabled === true - const onPress = useCallback(async () => { + const onPress = useCallback(() => { onClose() - if (betterWorldFeature.balanceScreen?.send?.enabled) { + if (isSendNftEnabled) { nav.navigate(Routes.SEND_NFT, { contractAddress: address, tokenId, }) return } nav.navigate(Routes.INSERT_ADDRESS_SEND, { contractAddress: address, tokenId, }) - }, [address, nav, onClose, tokenId, betterWorldFeature.balanceScreen?.send?.enabled]) + }, [address, nav, onClose, tokenId, isSendNftEnabled])This makes the flag handling safer and the callback dependencies clearer.
src/i18n/translations/vi.json (2)
1062-1062: Unify “collectible” terminology.Elsewhere in VI, “Đồ sưu tầm” is used; here it’s “vật phẩm sưu tầm”. Pick one for consistency (recommend “Đồ sưu tầm”).
1141-1141: Prefer generic step key; plan to retire hardcoded variant.Now that SEND_STEP_OF exists, consider migrating callers off SEND_STEP_OF_3 and deprecating it to reduce duplication.
src/i18n/translations/sv.json (1)
1054-1054: Polish phrasing for natural Swedish.Use “Dina plånbokskonton visas här när de har lagts till.” for a more idiomatic compound.
src/i18n/translations/tr.json (3)
1062-1062: Clarify “collectible” wording.“Koleksiyon gönder” is terse. Consider “Koleksiyon ürünü gönder” or “Koleksiyon öğesi gönder” for clarity.
1144-1145: Align “token” terminology.“SEND_TOKEN_AMOUNT/SELECT” use “Token”, while other keys in TR sometimes use “Jeton”. Pick one term (prefer “Token” for web3 consistency) across this locale.
If you want, I can list all occurrences to normalize.
1133-1133: Minor UX copy tweak (optional).“Bu yeni adresi kişilere ekle” → “Bu yeni adresi Kişiler’e ekle” (proper noun casing) or “Kişilere bu yeni adresi ekle” (flowing order).
src/i18n/translations/zh.json (1)
1054-1156: Unify second‑person pronouns in new send‑flow stringsThe new send strings mix “你/某个地址” with the more formal “您” used elsewhere in this locale. For consistency and tone, I’d align these:
- "SEND_ACCOUNTS_EMPTY_STATE_DESCRIPTION": "添加后，你的钱包账户将显示在此处。", + "SEND_ACCOUNTS_EMPTY_STATE_DESCRIPTION": "添加后，您的钱包账户将显示在此处。", - "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "当你向某个地址发送后，将会在此显示以便快速访问。", + "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "当您向某个地址发送后，将会在此显示以便快速访问。"src/i18n/translations/tw.json (1)
1054-1156: Align pronoun form with rest of Traditional Chinese localeMost of this locale uses the polite “您”, while some new send‑flow strings use “你/你的”. For a consistent tone, consider:
- "SEND_CONTACTS_EMPTY_STATE_DESCRIPTION": "新增你的第一個聯絡人以更快傳送並避免錯誤。", + "SEND_CONTACTS_EMPTY_STATE_DESCRIPTION": "新增您的第一個聯絡人，以更快傳送並避免錯誤。", - "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "當你發送給一個地址後，它會顯示在這裡以便快速存取。", + "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "當您發送給一個地址後，它會顯示在這裡以便快速存取。"src/Screens/Flows/App/NFT/NFTDetailScreen/NFTDetailScreen.tsx (1)
7-15: Feature‑flag‑gated SEND_NFT routing is correct; consider a small readability tweakThe new
useFeatureFlagsusage and the conditional navigation toRoutes.SEND_NFTvsRoutes.INSERT_ADDRESS_SENDcorrectly gate the NFT send flow behindbetterWorldFeature.balanceScreen?.send?.enabled, and the route params match the stack typing.To make this a bit clearer and keep the dependency array simple, you could factor the flag into a local boolean:
const { betterWorldFeature } = useFeatureFlags() const isNewNFTSendEnabled = betterWorldFeature.balanceScreen?.send?.enabled ?? false const onSendPress = useCallback(() => { if (isNewNFTSendEnabled) { nav.navigate(Routes.SEND_NFT, { contractAddress: route.params.collectionAddress!, tokenId: route.params.nftTokenId, }) return } nav.navigate(Routes.INSERT_ADDRESS_SEND, { contractAddress: route.params.collectionAddress!, tokenId: route.params.nftTokenId, }) }, [nav, route.params.collectionAddress, route.params.nftTokenId, isNewNFTSendEnabled])Also applies to: 61-76
src/Screens/Flows/App/NFT/SendNFTScreen/SendNFTScreen.tsx (2)
25-27: Type duplication:SendNFTFlowStepis defined in multiple places.This type is also defined in
SendNFTContextProvider.tsx. Consider exporting it from a single location and importing it here to avoid divergence if the flow steps change.-type SendNFTFlowStep = "insertAddress" | "summary" - -const ORDER: SendNFTFlowStep[] = ["insertAddress", "summary"] +import { SendNFTFlowStep } from "~Components/Reusable/Send" + +const ORDER: SendNFTFlowStep[] = ["insertAddress", "summary"]
127-129: Summary step is a placeholder.The summary step currently renders an empty fragment. This appears intentional for scaffolding the flow, but ensure the summary screen implementation is tracked.
Would you like me to open an issue to track implementing the summary step content?
src/Components/Reusable/Send/Provider/SendNFTContextProvider.tsx (1)
25-43: Navigation logic is correct but consider adding exhaustiveness handling.The switch statements only handle specific cases, which is correct for a two-step flow. However, adding a
defaultcase (even if just a no-op) would provide exhaustiveness safety if additional steps are added later.const goToNext = useCallback(() => { switch (step) { case "insertAddress": nextStep.value = "summary" previousStep.value = step setStep("summary") break + default: + break } }, [nextStep, previousStep, step]) const goToPrevious = useCallback(() => { switch (step) { case "summary": nextStep.value = "insertAddress" previousStep.value = step setStep("insertAddress") break + default: + break } }, [nextStep, previousStep, step])src/i18n/i18n-types.ts (1)
4356-4359: Create‑contact placeholders and description keys line up correctly
SEND_CREATE_CONTACT_ADDRESS_PLACEHOLDER,SEND_CREATE_CONTACT_DESCRIPTION, andSEND_CREATE_CONTACT_NAME_PLACEHOLDERexist in bothRootTranslationandTranslationFunctionswith matching names and simple string/zero‑arg function types, so typed usage for the “add contact” flow is coherent.If you want copy consistency with other placeholders like
PLACEHOLDER_ENTER_ADDRESS, consider switching the English phrasing from “Insert …” to “Enter …” in the source translation files, then re‑generating this type file.Also applies to: 4364-4367, 4372-4375, 10064-10067, 10074-10077, 10084-10087
src/i18n/translations/it.json (1)
1065-1066: Italian: receiver term and wallet address phrasingStandardize “Destinatario” and improve “Indirizzo wallet” phrasing. “Ricevitore” (Line 63) and “Destinatario” are mixed; suggest converging on “Destinatario” across the app.
- "SEND_CREATE_CONTACT_ADDRESS": "Indirizzo wallet", + "SEND_CREATE_CONTACT_ADDRESS": "Indirizzo del wallet", - "SEND_CREATE_CONTACT_ADDRESS_PLACEHOLDER": "Inserisci indirizzo wallet", + "SEND_CREATE_CONTACT_ADDRESS_PLACEHOLDER": "Inserisci l'indirizzo del wallet", - "SEND_RECEIVER": "Destinatario", + "SEND_RECEIVER": "Destinatario", // keep, but align OTHER usages (e.g., ADDITIONAL_DETAIL_RECEIVER) in a follow-up - "SEND_RECEIVER_ADDRESS_INPUT_ERROR": "Indirizzo wallet, username o dominio non valido", + "SEND_RECEIVER_ADDRESS_INPUT_ERROR": "Indirizzo del wallet, username o dominio non valido", - "SEND_RECEIVER_ADDRESS_INPUT_LABEL": "Indirizzo wallet", + "SEND_RECEIVER_ADDRESS_INPUT_LABEL": "Indirizzo del wallet", - "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "Quando invii a un indirizzo, comparirà qui per un accesso rapido.", + "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "Quando invii a un indirizzo, comparirà qui per accesso rapido."If you prefer “Portafoglio” over “wallet”, I can generate a locale-wide diff to switch all occurrences for consistency.
Also applies to: 1126-1134, 1138-1141, 1143-1143
src/i18n/translations/es.json (1)
1057-1062: Spanish: natural phrasing and consistency in SEND stringsTighten one phrase and keep “billetera” consistent in the changed keys.
- "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "Cuando envíes a una dirección, aparecerá aquí para rápido acceso.", + "SEND_RECENT_EMPTY_STATE_DESCRIPTION": "Cuando envíes a una dirección, aparecerá aquí para acceso rápido."Note: The repo mixes “billetera” y “cartera”. If desired, I can prep a follow-up PR to normalize across ES.
Also applies to: 1064-1073, 1126-1126, 1138-1141, 1155-1155
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
src/Components/Collectibles/CollectiblesSendActionButton.tsx(2 hunks)src/Components/Reusable/Send/Provider/SendContextProvider.tsx(2 hunks)src/Components/Reusable/Send/Provider/SendNFTContextProvider.spec.tsx(1 hunks)src/Components/Reusable/Send/Provider/SendNFTContextProvider.tsx(1 hunks)src/Components/Reusable/Send/Provider/index.ts(1 hunks)src/Constants/Theme/Colors.ts(3 hunks)src/Navigation/Stacks/HomeStack.tsx(3 hunks)src/Navigation/Stacks/NFTStack.tsx(3 hunks)src/Screens/Flows/App/NFT/NFTDetailScreen/NFTDetailScreen.tsx(2 hunks)src/Screens/Flows/App/NFT/SendNFTScreen/SendNFTScreen.tsx(1 hunks)src/Screens/Flows/App/NFT/SendNFTScreen/index.ts(1 hunks)src/Screens/Flows/App/NFT/index.ts(1 hunks)src/i18n/i18n-types.ts(6 hunks)src/i18n/translations/de.json(3 hunks)src/i18n/translations/en.json(3 hunks)src/i18n/translations/es.json(4 hunks)src/i18n/translations/fr.json(4 hunks)src/i18n/translations/hi.json(3 hunks)src/i18n/translations/it.json(3 hunks)src/i18n/translations/ja.json(4 hunks)src/i18n/translations/ko.json(3 hunks)src/i18n/translations/nl.json(3 hunks)src/i18n/translations/pl.json(4 hunks)src/i18n/translations/pt.json(5 hunks)src/i18n/translations/ru.json(4 hunks)src/i18n/translations/sv.json(3 hunks)src/i18n/translations/tr.json(3 hunks)src/i18n/translations/tw.json(3 hunks)src/i18n/translations/vi.json(2 hunks)src/i18n/translations/zh.json(3 hunks)
🧰 Additional context used
🧬 Code graph analysis (7)
src/Screens/Flows/App/NFT/SendNFTScreen/SendNFTScreen.tsx (8)
src/Navigation/Stacks/NFTStack.tsx (1)
RootStackParamListNFT(19-52)src/Utils/ReanimatedUtils/Reanimated.tsx (1)
wrapFunctionComponent(121-130)src/Hooks/useTheme/useTheme.tsx (2)
useTheme(8-27)useThemedStyles(29-32)src/Components/Reusable/HeaderButtons/CloseIconHeaderButton.tsx (1)
CloseIconHeaderButton(12-19)src/Screens/Flows/App/SendScreen/Animations/Entering.tsx (2)
EnteringFromRightAnimation(21-36)EnteringFromLeftAnimation(4-19)src/Screens/Flows/App/SendScreen/Animations/Exiting.tsx (2)
ExitingToLeftAnimation(4-23)ExitingToRightAnimation(25-44)src/Storage/Redux/Selectors/Nft.ts (1)
selectNFTWithAddressAndTokenId(121-136)src/Components/Reusable/Send/Provider/SendNFTContextProvider.tsx (1)
SendNFTContextProvider(12-75)
src/Navigation/Stacks/NFTStack.tsx (1)
src/Screens/Flows/App/NFT/SendNFTScreen/SendNFTScreen.tsx (1)
SendNFTScreen(159-171)
src/Navigation/Stacks/HomeStack.tsx (1)
src/Screens/Flows/App/NFT/SendNFTScreen/SendNFTScreen.tsx (1)
SendNFTScreen(159-171)
src/Screens/Flows/App/NFT/NFTDetailScreen/NFTDetailScreen.tsx (1)
src/Components/Providers/FeatureFlagsProvider.tsx (1)
useFeatureFlags(142-149)
src/Components/Collectibles/CollectiblesSendActionButton.tsx (1)
src/Components/Providers/FeatureFlagsProvider.tsx (1)
useFeatureFlags(142-149)
src/Components/Reusable/Send/Provider/SendNFTContextProvider.tsx (2)
src/Model/Nft/Nft.ts (1)
NonFungibleToken(22-27)src/Components/Reusable/Send/Provider/SendContextProvider.tsx (4)
SendFlowState(7-14)SendFlowStep(5-5)SendContextType(16-28)SendContext(30-30)
src/Components/Reusable/Send/Provider/SendContextProvider.tsx (2)
src/Model/Token/Token.ts (1)
FungibleTokenWithBalance(59-61)src/Model/Nft/Nft.ts (1)
NonFungibleToken(22-27)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: scan / unit (1)
- GitHub Check: scan / unit (2)
- GitHub Check: scan / unit (4)
- GitHub Check: scan / unit (3)
🔇 Additional comments (44)
src/i18n/translations/pt.json (2)
1061-1061: ✓ New translation keys are properly added for NFT send flow.The new keys (
SEND_COLLECTIBLE,SEND_RECEIVER,SEND_STEP_OF) align with the PR objectives for the two-step NFT sending process and generalized step formatting. Placeholder syntax ({currentStep: string},{totalSteps: string}) matches expected i18n patterns.Also applies to: 1126-1126, 1140-1141
1064-1064: The terminology used in the "SEND_CREATE_CONTACT_*" updates aligns consistently with terminology elsewhere in the file:
- "Endereço da carteira" (line 1064) matches the pattern used for wallet address fields (also at line 1129:
SEND_RECEIVER_ADDRESS_INPUT_LABEL)- "Nome" (line 1068) is the standard generic term for name fields (also at line 503:
COMMON_LBL_NAME), with "Nome do contato" used in other contact-specific contexts (line 197, 1069)- "Adicionar contato" (line 1072) matches the existing pattern for contact-related actions (also at line 319:
BTN_ADD_CONTACT)No terminology inconsistencies detected. The refinements follow established conventions in the Portuguese translation file.
src/Constants/Theme/Colors.ts (2)
880-892: Light theme mapping for send step colors is coherent with existing palette
stepText: COLORS.GREY_700andstepBackground: COLORS.GREY_200align with other light UI tokens (titles, chips, etc.) and should read fine on the app background. No issues from a theming/typing perspective.
1265-1277: Dark theme mapping for send step colors aligns with dark paletteUsing
GREY_100forstepTextoverPURPLE_DISABLEDbackground keeps consistency with other dark-surface tokens and should maintain contrast alongside the existing send screen card styling. Implementation matches theColorsshape defined above.src/i18n/translations/ja.json (1)
1054-1156: Send-flow Japanese translations and placeholders look consistentAll updated send-related strings (
SEND_ACCOUNTS_*,SEND_AMOUNT_EXCEEDS_BALANCE,SEND_COLLECTIBLE, theSEND_CREATE_CONTACT_*block,SEND_RECEIVER,SEND_RECENT_EMPTY_STATE_DESCRIPTION,SEND_STEP_OF,SEND_STEP_OF_3,SEND_TOKEN_SELECT,SEND_VOT3_WARNING) preserve the expected placeholders and match the intended UX semantics for the new NFT/send flow. I don’t see placeholder name or formatting issues here.src/i18n/translations/ko.json (1)
1054-1156: Korean send/NFT send translations align with the new flowThe updated send-related keys (
SEND_ACCOUNTS_*,SEND_COLLECTIBLE, theSEND_CREATE_CONTACT_*group,SEND_RECEIVER*,SEND_RECENT_EMPTY_STATE_DESCRIPTION,SEND_STEP_OF/SEND_STEP_OF_3,SEND_TOKEN_AMOUNT,SEND_TOKEN_SELECT,SEND_VOT3_WARNING) read naturally in Korean and keep the correct placeholder structure. They should integrate cleanly with the new two-step NFT send UI.src/i18n/translations/tr.json (1)
1141-1141: No changes needed—step-format rendering is correct across all locales.TR's "{stepNumber: string} / 3" uses the proper string placeholder type and localizes the connector appropriately (uses "/" instead of locale-specific prepositions like "de", "von", "van", etc.). The component calls
SEND_STEP_OF()with string parameters, and all 18 locales consistently define SEND_STEP_OF_3 with the same placeholder structure and locale-specific connectors. No hardcoded "of" assumptions exist.src/i18n/translations/fr.json (1)
1054-1156: NFT send & step translations look consistentThe new French strings for SEND_NFT (SEND_COLLECTIBLE, SEND_RECEIVER, SEND_STEP_OF and contact‑creation wording) are grammatically correct and consistent with existing terminology (“objet de collection”, “Destinataire”, “sur {totalSteps}”). No changes needed.
src/Screens/Flows/App/NFT/SendNFTScreen/index.ts (1)
1-1: Barrel export for SendNFTScreen is fineRe‑exporting from
"./SendNFTScreen"matches the pattern used elsewhere and cleanly exposes the NFT send screen.src/Screens/Flows/App/NFT/index.ts (1)
6-6: Including SendNFTScreen in the NFT barrel is appropriateAdding
export * from "./SendNFTScreen"keeps the NFT screens index in sync with the new send flow and matches existing export style.src/Components/Reusable/Send/Provider/index.ts (1)
1-2: Provider barrel cleanly exposes NFT send contextRe‑exporting
SendNFTContextProvideralongsideSendContextProviderfrom this index keeps the send providers discoverable from a single module and doesn’t introduce issues on its own.src/Navigation/Stacks/NFTStack.tsx (1)
34-37: Routes.SEND_NFT type is consistently defined across stacksThe
Routes.SEND_NFTroute type inRootStackParamListNFTmatches identical declarations inHomeStack, both defining{ contractAddress: string; tokenId: string }. All navigation calls (NFTDetailScreen,CollectiblesSendActionButton) pass the correct parameters, and screen registrations in both stacks are properly configured.src/Components/Reusable/Send/Provider/SendNFTContextProvider.spec.tsx (1)
1-149: Well-structured test coverage for the NFT context provider.The tests comprehensively cover the key functionality: initial state, NFT initialization, flow state updates, navigation transitions, boundary behavior, and button enable states. The
createWrapperpattern is clean and the tests properly useact()for state updates.src/Components/Reusable/Send/Provider/SendContextProvider.tsx (1)
3-30: Clean extension of the Send context to support NFT flow.The changes export existing types (
SendFlowState,SendContextType,SendContext) and add an optionalnftfield. This approach enables the newSendNFTContextProviderto share the same context type while maintaining backward compatibility with existing token send flows.src/i18n/translations/en.json (1)
1061-1061: Translation keys properly added for NFT send flow.The new keys (
SEND_COLLECTIBLE,SEND_RECEIVER,SEND_REVIEW_DETAILS,SEND_STEP_OF) follow existing naming conventions and support the new two-step NFT sending flow. The parameterizedSEND_STEP_OFis more flexible than the hardcodedSEND_STEP_OF_3.Also applies to: 1126-1126, 1140-1141
src/Screens/Flows/App/NFT/SendNFTScreen/SendNFTScreen.tsx (2)
65-93: Animation callbacks look correct.The
EnteringandExitingcallbacks properly handle the worklet context and use shared values for direction-based animations. The fallback to a no-op animation when steps are undefined is appropriate.
159-171: Screen wrapper correctly fetches NFT and provides context.The pattern of fetching the NFT via selector and wrapping content with the context provider is clean. Minor note:
nft ?? undefinedis redundant sincenftis alreadyNonFungibleToken | undefined, but it's harmless.src/Navigation/Stacks/HomeStack.tsx (1)
186-189: SEND_NFT route correctly added to HomeStack.The route definition matches the pattern in
NFTStack.tsxand the screen registration follows the same feature flag gating (betterWorldFeature.balanceScreen.collectibles.enabled) used by other collectibles screens. This maintains consistency across navigation stacks.Also applies to: 400-402
src/Components/Reusable/Send/Provider/SendNFTContextProvider.tsx (3)
1-10: LGTM on imports and type definitions.The imports are appropriate, and reusing
SendContextfrom the existing provider promotes consistency.SendNFTFlowStepcorrectly defines the two-step subset needed for NFT transfers.
12-23: State initialization and shared values are well-structured.The component correctly initializes state for the two-step NFT flow and reuses the animation tracking pattern from the existing send flow.
45-75: Context value memoization is appropriate.The
useMemocorrectly memoizes the context value with all required dependencies. The context correctly conforms toSendContextType, enabling reuse of existing send flow components.src/i18n/translations/pl.json (3)
1061-1061: New translation key for NFT collectible sending.The key
SEND_COLLECTIBLEis correctly added for the NFT send flow.
1126-1126: New receiver label translation added.
SEND_RECEIVERprovides a clear label for the receiver input in the NFT flow.
1140-1141: Flexible step indicator translations.
SEND_STEP_OFprovides a dynamic step format with{currentStep}and{totalSteps}parameters, whileSEND_STEP_OF_3is retained for backward compatibility with the existing 3-step token send flow.src/i18n/translations/nl.json (3)
1061-1061: Dutch translation for collectible sending added.
SEND_COLLECTIBLE: "Verzamelobject versturen"correctly translates the send collectible action.
1126-1126: Receiver label translation added.
SEND_RECEIVER: "Ontvanger"is the correct Dutch translation.
1140-1141: Step indicator translations are consistent.The
SEND_STEP_OFkey with"van"(Dutch for "of") correctly mirrors the pattern used in other language files.src/i18n/i18n-types.ts (4)
4348-4351: NewSEND_COLLECTIBLElabel and helper are consistent
SEND_COLLECTIBLEis correctly added toRootTranslationand mirrored inTranslationFunctionsas a zero‑arg helper, matching surrounding naming for send‑flow titles. No issues found.Also applies to: 10055-10058
4601-4604:SEND_RECEIVERkey cleanly adds a receiver step title
SEND_RECEIVERis added as a plain string inRootTranslationand as a zero‑arg function inTranslationFunctions, matching the surrounding send‑flow keys and giving a clear, reusable label for the receiver step.Also applies to: 10307-10310
4657-4660:SEND_REVIEW_DETAILSsummary‑step label is wired correctlyThe new
SEND_REVIEW_DETAILSstring and its corresponding helper function are consistent and align with the semantics of the review/summary step in the send flow; no typing or naming issues here.Also applies to: 10363-10366
4662-4666:SEND_STEP_OFparameterization is consistent across declarations and callsitesThe
SEND_STEP_OFkey usesRequiredParams<'currentStep' | 'totalSteps'>inRootTranslation(line 4666) and(arg: { currentStep: string, totalSteps: string }) => LocalizedStringinTranslationFunctions(line 10373), with full alignment. The callsite atSendNFTScreen.tsx:115-118correctly passes both parameters as strings via{ currentStep: stepInfo.currentStep.toString(), totalSteps: TOTAL_STEPS.toString() }, and all translation strings across supported locales use the matching{currentStep: string}and{totalSteps: string}placeholders.src/i18n/translations/de.json (13)
1054-1054: LGTM – formality standardization.Changing from informal "deiner" to formal "Ihrer" aligns with professional app conventions. The updated wording maintains clarity.
1057-1057: LGTM – appropriate grammatical form for section title.Using the noun form "Beobachtung" instead of the past participle "Beobachtet" is more suitable for a section header.
1059-1059: Verify translation consistency – AI summary vs. code mismatch.The AI summary claims a change from "überschreitet" to "übersteigt", but the code shows "übersteigt". Please confirm the intended wording. Both verbs are acceptable ("übersteigt" is slightly more technical/formal).
1061-1061: LGTM – contextually appropriate for NFT sending feature."Sammelobjekt senden" correctly translates the collectible/NFT sending action and aligns with existing collectible terminology throughout the app.
1062-1062: LGTM – improved copy with clearer benefits and consistent formality.The refined wording effectively communicates the benefit of adding contacts and maintains the formal tone.
1064-1064: LGTM – more precise terminology, pending consistency verification.Changing from "Kontaktadresse" to "Wallet-Adresse" is more technically precise for the input field. Verify this terminology is consistent across the send flow screens and other language files.
1067-1067: LGTM – clearer, more direct action description.The simplified wording is more direct and matches the action-oriented style of send flow UI.
1068-1068: LGTM – appropriate label simplification.Shortening from "Kontaktname" to "Name" reduces redundancy while maintaining clarity in the contact creation context.
1072-1072: LGTM – more semantically appropriate verb.Changing from "Kontakt erstellen" to "Kontakt hinzufügen" better reflects the action of saving a contact to an existing list, rather than creating a new entity.
1126-1126: LGTM – appropriate new label for receiver field."Empfänger" is a clear, contextually appropriate label for the receiver designation in the NFT send flow.
1138-1138: LGTM – clear and helpful empty state messaging.The message effectively explains the purpose of the recent recipients feature and guides users toward enabling it through normal usage.
1139-1139: LGTM – consistent and clear empty state title.Matches the pattern and style of other empty state titles in the send flow.
1140-1140: Update de.json step indicator format for NFT send flow.The
SEND_STEP_OFplaceholder format{currentStep: string} von {totalSteps: string}is correctly implemented and consistently localized across all 17 supported languages. However, note that this placeholder is only used in the NFT send flow (2 steps); the token send flow does not display step indicators to users, so cross-flow consistency verification is not applicable here.
|
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/i18n/i18n-types.ts (1)
4674-4678:SEND_RECEIVER_DETAILS_COUNTuses invalidRequiredParamssyntax and inconsistent patternThe current definition at both locations (lines 4674–4678 and 10417–10421) is incorrect:
Invalid type syntax:
RequiredParams<'current', 'total'>uses comma-separated arguments instead of a union. All otherRequiredParamsentries in the file useRequiredParams<'param1' | 'param2'>syntax. This should beRequiredParams<'current' | 'total'>.Inconsistent pattern in TranslationFunctions: Other parameterized entries like
ALERT_MSG_LAST_BACKUP_DATEfollow the pattern:
- RootTranslation:
RequiredParams<'date'>- TranslationFunctions:
(arg: { date: string }) => LocalizedString
SEND_RECEIVER_DETAILS_COUNTshould match this pattern with a function signature in TranslationFunctions.Fix in RootTranslation:
- SEND_RECEIVER_DETAILS_COUNT: RequiredParams<'current', 'total'> + SEND_RECEIVER_DETAILS_COUNT: RequiredParams<'current' | 'total'>Fix in TranslationFunctions:
- SEND_RECEIVER_DETAILS_COUNT: RequiredParams<'current', 'total'> + SEND_RECEIVER_DETAILS_COUNT: (arg: { current: number; total: number }) => LocalizedStringSince this file is auto-generated, this likely indicates a generator bug in typesafe-i18n v5.26.2. Verify the fix doesn't conflict with the generator by running
yarn i18n:typesafter making changes.src/i18n/translations/tw.json (1)
1181-1185: Fix Simplified Chinese in TW locale (visible i18n defect).These strings use Simplified characters (“默认/网址/选择/删除”), which is inconsistent with the rest of zh‑TW.
- "SETTINGS_TRANSACTIONS_DEFAULT_DELEGATION": "默认委托", - "SETTINGS_TRANSACTIONS_MANAGE_URLS": "管理网址", - "SETTINGS_TRANSACTIONS_SELECT_DEFAULT_DELEGATION": "选择交易的默认委托", - "SETTINGS_TRANSACTIONS_SELECT_DELEGATION_URLS": "委托网址", - "SETTINGS_TRANSACTIONS_SELECT_DELEGATION_URLS_BODY": "添加或删除委托网址，以便在发送交易时选择", + "SETTINGS_TRANSACTIONS_DEFAULT_DELEGATION": "預設委託", + "SETTINGS_TRANSACTIONS_MANAGE_URLS": "管理網址", + "SETTINGS_TRANSACTIONS_SELECT_DEFAULT_DELEGATION": "選擇交易的預設委託", + "SETTINGS_TRANSACTIONS_SELECT_DELEGATION_URLS": "委託網址", + "SETTINGS_TRANSACTIONS_SELECT_DELEGATION_URLS_BODY": "新增或刪除委託網址，以便在發送交易時選擇",
🧹 Nitpick comments (1)
src/Constants/Theme/Colors.ts (1)
900-901: Good color choices for light theme.The stepText (GREY_700) on stepBackground (GREY_200) pairing provides appropriate contrast for readability in the light theme.
Consider verifying that the color contrast ratio meets WCAG AA standards (4.5:1 for normal text) for accessibility:
#!/bin/bash # Description: Check contrast ratio between stepText and stepBackground # This uses a simple Python script to calculate contrast ratio python3 << 'EOF' def hex_to_rgb(hex_color): hex_color = hex_color.lstrip('#') return tuple(int(hex_color[i:i+2], 16) for i in (0, 2, 4)) def relative_luminance(rgb): r, g, b = [x / 255.0 for x in rgb] r = r / 12.92 if r <= 0.03928 else ((r + 0.055) / 1.055) ** 2.4 g = g / 12.92 if g <= 0.03928 else ((g + 0.055) / 1.055) ** 2.4 b = b / 12.92 if b <= 0.03928 else ((b + 0.055) / 1.055) ** 2.4 return 0.2126 * r + 0.7152 * g + 0.0722 * b def contrast_ratio(color1, color2): lum1 = relative_luminance(hex_to_rgb(color1)) lum2 = relative_luminance(hex_to_rgb(color2)) lighter = max(lum1, lum2) darker = min(lum1, lum2) return (lighter + 0.05) / (darker + 0.05) # Light theme colors - you'll need to replace these with actual hex values from COLORS enum # GREY_700 and GREY_200 grey_700 = "#363A3F" # Example value, verify actual color grey_200 = "#E7E9EB" # Example value, verify actual color ratio = contrast_ratio(grey_700, grey_200) print(f"Light theme contrast ratio: {ratio:.2f}:1") print(f"WCAG AA (normal text): {'✓ PASS' if ratio >= 4.5 else '✗ FAIL'}") print(f"WCAG AA (large text): {'✓ PASS' if ratio >= 3.0 else '✗ FAIL'}") EOF
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (20)
src/Components/Reusable/Send/Provider/SendContextProvider.tsx(3 hunks)src/Constants/Theme/Colors.ts(3 hunks)src/i18n/i18n-types.ts(6 hunks)src/i18n/translations/de.json(4 hunks)src/i18n/translations/en.json(3 hunks)src/i18n/translations/es.json(4 hunks)src/i18n/translations/fr.json(5 hunks)src/i18n/translations/hi.json(4 hunks)src/i18n/translations/it.json(4 hunks)src/i18n/translations/ja.json(3 hunks)src/i18n/translations/ko.json(4 hunks)src/i18n/translations/nl.json(4 hunks)src/i18n/translations/pl.json(3 hunks)src/i18n/translations/pt.json(4 hunks)src/i18n/translations/ru.json(4 hunks)src/i18n/translations/sv.json(3 hunks)src/i18n/translations/tr.json(4 hunks)src/i18n/translations/tw.json(4 hunks)src/i18n/translations/vi.json(3 hunks)src/i18n/translations/zh.json(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (12)
- src/i18n/translations/pt.json
- src/Components/Reusable/Send/Provider/SendContextProvider.tsx
- src/i18n/translations/it.json
- src/i18n/translations/sv.json
- src/i18n/translations/fr.json
- src/i18n/translations/de.json
- src/i18n/translations/hi.json
- src/i18n/translations/vi.json
- src/i18n/translations/en.json
- src/i18n/translations/ru.json
- src/i18n/translations/nl.json
- src/i18n/translations/tr.json
🔇 Additional comments (21)
src/i18n/translations/pl.json (2)
1137-1137: Verify intent: SEND_RECEIVER_DETAILS and SEND_REVIEW_DETAILS share identical translations.Both keys have the same Polish text ("Przejrzyj szczegóły"). Confirm whether this duplication is intentional or if they should be differentiated in the UI/flow context.
Also applies to: 1146-1146
1130-1130: Translation additions for NFT send flow look good.The remaining translations are grammatically sound and follow established Polish conventions for the wallet UI:
- SEND_RECEIVER: "Odbiorca" (correct receiver label)
- SEND_STEP_OF: "{currentStep: string} z {totalSteps: string}" (consistent step numbering format)
- SEND_STEP_OF_3: Specialized variant retained for backward compatibility
Also applies to: 1147-1147, 1148-1148
src/i18n/translations/ko.json (3)
1147-1147: Verify placeholder naming consistency across translation keys.The new
SEND_STEP_OFkey uses placeholders{currentStep}and{totalSteps}, while the similarSEND_RECEIVER_DETAILS_COUNTkey (line 1138) uses{current}and{total}. Confirm this naming variation is intentional and matches the corresponding component code that will use these translations.
1137-1137: Confirm duplicate translation values are intentional.Both
SEND_RECEIVER_DETAILS(line 1137) andSEND_REVIEW_DETAILS(line 1146) translate to the same Korean text: "세부 정보 검토". Verify this duplication is intentional or if these keys serve distinctly different UI contexts that happen to use the same translation.Also applies to: 1146-1146
463-465: JSON structure and translation key additions look good.The new translation keys follow the existing naming conventions (
SEND_*prefix), are properly formatted JSON, and are correctly positioned alphabetically within the file. All changes support the NFT send flow feature described in the PR.Also applies to: 1065-1065, 1130-1130, 1137-1137, 1146-1147
src/Constants/Theme/Colors.ts (2)
1290-1291: LGTM! Dark theme implementation is consistent.The dark theme colors for stepText (GREY_100) and stepBackground (PURPLE_DISABLED) maintain proper contrast and are consistent with the overall dark theme design system.
385-386: LGTM! Migration successfully verified.The restructuring of stepText to the sendScreen level and addition of stepBackground is properly implemented. All references have been correctly updated:
- Type definition at lines 385-386
- Light theme at lines 900-901 (GREY_700 on GREY_200)
- Dark theme at lines 1290-1291 (GREY_100 on PURPLE_DISABLED)
- Active usage in SendNFTScreen.tsx (lines 109-110)
No stale references to the old
tokenAmountCard.stepTextremain in the codebase.src/i18n/i18n-types.ts (3)
4368-4395: New send-contact & collectible i18n keys are consistent and correctly wired
SEND_COLLECTIBLE,SEND_CREATE_CONTACT_ADDRESS_PLACEHOLDER,SEND_CREATE_CONTACT_DESCRIPTION, andSEND_CREATE_CONTACT_NAME_PLACEHOLDERare added to bothRootTranslation(asstring) andTranslationFunctions(as zero‑arg functions) with matching names and expected semantics. This keeps the send/contact flow type‑safe and aligned with existing SEND_* patterns. No changes needed.Also applies to: 10112-10139
4622-4624:SEND_RECEIVERlabel is correctly exposed in both translation surfacesThe new
SEND_RECEIVERkey is added as a plain string inRootTranslationand as() => LocalizedStringinTranslationFunctions, matching how other section titles are modelled. This will give the receiver step its own dedicated, reusable label without type holes. Looks good.Also applies to: 10365-10367
4688-4696: Step/summary keys for the new send flow are well‑typed
SEND_REVIEW_DETAILSandSEND_STEP_OFare introduced inRootTranslationand mirrored inTranslationFunctionswith an explicit arg object{ currentStep, totalSteps }. TheRequiredParams<'currentStep' | 'totalSteps'>usage matches the function signature and placeholder names in the JSDoc, so consumers will get proper type guidance when formatting step indicators. No issues spotted here.Also applies to: 10431-10437
src/i18n/translations/zh.json (2)
463-465: LGTM on alert copy tweaks.Wording reads naturally and keeps placeholders intact.
1137-1148: New SEND_ labels look consistent.*Placeholders/types and punctuation are correct; duplication of “查看详情” for both keys is acceptable.
src/i18n/translations/es.json (4)
463-466: LGTM on alerts.Clear and idiomatic phrasing; placeholders preserved.
1065-1065: LGTM for SEND_COLLECTIBLE.Matches “Coleccionables” elsewhere.
1130-1131: LGTM for receiver labels.“Destinatario” and “Revisar detalles” are consistent across the flow.
Also applies to: 1137-1137
1146-1148: LGTM for step formatting.Types and ordering look good: “{currentStep: string} de {totalSteps: string}”.
src/i18n/translations/tw.json (3)
463-465: LGTM on alert wording.Natural Traditional Chinese; no placeholder drift.
1065-1065: LGTM for SEND_COLLECTIBLE.Terminology matches “收藏品” usage elsewhere.
1130-1131: LGTM for receiver and step labels.Consistent terms and typed placeholders.
Also applies to: 1137-1137, 1146-1148
src/i18n/translations/ja.json (2)
464-466: LGTM on alert copy.Minor wording tweak reads fine; semantics unchanged.
1065-1065: LGTM for SEND_COLLECTIBLE.Term aligns with “コレクティブル”.
| "SEND_RECEIVER_ADD_CONTACT_BTN": "この新しいアドレスを連絡先に追加する", | ||
| "SEND_RECEIVER_DETAILS": "詳細を確認", | ||
| "SEND_RECEIVER_DETAILS_COUNT": "{current} / {total}", | ||
| "SEND_RECEIVER_DETAILS_COUNT": "{current}／{total}", |
There was a problem hiding this comment.
Restore placeholder types and use ASCII slash for consistency.
Other locales keep typed placeholders; “／” also differs from the rest of the UI (“/”).
- "SEND_RECEIVER_DETAILS_COUNT": "{current}／{total}",
+ "SEND_RECEIVER_DETAILS_COUNT": "{current: number} / {total: number}",🤖 Prompt for AI Agents
src/i18n/translations/ja.json around line 1138: the translation currently uses a
fullwidth slash and untyped placeholders ("{current}／{total}"); change it to use
ASCII slash and typed placeholders consistent with other locales, e.g.
"{current, number}/{total, number}", so restore the placeholder types and
replace "／" with "/".
| "SEND_REVIEW_DETAILS": "詳細を確認", | ||
| "SEND_STEP_OF": "{currentStep}／{totalSteps}", | ||
| "SEND_STEP_OF_3": "{stepNumber} / 3", |
There was a problem hiding this comment.
Unify placeholder typing and slash style in SEND_STEP_OF.
Match other locales’ typed placeholders and ASCII slash.
- "SEND_STEP_OF": "{currentStep}／{totalSteps}",
+ "SEND_STEP_OF": "{currentStep: string} / {totalSteps: string}",📝 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.
| "SEND_REVIEW_DETAILS": "詳細を確認", | |
| "SEND_STEP_OF": "{currentStep}／{totalSteps}", | |
| "SEND_STEP_OF_3": "{stepNumber} / 3", | |
| "SEND_REVIEW_DETAILS": "詳細を確認", | |
| "SEND_STEP_OF": "{currentStep: string} / {totalSteps: string}", | |
| "SEND_STEP_OF_3": "{stepNumber} / 3", |
🤖 Prompt for AI Agents
In src/i18n/translations/ja.json around lines 1146 to 1148, the SEND_STEP_OF
entry uses fullwidth slash and untyped placeholder names
("{currentStep}／{totalSteps}"), which is inconsistent with other locales; change
the value to use typed placeholders and an ASCII slash exactly like other
locales, e.g. "{stepNumber} / {totalSteps}" so the placeholder names and slash
style match existing translations.
| "SEND_AMOUNT": "Kwota", | ||
| "SEND_AMOUNT_EXCEEDS_BALANCE": "Kwota przekracza saldo", | ||
| "SEND_BALANCE_PERCENTAGE": "Procent salda: {percentage: string}", | ||
| "SEND_COLLECTIBLE": "Wyślij kolekcjonowalny", |
There was a problem hiding this comment.
Fix incomplete Polish grammar in SEND_COLLECTIBLE translation.
The phrase "Wyślij kolekcjonowalny" is grammatically incomplete—the adjective requires a noun. Consider "Wyślij zbieralny" or "Wyślij przedmiot kolekcji" to provide a complete, actionable label.
🤖 Prompt for AI Agents
In src/i18n/translations/pl.json around line 1065, the translation value for
"SEND_COLLECTIBLE" is grammatically incomplete ("Wyślij kolekcjonowalny");
replace it with a complete, natural Polish phrase such as "Wyślij przedmiot
kolekcji" (or "Wyślij przedmiot kolekcjonerski") by updating the string value to
one of those options so the label is actionable and grammatically correct.
| "SEND_AMOUNT": "金额", | ||
| "SEND_AMOUNT_EXCEEDS_BALANCE": "金额超出余额", | ||
| "SEND_BALANCE_PERCENTAGE": "余额百分比: {percentage: string}", | ||
| "SEND_COLLECTIBLE": "发送藏品", |
There was a problem hiding this comment.
Unify “collectible” term across zh to avoid inconsistency.
Elsewhere you use “收藏品”; here it’s “藏品”. Align to “收藏品”.
- "SEND_COLLECTIBLE": "发送藏品",
+ "SEND_COLLECTIBLE": "发送收藏品",📝 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.
| "SEND_COLLECTIBLE": "发送藏品", | |
| "SEND_COLLECTIBLE": "发送收藏品", |
🤖 Prompt for AI Agents
In src/i18n/translations/zh.json around line 1065 the key "SEND_COLLECTIBLE"
uses the term "藏品" which is inconsistent with the rest of the zh translations
that use "收藏品"; update the value to "发送收藏品" to unify terminology across the
locale.
| "SEND_PLEASE_TYPE_ADDRESS": "请输入地址或 .vet 域名", | ||
| "SEND_RANGE_MAX": "最大", | ||
| "SEND_RANGE_ZERO": "0%", | ||
| "SEND_RECEIVER": "接收方", |
There was a problem hiding this comment.
Use the same receiver term as the rest of the UI.
Most strings use “接收者”, not “接收方”.
- "SEND_RECEIVER": "接收方",
+ "SEND_RECEIVER": "接收者",🤖 Prompt for AI Agents
In src/i18n/translations/zh.json around line 1130 the key "SEND_RECEIVER" uses
the term "接收方" which is inconsistent with the rest of the UI that uses "接收者";
update the value to "接收者" to match existing translations and maintain
consistency across the interface.
Related Issue
Closes veworld/veworld-private#574
Description of Changes
Add wrapper for NFT send flow
Reviewer(s)
@Doublemme @hughlivingstone @HiiiiD
UI/UX Changes
Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-12-05.at.10.21.32.mp4
Checklist
Thank you for contributing! 🎉
Summary by CodeRabbit
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.