Add Seasons #286
Add Seasons #286
Conversation
- add banner displaying season information
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Caution Review failedThe pull request is closed. WalkthroughThis pull request introduces significant changes to the LootSurvivor UI, focusing on tournament functionality and user experience. The modifications include adding tournament-related components, updating environment configurations, introducing new GraphQL queries, and enhancing state management. Key changes involve implementing a new season entry mechanism, adding a login dialog, creating toast notifications, and updating various UI components to support tournament interactions. Changes
Sequence DiagramsequenceDiagram
participant User
participant UI
participant LoginDialog
participant TournamentContract
participant GraphQL
User->>UI: Starts Application
UI->>LoginDialog: Show Login Options
User->>LoginDialog: Select Wallet
LoginDialog->>TournamentContract: Connect Wallet
UI->>GraphQL: Fetch Tournament Details
GraphQL-->>UI: Return Tournament Data
UI->>User: Display Season Details and Prizes
User->>UI: Enter Season
UI->>TournamentContract: Start Season Transaction
TournamentContract-->>UI: Transaction Confirmation
UI->>User: Show Success Toast Notification
Possibly Related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (5)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (55)
ui/src/app/components/onboarding/Intro.tsx (1)
61-62: Multiple state updates in immediate succession – ensure the desired order of operations.Currently,
setScreen("start"),handleOnboarded(), andsetNetwork()happen back-to-back. If any of these depend on the result of a previous call, consider consolidating them into a single function or adding appropriate checks, ensuring correct user flow. Otherwise, this is fine as is.ui/src/app/components/start/AdventurerName.tsx (1)
32-47: Minor improvements for maintainability and accessibility
Consolidate repeated utility classes
You have"flex flex-col"repeated multiple times (e.g.,"flex flex-col items-center uppercase flex flex-col") on line 32. Consider removing duplicates to simplify your utility classes.Use a constant for maximum length
Instead of hard-coding31in multiple places, store it in a declared constant (e.g.,const MAX_NAME_LENGTH = 31;). This makes the code more maintainable if the limit changes later.Enhance accessibility with a label
The<p>element containing"Name"could be replaced or supplemented by a<label>associated with the<input>for better screen-reader support.ui/src/app/components/start/CreateAdventurer.tsx (4)
64-68: GraphQL query usage.
UsinguseQuerywith custom variables and a custom client is consistent. Double-check that potential fetch or network errors are being handled in the parent component or a global error boundary.
69-69: Consider removing console statements.
While debug logs can help during development, consider removing or replacingconsole.logwith a logger to avoid exposing sensitive data in production logs.
113-133: Robust error handling in handleNameEntry.
Thetry/catchblock provides a good approach to handle spawn errors. Ensure the user receives appropriate feedback on spawn failures. Possibly propagate the error upward or display a toast to inform the user of the issue.
148-164: Clear and concise UI explaining the new season.
The heading, description, andPrizescomponent integration are straightforward and user-friendly. Ensure the text referencing “$100 LORDS” remains up-to-date if the prize pool changes.ui/src/app/lib/utils/index.ts (1)
86-93: stringToFelt for flexible conversion.
UsingTextEncoderis a straightforward approach. Mind special characters and large strings. Potentially handle edge cases like empty strings or extremely large strings that exceed on-chain constraints.ui/src/app/lib/utils/syscalls.ts (1)
306-312: lordsDollarValue integration.
Fetching the Lords price withpragmaContract.callis coherent with the rest of the pricing logic. However, handle potential call rejections. Consider caching or rate-limiting calls, given how frequently the price might be requested.ui/src/app/hooks/useCustomQuery.ts (1)
24-28: **Memoization ofgameClient. **
Memoizing based on thenetworkis efficient. However, iflsGQLURLchanges for the same network at runtime (e.g. a config update), the client won't re-initialize. If that's expected, then this is fine. Otherwise, consider adding more dependencies to the array:-}, [network]); +}, [network, networkConfig[network!].lsGQLURL]);ui/src/app/provider.tsx (1)
2-3: **Connector import usage. **
Since you're already importingcartridgeConnector, consider removing any unusedChain,mainnet, orsepoliaimports if they aren’t needed elsewhere. It helps keep the file uncluttered.ui/src/app/components/onboarding/LoginDialog.tsx (2)
12-15: **Layer styling. **
The overlay style logic is straightforward. If multiple modals or overlays exist, consider using a higher layering approach (e.g. uniquez-index) to avoid overlap conflicts.
27-39: **Connector button iteration. **
Enumeratingconnectorsto present wallet options is excellent. For better user experience, consider revealing friendly wallet names whenconnector.nameor a more descriptive text thanidis available.ui/src/app/components/leaderboard/SeasonRow.tsx (4)
7-10: Consider adding validation for adventurer props
Your component relies on a non-null/defined Adventurer object, specifically referencing fields likeid,xp, etc. If there's any chance the data could be partially loaded or null, adding a type guard or default fallback values will help prevent rendering errors.
22-25: Use a stable or memoized approach for sorting
The creation of atopScoresarray on each render might trigger re-sorting. While this is likely benign in most cases, if the list of adventurers grows, consider using a memoization hook such asuseMemoto avoid redundant sorts.
29-35: Ensure maintainable styling strategies
You are applying multiple conditional classes to handle styling for top-scorer or owned adventurer. For scalability and maintainability, consider extracting these conditions into a small helper function or using a styling library that supports conditional class application more systematically (e.g., clsx).
36-39: Optional: Provide feedback on row selection
Beyond playing a sound effect, you could highlight the selected row or show a subtle UI feedback. This helps users confirm their action, especially on slower connections where clicking may not result in an immediate navigation or state change.ui/src/app/lib/connectors.ts (1)
105-112: Extended policies can introduce future maintainability needs
You’ve added new policy objects for tournament actions, which is good for modularity. Over time, if many methods are introduced, consider externalizing these policies into a configurable object or JSON to reduce overhead in the code.ui/src/app/layout.tsx (2)
12-12: Ensure fallback or error handling for failing clients
In case thetournamentClientorgameClientinitialization fails, consider providing a fallback UI or error boundary. This helps avoid potential unhandled exceptions in the event of misconfiguration or network issues.
86-96: Nested ApolloProviders
You are nesting two distinct ApolloProviders. This can be valid if you require separate caches or schemas. However, ensure the correct provider is used by child components to avoid confusion. If your services share overlapping schema types, consider using a single Apollo client configured for both endpoints.ui/src/app/components/start/SeasonDetails.tsx (3)
4-64: Refactor repeated layout logic
You’ve structured the prize sections (1st, 2nd, 3rd place) in a repeated pattern. If these sections multiply or become more complex, consider extracting them into a small, reusable component that receives props like rank, amount, and icon.
66-83: Promote reusability with SeasonDetails
The layout’s logic is minimal right now (renderingSeasonTableplus an optional payment container). Should additional conditions be added, consider a sub-component or hooking into a global store for toggling and dynamic display.
70-81: Confirm commented-out code relevancy
There’s a block of commented-out code suggesting conditional rendering for payment details. If it’s future-facing, consider a TODO note or a feature flag approach. If it’s deprecated, remove it to maintain code cleanliness.ui/src/app/components/start/Prizes.tsx (6)
6-9: Use explicit typing for stronger type safety.
Currently,prizes: anymight obscure details about the structure ofprizes. Consider defining a more specific type or interface for improved maintainability.interface Prizes { - prizes: any; + prizes: { + lsTournamentsV0TournamentPrizeModels: { + edges: Array<{ + node: { + payout_position: number; + token: string; + token_data_type: { + option: string; + erc20?: { token_amount?: string }; + erc721?: { token_id?: string }; + }; + }; + }>; + }; + }; lordsDollarValue: () => Promise<bigint>; }
15-18: Ensure error handling forlordsDollarValue.
Async calls can fail or reject. Consider surrounding the call with a try/catch block or rejecting gracefully.async function handleLordsDollarValue() { try { const value = await lordsDollarValue(); setLordsDollar(value); } catch (error) { + console.error("Failed to fetch Lords dollar value:", error); + // Possibly handle fallback or set a default value } }
20-23: Validate thatlordsDollarValueis called only once.
This effect runs once on mount. If you ever need updates, consider addinglordsDollarValueto dependencies.
27-38: Check for large data sets inreduce.
Ifprizescould contain large arrays, consider more efficient grouping approaches to avoid potential performance bottlenecks.
36-36: Remove or transform debug logs.
console.log(acc);could clutter logs in production. Use a proper logger or remove if unnecessary.- console.log(acc);
46-89: Enhance ERC20 vs. ERC721 logic clarity.
The code is straightforward, but you could unify the display logic or factor repeated code into separate, well-named functions.ui/src/app/containers/LeaderboardScreen.tsx (2)
92-92: Rename button label or maintain consistently.
Currently labeled “Scores” vs. “Beast Leaderboard.” The naming is fine, but confirm it reflects the final intended UI.
102-105: Validate potential re-fetching overhead.
SeasonTableusage is straightforward. Consider lazy-loading or progressive loading if the data set is large, or add pagination if not already implemented.ui/src/app/hooks/useToast.ts (5)
11-12: Customizable toast limit & remove delay.
1 toast limit is sometimes too low for typical usage. Evaluate if you want multiple concurrent messages.
14-19: Optional fields liketitle,description,action.
Your approach is flexible. Ensure typical usage includes sensible defaults.
30-33:genId()approach is simple but sufficient.
No concerns for collisions as long as it remains single-process. For distributed or server usage, consider a more robust ID.
136-141:dispatchtriggers updates for all listeners.
In high-traffic situations, ensure performance remains acceptable.
145-172:toastfunction usage is flexible.
updateanddismissclosures are helpful.- Consider adding an auto-dismiss option with a configurable duration.
ui/src/app/containers/AdventurerScreen.tsx (3)
26-33: Consider clarifying the difference betweencostToPlayandseasonCost.
If these values represent different fees or cost structures, ensure that the consumer of this interface can distinguish them. Otherwise, you risk merging conceptually overlapping costs, which could cause confusion.
55-55: Ensure thestartSeasoncallback is properly tested.
Since you’re introducing a new function into this component, consider adding or updating unit tests to confirm that it’s bound and called correctly, especially within theCreateAdventurercomponent.
130-131: Adjust the container width for small screens.
While switching from a column to a row layout, ensure that text or buttons don’t become too cramped on narrower devices. A responsive approach (e.g., conditional wrapping or text truncation) might improve usability.ui/src/app/components/season/toast.tsx (3)
27-42: Refine yourtoastVariantsutility for clarity.
Thedestructivevariant is correct; however, consider adding other possible variants (success, warning, info) if your design calls for them. This helps avoid scattering similar styling logic throughout the codebase in the future.
92-103: Promote consistent typography across the app.
Your toasts use a specific text class. If your product uses a design system or style guide, make sure the text aligns with its guidelines for headings or subheadings.
116-119: Validate newly introduced type definitions.
YourToastActionElementandToastPropsmay benefit from additional doc comments to clarify typical usage and constraints.ui/src/app/components/leaderboard/SeasonTable.tsx (3)
16-20: Document the prop usage.
Briefly describe in JSDoc howitemsPerPage,handleFetchProfileData, andadventurerCountare intended to be used. Future maintainers will appreciate the clarity.
22-26: Consider naming consistency.
SeasonTableandSeasonRoware consistent, but if the functions will handle other states or tables in the future, keep the naming flexible.
71-80: Look into concurrency forhandleRowSelected.
IfhandleFetchProfileDatatriggers multiple fetches or a heavy network call, consider a loading state or concurrency safeguards to avoid inconsistent UI states when quickly selecting multiple rows.ui/src/app/lib/networkConfig.ts (2)
86-86: Leave notes onkatanaenvironment usage.
You set thetournamentGQLURLto an empty string here. If you eventually add support for tournaments on Katana, you’ll need to update this field to the relevant endpoint.
98-99: ValidatetournamentAddressfor the Katana environment.
If this is always"0x0", consider if the code that reads this address gracefully handles no-op states or uses mocks for local dev.ui/src/app/components/start/PaymentDetails.tsx (1)
Line range hint
13-145: Refactored payment layout and updated cost/payout details.
Hard-coded values like "$3.50" might break if prices or payout shares change. Consider passing these values as dynamic props or retrieving them from a configuration to ensure future flexibility and avoid duplication.ui/src/app/hooks/graphql/queries.ts (3)
245-256: Consider paginated fetching.
While querying up to 1000 records is often acceptable, consider adding or using existing pagination to handle large data sets more efficiently and avoid potential performance bottlenecks.
499-514: Consider paginated fetching for tournament games.
Similarly, the 1000-record limit is reasonable but can become a bottleneck for larger tournaments. Implement a cursor or offset-based approach if you expect many records.
516-542: Consider paginated fetching for tournament prizes.
The approach forgetTournamentPrizesis consistent with other queries, but you may need pagination if the number of prizes grows significantly.ui/src/app/components/start/Spawn.tsx (2)
231-242: Inline “Play” block.
This new block gives a clear call-to-action button. Ensure you handle any disabled or loading states if the user is not ready or can’t start the season.
346-346: Bottom bar controls.
Adding the “Back” button near the bottom is helpful. Consider conditional disabling if you need the user to complete certain steps first.ui/src/app/page.tsx (1)
778-782: New Season 0 toast message.
Announcing season startup is a nice addition to user engagement. Verify that the environment variable or flags controlling feature availability are aligned with this message.ui/src/app/components/start/WeaponSelect.tsx (2)
66-71: Enhance accessibility for weapon selectionThe weapon selection UI could benefit from improved accessibility:
className={`flex flex-col gap-1 items-center justify-center w-20 sm:w-28 hover:cursor-pointer hover:bg-terminal-green hover:text-terminal-black p-1 sm:p-2 ${ formData.startingWeapon == weapon.name ? "bg-terminal-green text-terminal-black" : "border border-terminal-green" -}`} -onClick={() => handleWeaponSelectionDesktop(weapon.name)} +}`} +onClick={() => handleWeaponSelectionDesktop(weapon.name)} +onKeyDown={(e) => e.key === 'Enter' && handleWeaponSelectionDesktop(weapon.name)} +role="button" +tabIndex={0} +aria-label={`Select ${weapon.name} as your weapon`} +aria-selected={formData.startingWeapon === weapon.name}
58-74: Add loading and error states for weapon selectionThe weapon selection UI could be enhanced with loading and error states to improve user experience:
Consider adding:
- Loading state while weapon selection is being processed
- Error handling for failed selections
- Visual feedback for successful selection
Would you like me to provide an implementation example?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (7)
.DS_Storeis excluded by!**/.DS_Storeui/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlui/public/icons/classic-logo.svgis excluded by!**/*.svgui/public/icons/close.svgis excluded by!**/*.svgui/public/icons/plus.svgis excluded by!**/*.svgui/public/icons/tournament-trophy.svgis excluded by!**/*.svgui/yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (37)
ui/.env(1 hunks)ui/components.json(1 hunks)ui/package.json(3 hunks)ui/src/app/components/icons/Icons.tsx(4 hunks)ui/src/app/components/leaderboard/ScoreTable.tsx(2 hunks)ui/src/app/components/leaderboard/SeasonRow.tsx(1 hunks)ui/src/app/components/leaderboard/SeasonTable.tsx(1 hunks)ui/src/app/components/navigation/Header.tsx(3 hunks)ui/src/app/components/onboarding/Intro.tsx(2 hunks)ui/src/app/components/onboarding/LoginDialog.tsx(1 hunks)ui/src/app/components/season/toast.tsx(1 hunks)ui/src/app/components/season/toaster.tsx(1 hunks)ui/src/app/components/start/AdventurerName.tsx(2 hunks)ui/src/app/components/start/CreateAdventurer.tsx(3 hunks)ui/src/app/components/start/PaymentDetails.tsx(3 hunks)ui/src/app/components/start/Prizes.tsx(1 hunks)ui/src/app/components/start/SeasonDetails.tsx(1 hunks)ui/src/app/components/start/Spawn.tsx(7 hunks)ui/src/app/components/start/WeaponSelect.tsx(1 hunks)ui/src/app/containers/AdventurerScreen.tsx(5 hunks)ui/src/app/containers/LeaderboardScreen.tsx(3 hunks)ui/src/app/globals.css(1 hunks)ui/src/app/hooks/graphql/queries.ts(3 hunks)ui/src/app/hooks/useCustomQuery.ts(2 hunks)ui/src/app/hooks/useToast.ts(1 hunks)ui/src/app/hooks/useUIStore.ts(3 hunks)ui/src/app/layout.tsx(2 hunks)ui/src/app/lib/clients.ts(1 hunks)ui/src/app/lib/connectors.ts(3 hunks)ui/src/app/lib/constants.ts(1 hunks)ui/src/app/lib/networkConfig.ts(8 hunks)ui/src/app/lib/utils/index.ts(1 hunks)ui/src/app/lib/utils/syscalls.ts(10 hunks)ui/src/app/page.tsx(6 hunks)ui/src/app/provider.tsx(2 hunks)ui/src/lib/utils.ts(1 hunks)ui/tailwind.config.js(2 hunks)
✅ Files skipped from review due to trivial changes (2)
- ui/.env
- ui/src/app/globals.css
🔇 Additional comments (103)
ui/src/app/components/onboarding/Intro.tsx (1)
9-10: Ensure the removal ofsetLoginScreenaligns with all usage in the codebase.With
setLoginScreenremoved here, please confirm no references tosetLoginScreenremain elsewhere. Otherwise, it may lead to runtime errors or regression in login flow.✅ Verification successful
setLoginScreenis still being used in the codebase but removed from Intro componentThe verification reveals that
setLoginScreenis actively used in the codebase:
- Defined in
ui/src/app/hooks/useUIStore.tsas part of the store interface and implementation- Used in
ui/src/app/components/navigation/Header.tsxfor login flow controlLet's verify if the removal from Intro.tsx is intentional by checking its usage history:
Let's try a different approach to understand the context better:
The removal of
setLoginScreenfrom Intro.tsx appears intentional and safeAfter reviewing the codebase:
- The
setLoginScreenis properly defined inuseUIStore.tsand is still available in the store- It's currently only used in
Header.tsxfor login flow control- The
Intro.tsxcomponent doesn't show any signs of needing login functionality - it's focused on onboarding and network selection- The removal from
Intro.tsxappears to be a clean-up of an unused import🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Searches for any references to `setLoginScreen` that might still be present. rg 'setLoginScreen'Length of output: 377
Script:
#!/bin/bash # Check the git history of Intro.tsx to understand the context of removal git log -L :setLoginScreen:ui/src/app/components/onboarding/Intro.tsx # Also check how setLoginScreen was used in Intro.tsx rg -B 3 -A 3 'setLoginScreen' ui/src/app/components/onboarding/Intro.tsxLength of output: 72
Script:
#!/bin/bash # Check the current implementation of Intro.tsx cat ui/src/app/components/onboarding/Intro.tsx # Also check the store implementation to understand the relationship cat ui/src/app/hooks/useUIStore.tsLength of output: 13316
ui/src/app/components/start/AdventurerName.tsx (1)
2-2: Imports look good!
The addition ofChangeEventanduseStatefrom "react" is appropriate for the newhandleChangelogic and local state management.ui/src/app/components/start/CreateAdventurer.tsx (7)
1-3: Import usage appears consistent.
The newly added imports forPrizesand other dependencies are properly structured. No immediate issues spotted.
6-10: Tournament-related imports.
Good practice importing thetournamentClient,networkConfig, and GraphQL-related hooks here for improved separation of concerns. Ensure to handle loading and error states gracefully for each GraphQL operation.
20-26: Ensure prop type alignment.
The new propsstartSeasonandlordsDollarValueexpand the component’s functionality. Verify that these functions return or accept the correct data types (e.g., returning a Promise of a bigint) to prevent runtime errors.
49-53: UI store references are well-handled.
AccessingonKatanaandnetworkfromuseUIStorecleanly integrates environment-based logic. Also, storinglordsValueas a bigint is a good decision to avoid floating-point precision issues.
54-63: Memoization is implemented correctly.
Memoizingvariablesandclientensures fewer unnecessary re-renders. This approach is appropriate given that the client references can remain stable across multiple renders.
166-187: Initial adventurer creation approach is consistent.
WeaponSelectandAdventurerNameare neatly integrated; the button’s disabled condition for empty inputs helps prevent invalid submissions. Good job!
190-201: Second step referencing startSeason.
PassingstartSeasonandlordsValuetoSpawnensures the new season logic is maintained across UI steps. Confirm usage is tested in an integration or E2E test to ensure correct flow.ui/src/app/lib/utils/index.ts (1)
73-82: Hex decoding in feltToString looks good.
Padding and byte extraction ensure safe conversion. This approach is more explicit and less error-prone than relying on buffers. Consider handling empty or invalid hex scenarios if input can be malformed.ui/src/app/lib/utils/syscalls.ts (3)
52-52: New tournamentContractAddress property.
IncludingtournamentContractAddressinSyscallsPropsis a logical extension for tournament functionality. Ensure to keep environment-based addresses in sync with network configuration.
196-196: Expanded createSyscalls signature.
The addition oftournamentContractAddressin thecreateSyscallsfactory indicates a robust design to handle new contract interactions.
1612-1782: startSeason logic.
This new function seamlessly combines tournament entry with spawning logic. Key points:
- The code reuses existing checks such as
checkBalancesandhandleSubmitCalls, ensuring consistency.- The final block sets the new adventurer’s data in state, reflecting the same approach as
spawn.
Just ensure any possible revert reasons from the tournament contract are caught and displayed to the user.ui/src/lib/utils.ts (1)
1-6: cn function usage.
Merging class names withclsxandtwMergeis a standard pattern in modern React + Tailwind setups. No issues found.ui/src/app/components/season/toaster.tsx (2)
1-2: Client-side directive is appropriate.
Including"use client";ensures the component can use React hooks and manage toast states properly on the client side.
3-35: Toaster component is well-structured.
The composition of[Toast, ToastClose, ToastDescription, ToastTitle, ToastViewport]withuseToastis clear. Mapping over the array oftoaststo render each toast individually is straightforward, and the dismissal logic is well-managed with<ToastClose />.ui/src/app/hooks/useCustomQuery.ts (3)
3-4: **Imports look good. **
ImportinggameClientandnetworkConfigallows for dynamic GraphQL endpoint retrieval. This setup is consistent with best practices for environment-driven configurations.
6-6: **Use ofuseMemocomplement. **
AddinguseMemoimport is appropriate, ensuring that recalculations of the client instance only happen when necessary.
30-30: **Explicit client specification. **
Passing the memoizedclienttouseQueryensures clarity and decouples it from any default client. Good work keeping the usage explicit.ui/src/app/provider.tsx (3)
5-8: **jsonRpcProviderusage. **
Bringing injsonRpcProviderfrom@starknet-react/coremakes sense, tying into the new multi-network setup. This aligns well with the rest of the provider logic.
12-12: **Encapsulation ofnetworkConfig. **
Retaining a single source of truth for network-related configurations centralizes environment data and simplifies maintenance.
44-44: **Tournament address injection. **
You have introducedtournamentAddress. Ensure all features relying on this address have been updated accordingly in other files. Confirm usage with:✅ Verification successful
Tournament address usage is properly integrated across the codebase
The verification shows that
tournamentAddressis well-integrated across the codebase:
- Defined in
networkConfig.tsfor different network configurations- Used in
connectors.tsfor tournament-related contract interactions- Properly passed through from
provider.tsxtopage.tsxfor tournament functionalityThe changes are consistent and all necessary files have been updated to work with the tournament address.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searching turns of tournamentAddress usage rg -A 3 "tournamentAddress"Length of output: 2140
ui/src/app/lib/clients.ts (1)
44-64: **NewtournamentClientfunction. **
The addition matches the existing pattern forgoldenTokenClientandgameClient, maintaining consistent default options. No concerns here.ui/src/app/components/onboarding/LoginDialog.tsx (4)
1-5: **Imports and store usage. **
Imports for theButtoncomponent,CloseIcon, anduseUIStorecorrectly encapsulate UI logic, and theuseDisconnectplususeConnectapproach is standard for Starknet wallet management.
6-11: **State and hooks integration. **
Retrievingconnect,connectors, anddisconnectfrom Starknet hooks, alongsidesetShowLoginDialogfrom a global UI store, effectively manages the login dialog’s open/close state.
16-26: **Dialog container styling. **
The class names for center alignment and styling are clear. Usingabsolute top-1/2 left-1/2 transformis a common pattern for a centered overlay. Good job.
40-43: **Dialog structure finalization. **
Wrapping everything in a fragment is a neat solution for minimal DOM overhead. The component remains self-contained, making reusability and maintainability straightforward.ui/src/app/lib/connectors.ts (2)
119-119: Dark mode is set
You setcolorMode: "dark". Confirm that your UI components handle contrasting text and backgrounds to ensure accessibility in dark mode.
56-58: Parameter ordering consistency
The newly addedtournamentAddressis placed beforerpcUrl, which might be logical. However, if any existing code or usage patterns assumedrpcUrlwas the fourth parameter, ensure all invocations are updated accordingly to prevent mismatched arguments.✅ Verification successful
Let me gather more context about the function definition and its parameters.
Let me try a different approach to find the function definition.
Let me check all usages of this connector to verify parameter ordering.
Let me try one more time without file type restrictions.
Parameter ordering is correctly maintained
Based on the verification results, the parameter ordering is consistent between the function definition and its usage. The
cartridgeConnectorfunction is called with all parameters in the correct order:
- gameAddress
- lordsAddress
- ethAddress
- tournamentAddress
- rpcUrl
The only usage found in
ui/src/app/provider.tsxmatches exactly with the parameter order defined in the function signature, so there are no issues with mismatched arguments.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Checking all references to cartridgeConnector to ensure calls properly match rg -A 2 "cartridgeConnector\s*\("Length of output: 230
Script:
#!/bin/bash # Find the complete function definition of cartridgeConnector ast-grep --pattern 'const cartridgeConnector = ($$$) => { $$$ }'Length of output: 68
Script:
#!/bin/bash # Find the cartridgeConnector function definition using ripgrep rg -A 10 "const cartridgeConnector\s*=" ui/src/app/lib/connectors.tsLength of output: 306
Script:
#!/bin/bash # Find all usages of cartridgeConnector with more context rg -A 5 "cartridgeConnector\s*\(" --type ts --type tsxLength of output: 84
Script:
#!/bin/bash # Find all usages of cartridgeConnector with more context rg -A 6 "cartridgeConnector\s*\("Length of output: 477
ui/src/app/components/start/Prizes.tsx (4)
1-4: Import usage is clear and consistent.
No immediate issues or suggestions; well done structuring the imports and referencing local utilities and assets.
11-13: InitializelordsDollaronly when necessary.
Since its value is populated by an asynchronous call, confirm that no race condition arises if thelordsDollarValueprop changes repeatedly. Optionally, consider lazy initialization or advanced memoization if necessary.
80-85: Double-check numeric calculations for dividing token values.
You are dividing by10 ** 8and10 ** 18to convert raw amounts into a final decimal. Confirm that these exponents match the tokens' decimals.
97-97: Default export is good.
Exporting the component at the bottom is consistent with common patterns.ui/src/app/containers/LeaderboardScreen.tsx (2)
1-4: Imports nicely reflect updated leaderboard components.
Everything seems properly referenced.
8-8: GraphQL query usage looks consistent.
You’re correctly passing thenetworkparam. Ensure server-side caching or client caching is utilized for efficiency.ui/tailwind.config.js (6)
5-5: Dark mode via["class"].
This approach is straightforward. Remember to set a.darkclass on the<html>or<body>element to enable dark mode.
6-6: Confirm file wildcard expansion.
content: ["./src/**/*.{js,ts,jsx,tsx}"]ensures scanning for classes. Confirm if you have more file types or test files to include.
9-22: New colors look good.
Addingterminal-gold,terminal-silver,terminal-bronzeextends the palette for trophy highlights. No issues found.
72-76: Border radius approach is flexible.
Using CSS variables for radius is a neat approach for theming. No issues.
77-79: Perspective usage.
Adding custom perspective classes can be helpful for 3D transforms. This is good for advanced UI features.
120-121:tailwindcss-animateplugin usage.
This plugin unlocks more advanced animations. Looks well integrated into the config.ui/src/app/hooks/useToast.ts (7)
1-2: Enabling client-side code.
Ensure it’s truly needed (e.g., for React hooks or local states). Otherwise, keep code universal.
3-5: Comment references react-hot-toast.
This is a great approach to store-based toasts. Make sure licensing disclaimers are handled if needed.
6-9: Types are neatly referenced fromseason/toast.
Ensure these imports remain valid if the file structure changes in the future.
21-26: Action types are straightforward.
Clear naming convention. No changes needed.
61-75: Ensure unmount triggers a cleanup.
If the component unmounts mid-timeout, confirm that the pending removal is cleared or handled.
77-130: Reducer logic is well organized.
- Each case is concise and readable.
- Good usage of separate actions for
ADD_TOAST,UPDATE_TOAST, etc.
174-192:useToasthook seamlessly integrates with the toast store.
- Your subscription mechanism is well structured.
- Just confirm any concurrency or repeated renders are handled gracefully.
ui/src/app/containers/AdventurerScreen.tsx (3)
46-46: Validate the bigint return type for cross-browser compatibility.
Althoughbigintis widely supported in modern JavaScript runtimes, certain older browsers or polyfilled environments may not support it. Be sure to handle potential compatibility issues if this method is used in the UI layer.
63-63: Approach thelordsDollarValuecallback with caution.
It indicates a possibly asynchronous call returning a monetary value. Consider caching the result if it’s called frequently to avoid performance overhead, or verify if it’s safe to repeatedly call.
142-153: Pass the new props toCreateAdventurercarefully.
The additionalstartSeasonandlordsDollarValueprops bring new dependencies. Make sure thatCreateAdventurergracefully handles potential null or undefined scenarios (e.g., if the network call fails).ui/src/app/components/season/toast.tsx (5)
3-3: Confirm that @radix-ui/react-toast is added to the production build.
Ensure that your build pipeline includes this dependency properly so the toast system won't break in production.
44-58: Leverage the advanced features of Radix UI for accessibility.
ToastPrimitives.Roothandles basic accessibility well, but ensure custom roles oraria-*attributes are set if your design has additional accessibility needs.
74-91: Double-check thetoast-close=""attribute.
While it doesn’t break the code, confirm that the attribute is actually recognized or used by your styling or tooling. Some browsers or automated tooling might flag it if it’s not standard.
104-114: Check potential overflow of text inToastDescription.
If the toast message is longer than expected, ensure that lines wrap gracefully or that there's a max height to avoid layout issues.
120-130: Excellent modular exports.
Exporting each component and type fosters reusability and clarity, making your toast system straightforward to integrate.ui/src/app/components/leaderboard/SeasonTable.tsx (3)
42-46: Graceful handling of loading and error states.
Check if theuseQuerycall forgetTournamentGamescan fail. You might handle theerrorproperty fromuseQueryto display a warning message to the user.
58-66: Verify the shapes ofgetAdventurersInListByXPquery results.
UsingadventurersByXPdata?.adventurerswithout a null-check or fallback might result in an error if the server returns an unexpected shape.
88-164: Pagination logic appears correct.
Your check to conditionally render pagination if there are more than 10 adventurers is straightforward. Just remember to keep the pagination UI in sync with future filtering or searching features.ui/src/app/lib/networkConfig.ts (5)
6-6: SpecifytournamentGQLURLfor your test environment
Leaving this blank might be intentional, but ensure your devs know to fill it in or override it for local testing if needed.
26-27: ConfirmtournamentAddressusage forsepolia.
Given that it’s"0x0", verify if the system relies on it at runtime and whether that might cause issues in tournaments or test logic.
42-43: Ensure correctness oftournamentGQLURLfor mainnet.
The provided URL must match the actual endpoint for retrieving tournament data. If it’s in flux, consider extracting it to a.envfile for easier maintenance.
67-69: Double-check thetournamentAddressfor mainnet.
If the contract address was recently deployed, confirm that it matches the address on record to avoid mismatch with your on-chain data.
130-131: Double-check the local tournament references.
If the local environment requires special logic for tournaments, confirm that referencing"0x0"addresses won’t break your flows or tests.ui/src/app/components/leaderboard/ScoreTable.tsx (2)
2-11: Minor import reorganization.
No issues found. The updated imports are well-structured and do not introduce any known problems.
115-116: Heading updated to "Global Leaderboard".
This text change clarifies the scope of the leaderboard. No further issues observed.ui/src/app/components/icons/Icons.tsx (5)
1-15: Consolidated imports from react-icons/gi.
This improves readability. Nicely done.
97-97: Introduction of TournamentTrophyIcon.
No issues with naming. The icon name is descriptive and consistent.
123-124: New PlusIcon and CloseIcon exports.
Good addition for general UI functionalities (add/close).
137-200: Reworked icon export list.
This reorganization is consistent and logical.
18-67: New icons imported from public/icons.
They appear to be potentially useful assets. Confirm usage throughout the codebase, if not already done.✅ Verification successful
Based on the search results, I can see that the newly imported icons are actively used throughout the codebase:
Arcade- Used asArcadeIconin components likeArcadeLoaderand arcade-related functionalityArrowTarget,Arrow,DoubleArrow,PotionArrow- Used in various UI components for navigation and potion-related featuresClock- Used asClockIconfor displaying time informationClose- Used asCloseIconin multiple dialog/modal componentsDrop- Used asDownArrowIconfor dropdown menus and UI navigationEye- Used asEyeIconin tutorial components likePrescienceTutorialPlus- Used asPlusIconin UI componentsTournamentTrophy- Used asTournamentTrophyIconin prize-related componentsAll imported icons are properly utilized in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searching references to newly added icons to confirm usage and ensure they are used correctly. rg -A 3 'Arcade|ArrowTarget|Arrow|Clock|Close|Drop|Eye|Plus|TournamentTrophy'Length of output: 66101
ui/src/app/components/start/PaymentDetails.tsx (1)
151-155: Always displays PaymentDetails.
By removing conditional rendering, the payment table is now shown all the time. Confirm this is the desired UX and doesn't clutter the interface in contexts that don't require payment details.ui/src/app/hooks/useUIStore.ts (2)
133-134: Added new booleanshowLoginDialogwith setter.
This addition seems well-structured, enabling future expansions of login flow.
251-252: Initialized and mappedshowLoginDialogstate tosetShowLoginDialog.
The state management approach follows established patterns. Looks good.ui/src/app/hooks/graphql/queries.ts (1)
551-551: Good job on updating exports.
Including the newly created queries in the export section maintains clarity and consistency across modules.Also applies to: 568-569
ui/src/app/components/start/Spawn.tsx (8)
2-2: Updated imports for new season features.
Imports ofDownArrowIcon,PlusIcon, andSeasonDetailsappropriately bring in newly introduced UI elements, indicating better modularity.Also applies to: 5-5
31-31: New props in interface.
AddingstartSeasonandlordsValueis clear and consistent with the rest of theSpawnProps. Ensure you have adequate type definitions and usage scenarios for these props to avoid confusion and potential runtime errors.Also applies to: 38-38
44-44: Destructuring newly added props.
It's consistent to destructurestartSeasonandlordsValuealong with the existing props. No issues found.Also applies to: 51-51
133-133: Dependency array check.
Confirm whether you also needtournamentEndedor other evolving state in the dependency array to ensure the effect always updates correctly.
156-176: New function: enterSeason.
This function parallelshandlePaymentbut for season entry. The structure looks smart: using try/catch, updating UI states, and callingstartSeason. Just verify that all error states are properly handled.
221-227: Layering background with absolute positioning.
These lines effectively layer images and backgrounds for a cinematic effect. Verify that the absolute positioning behaves consistently across different resolutions.
245-273: Token or payment visual logic.
Displaying the correct token image (golden token, blobert, or Lords) based on user eligibility is a neat UX. The approach is logically structured.Also applies to: 274-291
295-296: Additional UI layout sections.
These newly introduced layout blocks—such as the multi-column approach forPaymentDetailsandSeasonDetails—improve readability. Confirm they render properly on smaller screens.Also applies to: 297-306, 309-312, 315-321
ui/src/app/components/navigation/Header.tsx (3)
88-88: New setter for login dialog state.
setShowLoginDialogis consistent with the rest of the UI state management pattern.
479-489: Refactored account button logic (mobile).
The conditional logic now displays the login dialog for unconnected users or a profile/disconnect flow for connected users. This separation simplifies user experience.
540-550: Refactored account button logic (desktop).
Similar improvements for the desktop view, further reinforcing the reusability and clarity of login vs. connected states.ui/src/app/page.tsx (14)
22-22: Added LoginDialog and toaster.
Importing theLoginDialogandToastercomponents suggests a streamlined login flow and improved user feedback.Also applies to: 24-24
54-54: Introduced toast and gameClient.
These hooks and utilities integrate nicely into the new approach for user feedback and GraphQL communication.Also applies to: 59-59
132-132: Hooking into showLoginDialog.
Storing this state in UI store for consistent usage across components is a solid approach.
140-140: Toast usage.
Great addition for alerting the user of season events or other status updates.
336-337: AddedstartSeasonfunction andlordsDollarValue.
Including these in the destructured object extends the game logic to handle new season flows. No issues found.
483-487: Created separate Apollo Client instance.
Memoizing thegameClientfor the tournament or special queries is good for performance. Just confirm you don’t need condition-based re-instantiation for repeated environment changes.Also applies to: 489-489
786-786: Toaster rendering.
Ensuring<Toaster />is included in the top-level DOM is essential for global user notifications.
793-808: Conditional display for special beast and top-up.
This block handles new interactive layers well. The approach respects existing logic for token top-up and the special beast event.
809-816: StatRemovalWarning overlay.
This additional user prompt is helpful. Ensure that all relevant edge cases (e.g., multiple stat warnings) are addressed.
817-821: Mobile TxActivity.
Allows transaction monitoring on smaller screens. The approach is consistent with the rest of your layering.
822-830: Header integration with costToPlay.
PassingcostToPlayto theHeaderensures consistent display or logic for top-up. No issues found.
831-839: Introduction of NotificationDisplay.
Keeping the user further informed fosters better UX. The position after the top bar is logical.
843-854: Refined menu sections.
The updatedScreenMenuusage for both mobile and desktop contexts ensures consistency across breakpoints.Also applies to: 856-864, 865-868
869-926: Support for new screens and dialogs.
Great job integrating new “season” flows (startSeason), updatedAdventurerScreen, andLoginDialog. Keep an eye on any overlapping modals for a smooth user experience.ui/components.json (2)
1-21: Well-structured component configuration!The configuration follows shadcn/ui best practices with proper TypeScript and React Server Components setup. The path aliases are logically organized for clean imports.
9-9: Verify if "neutral" base color aligns with seasons theming requirementsConsider if the neutral base color provides sufficient visual distinction for different seasons in the tournament UI.
✅ Verification successful
The "neutral" base color is appropriate and won't affect seasons theming
The codebase shows that the application uses a custom terminal-themed color palette defined in
tailwind.config.jswith specific colors liketerminal-green,terminal-yellow, and medal colors (terminal-gold,terminal-silver,terminal-bronze). The "neutral" base color incomponents.jsonis just the shadcn/ui default color scheme which doesn't override these custom theme colors. The seasons theming appears to rely on the custom color palette rather than shadcn's base colors.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if there are any season-specific color definitions in the Tailwind config cat tailwind.config.js | grep -A 10 "colors:"Length of output: 96
Script:
#!/bin/bash # Search for tailwind configuration files in different locations fd -e js -e ts -e cjs -e mjs tailwind.config # Look for any color theme configurations in the codebase rg -i "colors?.*=|colors?.*:" --type ts --type js --type css # Check for any season-related theme or color configurations rg -i "season.*theme|season.*color" --type ts --type js --type cssLength of output: 2199
Script:
#!/bin/bash # Let's check the content of the tailwind config file to see the color definitions cat ui/tailwind.config.js # Also check for any theme-related configurations in the shadcn setup fd -e json components.json cat ui/components.jsonLength of output: 4766
ui/package.json (1)
16-16: Consider pinning dependency versions for better stabilityThe new dependencies use caret (^) version constraints which allow minor version updates. For production stability, consider pinning exact versions:
- @radix-ui/react-toast
- lucide-react
- tailwind-merge
- tailwindcss-animate
- "@radix-ui/react-toast": "^1.2.4", + "@radix-ui/react-toast": "1.2.4", - "lucide-react": "^0.468.0", + "lucide-react": "0.468.0", - "tailwind-merge": "^1.14.0", + "tailwind-merge": "1.14.0", - "tailwindcss-animate": "^1.0.7" + "tailwindcss-animate": "1.0.7"Also applies to: 37-37, 52-52, 54-54
✅ Verification successful
Consider pinning dependency versions for better stability
The suggestion to pin versions remains valid as it would provide better stability and reproducible builds. However, security checks reveal no known vulnerabilities in any of the new dependencies:
- @radix-ui/react-toast
- lucide-react
- tailwind-merge
- tailwindcss-animate
These dependencies are only used in
ui/package.jsonand not shared across other package files, making version pinning a local optimization.- "@radix-ui/react-toast": "^1.2.4", + "@radix-ui/react-toast": "1.2.4", - "lucide-react": "^0.468.0", + "lucide-react": "0.468.0", - "tailwind-merge": "^1.14.0", + "tailwind-merge": "1.14.0", - "tailwindcss-animate": "^1.0.7" + "tailwindcss-animate": "1.0.7"🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for known vulnerabilities in new dependencies gh api graphql -f query=' { securityVulnerabilities(first: 10, ecosystem: NPM, package: "radix-ui__react-toast") { nodes { advisory { summary severity } } } } ' gh api graphql -f query=' { securityVulnerabilities(first: 10, ecosystem: NPM, package: "lucide-react") { nodes { advisory { summary severity } } } } 'Length of output: 495
Script:
#!/bin/bash # Check for vulnerabilities in remaining dependencies gh api graphql -f query=' { securityVulnerabilities(first: 10, ecosystem: NPM, package: "tailwind-merge") { nodes { advisory { summary severity } } } } ' gh api graphql -f query=' { securityVulnerabilities(first: 10, ecosystem: NPM, package: "tailwindcss-animate") { nodes { advisory { summary severity } } } } ' # Check if these dependencies are used in other package.json files fd -t f "package.json" --exec grep -l "@radix-ui/react-toast\|lucide-react\|tailwind-merge\|tailwindcss-animate"Length of output: 625
|
|
||
| export const seasonCost = 4000000000000000000; |
There was a problem hiding this comment.
Consider storing large constants as strings or BigInts to prevent precision issues.
JavaScript only provides integer precision up to 2^53 (≈9.007e15). This constant exceeds that limit, potentially leading to precision errors. Converting to a string or BigInt helps avoid unexpected results.
Here's a suggested fix:
-export const seasonCost = 4000000000000000000;
+// Use either a string representation or a BigInt literal to preserve precision:
+export const seasonCost = '4000000000000000000';
// OR
+// export const seasonCost = 4000000000000000000n; // Using BigInt literalCommittable suggestion skipped: line range outside the PR's diff.
| const handleGetLordsValue = async () => { | ||
| const value = await lordsDollarValue(); | ||
| setLordsValue(value); | ||
| }; | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Async operation lacks error handling.
handleGetLordsValue could fail if the contract call raises an exception. Consider wrapping this logic in a try/catch to display or handle potential errors gracefully.
const handleGetLordsValue = async () => {
+ try {
const value = await lordsDollarValue();
setLordsValue(value);
+ } catch (error) {
+ console.error("Failed to fetch Lords value", error);
+ // Optionally set a fallback or show user feedback
+ }
};📝 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.
| const handleGetLordsValue = async () => { | |
| const value = await lordsDollarValue(); | |
| setLordsValue(value); | |
| }; | |
| const handleGetLordsValue = async () => { | |
| try { | |
| const value = await lordsDollarValue(); | |
| setLordsValue(value); | |
| } catch (error) { | |
| console.error("Failed to fetch Lords value", error); | |
| // Optionally set a fallback or show user feedback | |
| } | |
| }; | |
| useEffect(() => { | ||
| handleGetLordsValue(); | ||
| console.log(lordsValue); | ||
| }, [lordsValue]); | ||
|
|
There was a problem hiding this comment.
Potential re-render loop risk.
The effect depends on lordsValue but also calls handleGetLordsValue, which sets lordsValue. If lordsValue changes each fetch, it could create an infinite loop. Consider conditioning the call or running it only once on mount.
-useEffect(() => {
- handleGetLordsValue();
- console.log(lordsValue);
-}, [lordsValue]);
+useEffect(() => {
+ handleGetLordsValue();
+ console.log(lordsValue);
+ // Possibly remove the dependency on lordsValue:
+}, []);📝 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.
| useEffect(() => { | |
| handleGetLordsValue(); | |
| console.log(lordsValue); | |
| }, [lordsValue]); | |
| useEffect(() => { | |
| handleGetLordsValue(); | |
| console.log(lordsValue); | |
| // Possibly remove the dependency on lordsValue: | |
| }, []); | |
| const ToastAction = React.forwardRef< | ||
| React.ElementRef<typeof ToastPrimitives.Action>, | ||
| React.ComponentPropsWithoutRef<typeof ToastPrimitives.Action> | ||
| >(({ className, ...props }, ref) => ( | ||
| <ToastPrimitives.Action | ||
| ref={ref} | ||
| className={cn( | ||
| "inline-flex h-8 shrink-0 items-center justify-center rounded-md border border-neutral-200 bg-transparent px-3 text-sm font-medium ring-offset-white transition-colors hover:bg-neutral-100 focus:outline-none focus:ring-2 focus:ring-neutral-950 focus:ring-offset-2 disabled:pointer-events-none disabled:opacity-50 group-[.destructive]:border-neutral-100/40 group-[.destructive]:hover:border-red-500/30 group-[.destructive]:hover:bg-red-500 group-[.destructive]:hover:text-neutral-50 group-[.destructive]:focus:ring-red-500 dark:border-neutral-800 dark:ring-offset-neutral-950 dark:hover:bg-neutral-800 dark:focus:ring-neutral-300 dark:group-[.destructive]:border-neutral-800/40 dark:group-[.destructive]:hover:border-red-900/30 dark:group-[.destructive]:hover:bg-red-900 dark:group-[.destructive]:hover:text-neutral-50 dark:group-[.destructive]:focus:ring-red-900", | ||
| className | ||
| )} | ||
| {...props} | ||
| /> | ||
| )); | ||
| ToastAction.displayName = ToastPrimitives.Action.displayName; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider extracting repetitive styling.
The same base styles appear in multiple toast subcomponents. You could unify them in a single shared variant or styling function to keep your code DRY.
ui/src/app/lib/networkConfig.ts
Outdated
| @@ -104,6 +115,7 @@ export const networkConfig = { | |||
| rpcUrl: "http://localhost:5050", | |||
| rpcAPIKey: "", | |||
| lsGQLURL: "http://localhost:8080/graphql", | |||
| tournamentGQLURL: "", | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider environment variable for localKatana:
Even local environments may benefit from a dynamic approach so that different developers don’t have to constantly update config for local testing.
| // const handleWeaponSelectionMobile = (weapon: string) => { | ||
| // setFormData({ ...formData, startingWeapon: weapon }); | ||
| // setStep(step + 1); | ||
| // }; |
There was a problem hiding this comment.
Clarify the removal of mobile weapon selection handler
The mobile weapon selection handler is commented out without a replacement. This could impact mobile users' ability to select weapons.
Please either:
- Restore the mobile handler if it's still needed
- Confirm that mobile selection is handled by the desktop handler
- Document why mobile-specific handling was removed
Summary by CodeRabbit
Release Notes
Tournament Features
User Interface
Technical Improvements
Bug Fixes and Refinements