Footer#25
Conversation
|
È possibile rendere componente il bottone che c'è attualmente nella home? |
|
@Diubii non ho un pc sottomano in questo momento.
Il Button è assegnato (atm) a @Gabriele1075 magari sentitevi e coordinatevi |
|
@lorenzocorallo ok grazie, aspetterò il completamento del componente allora |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThis PR introduces a new Footer component, refactors button size variants for consistency, updates dependent UI components to use the new sizing system, and integrates the Footer into the root layout while simplifying the Home page structure. ChangesFooter Component and UI Refactoring
Possibly Related PRs
🚥 Pre-merge checks | ✅ 1 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
…eat: add FooterAccordion and FooterLink components
|
Once #105 is closed, I'll add the DropdownButton in the footer and open this pr |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/button-icon.tsx`:
- Around line 17-20: The prop className is declared but never forwarded to the
rendered Button; update the ButtonIcon component in button-icon.tsx to either
remove className from its props API or forward it: destructure className from
the component props and pass it into the rendered <Button> (e.g., pass
className={className} or merge it with existing classes) so consumers can style
the Button, or if you intentionally don't want external classes, remove
className from the props definition and usages.
In `@src/components/footer.tsx`:
- Around line 58-59: Sitemap legal entries ("Privacy Policy", "Terms &
Conditions", "Cookie policy") are currently defined as { type: "text", label:
"..."} and render as <p>, so change each entry to a link entry (e.g., { type:
"link", label: "Privacy Policy", href: "/privacy" }) and update the footer
rendering logic (where it checks item.type) to render an anchor or Link
component for type === "link"; specifically modify the entries with label
"Privacy Policy", "Terms & Conditions", and "Cookie policy" and ensure the
Footer/component that inspects item.type uses the link branch to output
navigable anchors.
- Line 155: The Tailwind class on the footer div is using an invalid arbitrary
max-width value ("md:max-w-[1324]") without units; update the class string on
the div in src/components/footer.tsx (the element with className starting
"typo-body-small md:typo-body-large mt-36 ...") to use a valid CSS length like
"md:max-w-[1324px]" so Tailwind can parse the arbitrary value correctly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: df9f7128-9e71-4c94-b029-43f09b25adcb
📒 Files selected for processing (8)
src/app/layout.tsxsrc/app/page.tsxsrc/components/button-icon.tsxsrc/components/card-split/index.tsxsrc/components/card-split/primary-content.tsxsrc/components/card-split/secondary-content.tsxsrc/components/footer.tsxsrc/components/ui/button.tsx
💤 Files with no reviewable changes (1)
- src/app/page.tsx
| className?: string | ||
| }) { | ||
| return ( | ||
| <Button variant={variant} size="lg"> | ||
| <Button variant={variant} size={size}> |
There was a problem hiding this comment.
Wire className through or remove it from the props API.
Line 17 exposes className, but it’s never used (not destructured and not passed to Button on Line 20), so consumers get no effect.
Suggested fix
export function ButtonIcon({
variant = "primary",
icon: Icon,
children,
iconPosition = "left",
size,
+ className,
}: {
variant?: "primary" | "tertiary" | "tertiaryBlur"
icon: IconType
children: ReactNode
iconPosition?: "left" | "right"
size: ButtonSizes
className?: string
}) {
return (
- <Button variant={variant} size={size}>
+ <Button variant={variant} size={size} className={className}>
{iconPosition === "left" && <Icon />}
{children}
{iconPosition === "right" && <Icon />}
</Button>
)
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/button-icon.tsx` around lines 17 - 20, The prop className is
declared but never forwarded to the rendered Button; update the ButtonIcon
component in button-icon.tsx to either remove className from its props API or
forward it: destructure className from the component props and pass it into the
rendered <Button> (e.g., pass className={className} or merge it with existing
classes) so consumers can style the Button, or if you intentionally don't want
external classes, remove className from the props definition and usages.
Closes #10