feat(frontend): pnk-token-page #29
Conversation
WalkthroughThis pull request introduces a comprehensive update to the frontend, focusing on creating a new PNK Token page. The changes include adding new components, GraphQL queries, and types for the PNK Token page, along with environment configuration updates. The implementation involves creating multiple React components like Changes
Possibly related PRs
Suggested reviewers
Poem
🪧 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 (
|
✅ Deploy Preview for kleros-website-v2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (11)
frontend/.gitignore (1)
29-29: Consider documenting environment setup processSince this PR introduces Strapi integration, consider:
- Adding instructions in the README on how to obtain Strapi credentials
- Updating CI/CD pipeline configuration for the new environment variables
- Documenting the production deployment process
frontend/src/components/PNKToken/TokenomicsSection/Stat.tsx (1)
8-19: Clear and concise rendering.
Your layout effectively groups the label, primary, and secondary values. Good use of composable utilities (flex,text-base, etc.) keeps the UI readable. Consider verifying if you need i18n or localization for text elements like the label.frontend/src/components/PNKToken/TokenomicsSection/TokenStatDisplay.tsx (1)
7-27: Responsive token stats display.
Your approach with conditional styling classes (likemd:flex-row) is a solid way to handle responsive layouts. The usage ofmapto renderStatcomponents is clean and straightforward. One improvement might be to handle potential emptystatsarrays gracefully (e.g., show a fallback or message).frontend/src/components/ExternalLink.tsx (2)
11-11: Leverage a more direct type forclassName.
Currently, you are usingHTMLAttributes<HTMLDivElement>["className"]. While correct, it might be simpler and more intuitive to typeclassNameas a plainstringsince you are applying it directly to a<Link>component.- className?: HTMLAttributes<HTMLDivElement>["className"] + className?: string
23-28: Consider adding anaria-labelfor accessibility.
Adding anaria-labelon the<Image>or<span>clarifies the link’s purpose to assistive technologies.frontend/src/components/CtaCard.tsx (1)
27-43: Encourage link content for better accessibility.
While theExternalLinkcomponent is used, ensure that link text conveys a clear context (e.g., “Read more about X” instead of just the arrow text). Screen readers often rely on link text to convey intent.frontend/src/components/PNKToken/TokenNeedSection/index.tsx (1)
9-23: Visually unify card layout.
By mapping overtokenNeedData.card, you render multipleCtaCards. Ensure consistent spacing or alignment across all cards for improved UX, especially for dynamic or variable content lengths.frontend/src/components/PNKToken/Hero.tsx (1)
13-56: Optimize background image usage.
The approach to absolute positioning withfillis effective, but consider lazy loading or slightly smaller images if the background is large. This will help optimize performance on slower connections.frontend/src/pages/pnk-token.tsx (2)
19-25: Ensure consistent naming of interface.
IPNKtokenis descriptive, but consider matching PascalCase naming for clarity (e.g.,IPnkToken).-interface IPNKtoken { +interface IPnkToken {
27-43: Maintain SEO-friendly structure.
Placing your page sections in semantic containers (like<main>and<section>) instead of<div>elements alone may help with accessibility and search engine crawling.frontend/src/components/Navbar/index.tsx (1)
55-56: Confirm Updated Padding Breakpoints Against Design RequirementsYou've reduced the max padding from 256 to 128 on both
paddingLeftandpaddingRight. While it might make the layout more compact, verify that these changes follow the established design/UX guidelines for consistent spacing.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
frontend/.env.example(1 hunks)frontend/.gitignore(1 hunks)frontend/src/components/CtaCard.tsx(1 hunks)frontend/src/components/Divider.tsx(1 hunks)frontend/src/components/ExternalLink.tsx(1 hunks)frontend/src/components/Navbar/index.tsx(1 hunks)frontend/src/components/PNKToken/Hero.tsx(1 hunks)frontend/src/components/PNKToken/TokenNeedSection/index.tsx(1 hunks)frontend/src/components/PNKToken/TokenomicsSection/Stat.tsx(1 hunks)frontend/src/components/PNKToken/TokenomicsSection/TokenStatDisplay.tsx(1 hunks)frontend/src/components/PNKToken/TokenomicsSection/index.tsx(1 hunks)frontend/src/pages/_app.tsx(1 hunks)frontend/src/pages/pnk-token.tsx(1 hunks)frontend/src/queries/pnk-token/hero.ts(1 hunks)frontend/src/queries/pnk-token/token-need.ts(1 hunks)frontend/src/queries/pnk-token/tokenomics.ts(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- frontend/src/components/Divider.tsx
- frontend/.env.example
🔇 Additional comments (21)
frontend/src/pages/_app.tsx (1)
6-6: Great addition of multiple font weights.
By specifying an array of weights (["400", "500"]), you allow more flexible styling for different text elements without adding significant overhead. This should help ensure consistent typography across the application.
frontend/src/components/PNKToken/TokenomicsSection/Stat.tsx (3)
1-2: Imports and type references look good.
Importing TokenStat from @/queries/pnk-token/tokenomics ensures shared type consistency across components. No issues found here.
3-7: Thoughtful component signature.
Using React.FC<TokenStat & { label: string }> clarifies the props expected, especially the extra label prop. This design enforces type safety, preventing runtime errors.
23-23: Export statement is well-structured.
Exporting Stat as the default ensures straightforward imports into parent components. This is consistent with typical React conventions.
frontend/src/components/PNKToken/TokenomicsSection/TokenStatDisplay.tsx (3)
1-2: Consistent type import.
Importing TokenStatDisplay under a new alias ITokenStatDisplay helps distinguish prop types from the component name, reducing confusion in the codebase.
3-4: Image import from Next.js.
Using next/image is preferred for performance optimizations (lazy-loading, responsive sizing). Keep it up!
5-5: Reusability highlighted by separate component import.
Importing Stat from "./Stat" helps maintain a clean separation of concerns and fosters modular design.
frontend/src/queries/pnk-token/hero.ts (2)
1-26: GraphQL query covers essential hero data.
Fetching fields like header, subtitle, buyButton, socials, and background ensures the hero section is well-rounded. Consider specifying more precise field names or nested queries if future expansions require them.
28-49: Type definition enforces robust data shapes.
Your HeroQueryType mirrors the GraphQL response accurately, preventing type mismatches. If optional fields might appear in future expansions, consider partial types or optional chaining.
frontend/src/queries/pnk-token/token-need.ts (2)
5-31: Verify whether the returned data matches your UI assumptions.
All fields here (e.g., header, subtitle, and arrowLink) are required. If the backend returns partial data, the UI might break. Consider adding stronger runtime checks or fallback values in your components.
33-48: Good use of typed data structures.
Defining types for the fields ensures type safety and helps maintain consistent usage across the codebase.
frontend/src/queries/pnk-token/tokenomics.ts (2)
5-30: Handle potential nulls for arrowLink.
If your GraphQL API allows for arrowLink or any nested fields to be null, consider marking them optional in the type definitions or handling null cases gracefully in the UI.
32-52: Straightforward type definitions for clarity.
This section effectively captures the structure of your tokenomics-related data. No further change suggested.
frontend/src/components/PNKToken/TokenomicsSection/index.tsx (2)
14-29: Ensure consistent typography hierarchy.
You are using <h1> for the section header. Verify that other sections do not also use <h1>, as multiple <h1> elements on a single page may break hierarchical structure for screen readers.
21-21: Great modularization of statistics display.
Extracting TokenStatDisplay is a clean pattern that keeps the main component simpler and more readable.
frontend/src/components/CtaCard.tsx (2)
6-18: Ensure strong typing and consistent naming.
Your interface ICtaCard is well-structured and captures the required props. As a best practice, consider whether you want more descriptive property names (e.g., arrowLink → linkWithArrow) for clarity.
20-45: Add defensive checks for optional fields and improve alt text.
If icon.url or arrowLink.link.url can be null/undefined, add safe checks or default values to avoid runtime errors. Also, consider customizing the alt text to be more descriptive for improved accessibility.
- alt="Icon"
+ alt={icon.url ? `Icon for ${title}` : 'Default icon alt'}frontend/src/components/PNKToken/TokenNeedSection/index.tsx (1)
5-7: Explicitly handle empty or missing data in tokenNeedData.
Consider verifying whether pnkTokenPageNeedSection might be null or undefined in some configurations. If so, gracefully handle missing data with a default fallback.
frontend/src/components/PNKToken/Hero.tsx (1)
9-11: Validate data presence for heroData.
If the API fails to return all social links or the background image is missing, handle such cases to avoid UI breakage.
frontend/src/pages/pnk-token.tsx (1)
45-67: Graceful error handling during data fetch.
getStaticProps is fetching multiple queries. If any query fails, consider returning fallback data or a user-friendly error page instead of potentially breaking the build.
Would you like help implementing a fallback approach for partial query failures?
frontend/src/components/Navbar/index.tsx (1)
Line range hint 1-54: Overall Code Quality Looks Good
No major functional or logical issues identified. The component structure is clear, and the usage of React hooks (useState, useWindowScroll, useLockBodyScroll) is appropriate. The optional chaining for navbarData ensures that if certain data is missing, it won’t break the component. Additionally, the clsx usage keeps the conditional class naming clean.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (9)
frontend/src/components/PNKToken/Explorers.tsx (1)
9-29: Solid layout and accessibility.
Mapping over explorers with unique keys is good, though usingexplorer.nameas a key may risk collisions if multiple explorers share an identical name. Thealtattribute is properly set.frontend/src/components/PNKToken/BuySection/index.tsx (1)
10-24: Consider handling empty arrays smoothly
WhenfeaturedExchangesorexchangesarrays are empty, consider adding a small fallback UI or message to inform the user that no exchanges are available.frontend/src/components/CtaCard.tsx (1)
1-5: Ensure descriptive alt text for better accessibility
Currently, the alt text is"Icon". For enhanced screen-reader support, use a more descriptive alt text based on the content or purpose of the icon.frontend/src/components/PNKToken/TokenNeedSection/index.tsx (1)
9-33: Provide fallback for empty or missing data
IftokenNeedDataor its nested arrays are empty, consider handling it gracefully. A simple message or placeholder could improve user experience.frontend/src/components/PNKToken/Hero.tsx (3)
34-39: Consider using dynamic alt text from CMSThe Image component uses a static alt text "Hero Image Background". For better accessibility and SEO, consider using a descriptive alt text from the GraphQL data.
<Image src={background.url} - alt="Hero Image Background" + alt={background.alt || "Hero Image Background"} fill className="absolute top-0 left-0 h-full z-[-1] object-cover" />
27-29: Enhance button accessibilityThe button text should be more descriptive for screen readers. Consider adding an aria-label if the button text is too concise.
-<Button variant="secondary"> +<Button variant="secondary" aria-label={`${buyButton.text} - Purchase PNK tokens`}> <span>{buyButton.text}</span> </Button>
17-33: Consider extracting Tailwind classes into components or utilitiesThe component uses multiple Tailwind classes directly. Consider extracting commonly used spacing and responsive classes into reusable components or utility classes for better maintainability.
frontend/src/pages/pnk-token.tsx (2)
1-23: Consider grouping related importsThe imports could be organized better by grouping them into:
- External dependencies
- Components
- Queries
- Utils
+// External dependencies import React from 'react'; +// Components import Footer from "@/components/Footer"; import Navbar from "@/components/Navbar"; import BuySection from "@/components/PNKToken/BuySection"; import Hero from "@/components/PNKToken/Hero"; import TokenNeedSection from "@/components/PNKToken/TokenNeedSection"; import TokenomicsSection from "@/components/PNKToken/TokenomicsSection"; +// Queries import { footerQuery, FooterQueryType } from "@/queries/footer"; import { navbarQuery, NavbarQueryType } from "@/queries/navbar"; import { heroQuery, HeroQueryType } from "@/queries/pnk-token/hero"; import { buySectionQuery, BuySectionQueryType, } from "@/queries/pnk-token/token-buy"; import { tokenNeedSectionQuery, TokenNeedSectionQueryType, } from "@/queries/pnk-token/token-need"; import { TokenomicsSectionQueryType, tokenomicsSectionQuery, } from "@/queries/pnk-token/tokenomics"; +// Utils import { graphQLClient } from "@/utils/graphQLClient";
41-50: Consider adding error boundaries and loading statesThe page component could benefit from:
- Error boundaries to gracefully handle component failures
- Loading states for better UX during client-side transitions
- React Suspense for component-level loading
Consider wrapping sections in error boundaries and implementing loading states:
import { ErrorBoundary } from '@/components/ErrorBoundary'; import { LoadingFallback } from '@/components/LoadingFallback'; // In the component: <div> <Navbar {...{ navbarData }} /> <ErrorBoundary fallback={<ErrorFallback />}> <Suspense fallback={<LoadingFallback />}> <Hero {...{ heroData }} /> <BuySection {...{ buyData }} /> <TokenNeedSection {...{ tokenNeedData }} /> <TokenomicsSection {...{ tokenomicsData }} /> </Suspense> </ErrorBoundary> <Footer {...{ footerData }} /> </div>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
frontend/src/components/CtaCard.tsx(1 hunks)frontend/src/components/PNKToken/BuySection/Exchanges.tsx(1 hunks)frontend/src/components/PNKToken/BuySection/FeaturedExchange.tsx(1 hunks)frontend/src/components/PNKToken/BuySection/index.tsx(1 hunks)frontend/src/components/PNKToken/Explorers.tsx(1 hunks)frontend/src/components/PNKToken/Hero.tsx(1 hunks)frontend/src/components/PNKToken/TokenNeedSection/index.tsx(1 hunks)frontend/src/pages/pnk-token.tsx(1 hunks)frontend/src/queries/pnk-token/hero.ts(1 hunks)frontend/src/queries/pnk-token/token-buy.ts(1 hunks)
🔇 Additional comments (27)
frontend/src/queries/pnk-token/token-buy.ts (3)
1-9: Well-structured type definition.
The Exchange type is clear and adequately covers the exchange details (url, name, icon). This should reliably facilitate usage across components.
11-31: GraphQL query naming convention is clear.
The buySectionQuery is well-named and retrieves all necessary fields (header, featuredExchanges, exchanges) for the buying section. Make sure to handle errors if any of these fields are missing or undefined from the backend.
33-39: Type aligns perfectly with the query structure.
BuySectionQueryType accurately represents the returned data shape, which helps ensure type safety in the consuming components.
frontend/src/components/PNKToken/BuySection/FeaturedExchange.tsx (4)
1-4: Imports and type usage are consistent.
The usage of Exchange from the query file is appropriate, ensuring consistent typing across components.
6-8: Interface ensures clear prop definition.
Using IFeaturedExchange clarifies the requirements for the FeaturedExchange component.
9-25: Great accessibility and external link security.
The combination of target="_blank" and rel="noopener noreferrer" is good practice. Also, using exchange.name for the alt attribute fosters accessibility.
27-27: Default export is straightforward.
This is a clean and readable default export of the FeaturedExchange component.
frontend/src/components/PNKToken/BuySection/Exchanges.tsx (3)
1-8: Type usage properly enforces array structure.
IExchanges referencing Exchange[] ensures clarity on the prop shape.
9-29: Key usage might cause collisions.
Currently, exchange.name is used as the key inside the .map(). If two exchanges share the same name, React might present key-collision warnings. Consider a unique identifier per exchange if possible.
31-31: Clear default export.
Exporting Exchanges as the default is consistent with the rest of your components.
frontend/src/components/PNKToken/Explorers.tsx (3)
1-4: Imports are accurate and minimal.
The imports reflect only what's necessary: HeroQueryType, Image, and Link.
5-8: Interface usage ensures type-safety.
Using HeroQueryType["tokenExplorers"] clarifies that explorers has the proper shape from the query definition.
32-32: Default export is straightforward.
Exporting Explorers by default keeps the import pattern consistent in the rest of the codebase.
frontend/src/components/PNKToken/BuySection/index.tsx (3)
1-4: Use defensive checks for reliability
If there's a chance that buyData could be null or undefined (for example, if the query fails or returns partial data), you may want to add a conditional check or a safe fallback to avoid runtime errors.
6-8: Interface is well-defined
Defining IBuySection clearly communicates how this component expects data. The structure is straightforward and type-safe.
26-26: Export statement confirmed
The default export is consistent with typical React component export conventions.
frontend/src/components/CtaCard.tsx (3)
6-18: Interface coverage is thorough
The ICtaCard interface comprehensively covers component data, ensuring strong type safety.
20-45: Consistent layout and styling
The component structure and Tailwind usage create a clean, user-friendly layout.
47-47: Export is correct
The default export aligns well with the file’s responsibility.
frontend/src/queries/pnk-token/hero.ts (3)
1-2: GraphQL import confirmed
Imports from graphql-request look good and standard.
3-26: Query is clear and well-structured
Using a single query to retrieve both pnkTokenPageHero and tokenExplorers is efficient. The fields are appropriately named and should seamlessly integrate with the page component.
28-49: Type definitions ensure type safety
The HeroQueryType helps avoid runtime errors by capturing the expected schema. Good job outlining all nested fields.
frontend/src/components/PNKToken/TokenNeedSection/index.tsx (3)
1-3: Imports are well-organized
References to CtaCard and ExternalLink keep things modular and readable.
5-7: Interface usage is clear
ITokenNeedSection neatly documents the data shape for tokenNeedData.
35-35: Export statement is acceptable
The default export is appropriate, keeping file usage straightforward.
frontend/src/components/PNKToken/Hero.tsx (2)
1-9: LGTM! Well-organized imports using Next.js components
The imports are properly structured, utilizing Next.js Image and Link components for optimized performance.
10-12: LGTM! Well-typed interface definition
The interface properly types the component props using the GraphQL query type for type safety.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
frontend/src/components/ExternalLink.tsx(1 hunks)frontend/src/components/Navbar/AppsDropdownContent/Card.tsx(1 hunks)frontend/src/components/PNKToken/BuySection/Exchanges.tsx(1 hunks)frontend/src/components/PNKToken/BuySection/FeaturedExchange.tsx(1 hunks)frontend/src/styles/index.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- frontend/src/styles/index.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- frontend/src/components/PNKToken/BuySection/Exchanges.tsx
- frontend/src/components/ExternalLink.tsx
🔇 Additional comments (5)
frontend/src/components/Navbar/AppsDropdownContent/Card.tsx (1)
5-6: Nice enhancement centralizing hover effect styles.
Importing hoverEffect from a shared @/styles module promotes consistency and maintainability across the codebase. No adjustments are required here.
frontend/src/components/PNKToken/BuySection/FeaturedExchange.tsx (4)
1-7: LGTM! Well-structured imports using recommended Next.js components
The imports are well-organized and make good use of Next.js optimized components (Image, Link) for better performance and SEO.
8-10: LGTM! Clean and well-typed interface definition
The interface is properly typed using the Exchange type from the queries.
25-25: LGTM! Proper export statement
The default export follows React component conventions.
4-4: Verify the Exchange type implementation and GraphQL integration
Let's ensure the Exchange type and GraphQL query are properly implemented.
✅ Verification successful
Let me gather more information about the GraphQL query implementation since it wasn't fully visible in the previous results.
Exchange type and GraphQL integration are properly implemented
The verification shows that:
- The
Exchangetype is correctly defined with all required fields (url, name, icon) - The GraphQL query
buySectionQueryproperly includes thefeaturedExchangesfield with all necessary Exchange type fields - The
FeaturedExchangecomponent correctly:- Imports and uses the Exchange type
- Is properly integrated in the BuySection component
- Renders all Exchange fields (url, name, icon) correctly
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check Exchange type definition and GraphQL query
echo "Checking Exchange type definition..."
rg -A 10 "type Exchange" frontend/src/queries/pnk-token/token-buy.ts
echo "Checking GraphQL query implementation..."
rg -A 10 "query.*featuredExchanges" frontend/src/queries/pnk-token/token-buy.ts
echo "Checking component usage in BuySection..."
rg -A 5 "FeaturedExchange" frontend/src/components/PNKToken/BuySection/
Length of output: 2817
Script:
#!/bin/bash
# Check the complete GraphQL query implementation
echo "Checking complete GraphQL query..."
rg -A 20 "buySectionQuery = gql" frontend/src/queries/pnk-token/token-buy.ts
# Check BuySectionQueryType definition
echo "Checking BuySectionQueryType..."
rg -A 10 "BuySectionQueryType" frontend/src/queries/pnk-token/token-buy.ts
Length of output: 742
WIP
Remaining:
Summary by CodeRabbit
New Features
CtaCard,Divider,ExternalLink,Hero,TokenNeedSection,Stat,TokenStatDisplay,TokenomicsSection,Exchanges,FeaturedExchange,BuySection, andExplorers.Bug Fixes
.gitignoreto ignore local environment files.Documentation
Style