bug: Hydration warning / client-side state mismatch risk from suppressHydrationWarning on interactive elements

[Aditya8369]

Description

Multiple elements use suppressHydrationWarning even though they rely on client-only state like mounted, username, and trimmedUsername. This can mask real hydration mismatches and lead to UI being rendered in an unexpected state after hydration.

Steps to Reproduce

1. Load the landing page.
2. Immediately type in the username input or click “Generate Badge” before the page finishes hydrating (slow 3G / throttling helps).
3. Observe whether buttons/validation messages briefly show incorrect states.

Expected Behavior

No UI inconsistencies after hydration:
“Generate Badge” disabled/enabled correctly
validation message corresponds to the actual input
badge preview area updates correctly

Screenshots / Logs

No response

GitHub Username (If applicable)

No response

Environment

Chrome

[github-actions]

👋 Hey @Aditya8369, welcome to CommitPulse! 🎉

Thanks for opening your first issue — we're glad you're here.

Before diving in, please take a moment to:

• 📖 Read the CONTRIBUTING.md guide
• 💬 Join our Discord community for faster support and collaboration
• 🏷️ Comment /claim on any open, unassigned issue you'd like to work on

A maintainer will review your issue shortly. Happy contributing! 🚀

[rutul2006]

Hey @JhaSourav07 and the GSSoC Team!

I'd like to work on this hydration mismatch bug as a part of GSSoC '26! This is an important UI consistency issue that can lead to confusing states for users, especially on slower networks or devices.

Why this matters:

• Improved User Experience: Prevents flickering or incorrect states for the "Generate Badge" button, validation messages, and badge preview, ensuring a smooth and predictable experience.
• Eliminates Masked Bugs: Relying on suppressHydrationWarning hides real hydration mismatches instead of fixing them, which can lead to harder-to-debug issues down the line.
• Better Performance on Slow Connections: Users on throttled or unstable connections are more likely to interact before hydration completes, making this fix crucial for accessibility and reliability.
• React Best Practices: Ensuring server and client renders match is key to maintaining a stable Next.js/React application.

Proposed Solution:

• Code Audit: Thoroughly scan the landing page and related components to identify all instances of suppressHydrationWarning that rely on client-only states like mounted, username, or trimmedUsername.
• Fix Root Cause: Implement proper hydration-safe patterns, such as a mounted state gate (useEffect to set mounted to true) to conditionally render client-dependent UI, or render a consistent SSR placeholder until hydration is complete.
• State Derivation: Ensure validation logic and button states are computed only after mounting or use fallback values that match the initial server render to prevent mismatches.
• Component-Level Optimization: Where necessary, leverage Next.js dynamic imports with ssr: false for highly client-dependent components like the badge preview.
• Testing: Reproduce the issue using Chrome DevTools throttling (Slow 3G) and verify fixes by testing rapid input before hydration. Additionally, remove the unnecessary suppressHydrationWarning props and confirm no new warnings appear.
• Documentation: Add brief comments explaining the hydration-safe approach to prevent similar issues in the future.

I'd be happy to share my findings after the initial audit and discuss the best approach for the specific components involved!

Could you please assign this issue to me? I'm excited to fix this bug and enhance the overall stability of the landing page!

Thank you!

[github-actions]

👋 Hey @rutul2006! Looks like you want to work on this issue — awesome! 🎉

We don't assign issues through comments like this. Here's how our system works:

🤖 How to Claim an Issue

Comment /claim on this issue and our bot will automatically assign it to you (if you're eligible).

/claim

⚠️ Note: Only the issue author (@Aditya8369) can /claim this issue. If you'd like to contribute, consider opening a new issue for a bug or feature you've found, then claim that one!

📋 A Few Things to Know

• You can hold a maximum of 5 open issues at a time.
• If there's no activity for 3 days, the assignment will automatically expire so others can pick it up.
• Make sure to read our CONTRIBUTING.md before you start — it covers code style, commit conventions, and the PR checklist.

💬 Join Our Discord

Get faster help, collaborate with other contributors, and stay updated with project news:

Happy contributing! 🚀

[rutul2006]

/claim

[github-actions]

❌ Only the author of this issue (@Aditya8369) can claim it.