fix: cta button still clickable on footer socials #540
Conversation
|
@Complexlity is attempting to deploy a commit to the squirrellabs Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughThe changes introduce an optional Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant HeroComponent
participant Window
User->>HeroComponent: Render component
HeroComponent->>Window: Check for server-side rendering
Window-->>HeroComponent: Return screen width
HeroComponent->>HeroComponent: Initialize screenWidth state
User->>Window: Resize window
Window-->>HeroComponent: Trigger resize event
HeroComponent->>HeroComponent: Update screenWidth state
alt buttonVisible is true
HeroComponent->>User: Show button (pointerEvents: auto)
else buttonVisible is false
HeroComponent->>User: Hide button (pointerEvents: none)
end
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: 0
🧹 Outside diff range and nitpick comments (2)
src/components/LandingPage/hero.tsx (2)
Line range hint
9-17: Improve prop documentationThe comment "New prop" doesn't describe the purpose of
buttonVisible. Consider adding a more descriptive JSDoc comment explaining its purpose and default behavior.- buttonVisible?: boolean // New prop + /** Controls the visibility and interactivity of the CTA button. When false, the button is hidden and non-interactive. */ + buttonVisible?: boolean
Line range hint
26-36: Consider debouncing the resize handlerWhile the current implementation works, frequent resize events could impact performance. Consider debouncing the resize handler to limit the number of state updates.
+import { debounce } from 'lodash' + export function Hero({ heading, marquee = { visible: false }, cta, buttonVisible }: HeroProps) { const [duration, setDuration] = useState(10) const [screenWidth, setScreenWidth] = useState(typeof window !== 'undefined' ? window.innerWidth : 1200) useEffect(() => { - const handleResize = () => { + const handleResize = debounce(() => { setScreenWidth(window.innerWidth) - } + }, 250) handleResize() // Call once initially to set duration window.addEventListener('resize', handleResize) - return () => window.removeEventListener('resize', handleResize) + return () => { + handleResize.cancel() + window.removeEventListener('resize', handleResize) + } }, [])
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
src/components/LandingPage/hero.tsx(1 hunks)
🔇 Additional comments (1)
src/components/LandingPage/hero.tsx (1)
Line range hint 77-85: LGTM! Effectively prevents button interaction when hidden
The addition of pointerEvents style properly handles the button's interactivity state, preventing clicks when the button is hidden. The animation properties create a smooth transition between states.
Let's verify there are no other clickable elements that might need similar treatment:
✅ Verification successful
No other interactive motion.div elements require pointer-events handling
After analyzing the codebase, the current implementation in hero.tsx is the only instance where pointer-events handling is necessary, as it's the only motion.div that contains interactive elements (button) that needs to be disabled when hidden. Other motion.div elements in the codebase are used for visual animations only and don't require pointer-events management.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other potentially interactive elements in the codebase
# that might need similar pointer-events handling
# Look for other motion.div elements that might need similar treatment
ast-grep --pattern 'motion.div'
# Look for other button or anchor elements that might need similar treatment
rg -l 'className="btn-purple"'
Length of output: 1537
Script:
#!/bin/bash
# Let's check the content of these motion.div elements to see if they have interactive elements
# that might need pointer-events handling
# Check hero.tsx for the complete context
rg -A 10 "motion\.div" "src/components/LandingPage/hero.tsx"
# Check other files for motion.div with animation or interactive elements
rg -A 10 "motion\.div.*style=|motion\.div.*animate|motion\.div.*while|motion\.div.*onClick" "src/components/LandingPage/mike.tsx" "src/components/LandingPage/features.tsx" "src/components/LandingPage/BuildOnUs/index.tsx" "src/components/Global/Testimonials/index.tsx" "src/components/Global/FAQs/index.tsx"
Length of output: 901
No description provided.