Fix email validation in contact form#504
Conversation
✅ Deploy Preview for github-spy ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughTwo independent updates: Vite devDependency upgraded from ^5.4.10 to ^8.0.14 with package.json formatting cleanup; Contact form submission refactored to use native HTML form element with onSubmit handler instead of button click handler. ChangesVite Dependency Update
Contact Form Submission Refactoring
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🎉 Thank you @Official-Prasad for your contribution. Please make sure your PR follows https://github.com/GitMetricsLab/github_tracker/blob/main/CONTRIBUTING.md#-pull-request-guidelines
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 `@package.json`:
- Line 65: The package.json bump to "vite": "^8.0.14" requires follow-up: ensure
Node engine and build tooling are upgraded (Node ~20.19+/22.12+), and upgrade
plugin deps that list Vite 8 support — specifically update `@vitejs/plugin-react`
to a release that declares Vite 8 compatibility and verify or bump
`@vitejs/plugin-react-swc`; keep vitest@^4.1.6 (compatible) but run dev/build/test
locally and in CI to catch Rollup/Vite 8 bundler issues, and update any config
adapters or rollup plugins that report peerDependency conflicts after changing
vite, `@vitejs/plugin-react`, and `@vitejs/plugin-react-swc` in package.json.
In `@src/pages/Contact/Contact.tsx`:
- Around line 206-212: The form currently prevents default and calls
handleSubmit() but never collects user input; add name attributes to the four
fields (the name text input, email input, subject select, and message textarea)
and then update handleSubmit to actually read and send the values—either by
making the fields controlled with useState (create state vars and wire
value/onChange for inputs and use those in handleSubmit) or by changing
handleSubmit to accept the submit event and use new FormData(e.currentTarget) to
extract name,email,subject,message and then perform the existing async/send
logic and success popup; ensure you update the form onSubmit to forward the
event or data to handleSubmit accordingly.
- Around line 312-324: The submit button is absolutely positioned inside the
textarea container (the <button> with props type="submit",
disabled={isSubmitting} and child <Send />) which can obscure typed text; fix by
moving that button out of the textarea wrapper so it renders as a sibling below
the <textarea> (or alternatively remove absolute positioning and add sufficient
bottom padding to the textarea's container and adjust tabindex/flow so the
button follows normal DOM order), ensure styles for the moved button preserve
existing visual variants that use isSubmitting and the same class names, and
verify keyboard/focus order and visible focus ring remain correct after
relocation.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 94cfaaf7-c54a-45d9-8eb4-ba11890f3fe4
📒 Files selected for processing (2)
package.jsonsrc/pages/Contact/Contact.tsx
| "typescript-eslint": "^8.59.3", | ||
|
|
||
| "vite": "^5.4.10", | ||
| "vite": "^8.0.14", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does Vite version 8.0.14 exist and what is the latest stable Vite version?
💡 Result:
Yes. Vite version 8.0.14 exists (it’s published as vite@8.0.14, with a May 21, 2026 release date) [1][2][3]. Latest stable Vite version (as of 2026-05-25): 8.0.14 [4][5][6].
Citations:
- 1: https://npmx.dev/package/vite/v/8.0.14
- 2: https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md
- 3: vitejs/vite@v8.0.13...v8.0.14
- 4: https://www.npmjs.com/package/vite
- 5: https://registry.npmjs.org/vite
- 6: https://vite.dev/releases
🌐 Web query:
What are the breaking changes between Vite 5 and Vite 8?
💡 Result:
Key breaking changes from Vite 5 → Vite 8 (selected, source-backed items): 1) Vite 7: Node.js requirement bump (and default ESM-only compatibility) Vite 7 requires Node.js 20.19+ and 22.12+ (dropping Node 18). This is a practical breaking change for dev/build environments. [1] 2) Vite 7: Default browser target changed to “baseline-widely-available” In Vite 7, the default build.target changes from 'modules' to 'baseline-widely-available', with updated baseline browser versions. If you rely on the old default target, output and transpilation may change. [1] 3) Vite 7: Several SSR-breaking removals/behavior changes The Vite 7 changelog calls out breaking SSR-related changes such as: removing access to Object in SSR transformed code, removing experimental.skipSsrTransform, and removing HotBroadcaster, among others. [2] 4) Vite 5: Node 18 minimum / CJS Node API deprecation / API cleanup work Vite 5 requires Node.js 18+ and deprecates the CJS Node API. It also documents multiple migration items around reworking define and import.meta.env.* replacement strategy, worker.plugins becoming a function, removal of --https / https: true, and removal of resolvePackageEntry / resolvePackageData. [3] 5) Vite 8 (March 12, 2026): Rolldown replaces the dual bundler setup Vite 8 is the major architectural change where Vite moves to Rolldown as a single unified Rust-based bundler (instead of the previous esbuild+Rollup split). This affects bundling/optimization behavior even if many configs/plugins are auto-converted. [4] 6) Vite 8: Node.js requirement bump (same as Vite 7) The Vite 8 announcement states Vite 8 requires Node.js 20.19+, 22.12+ (same ranges as Vite 7). [4] 7) Vite 8: Additional explicit breaking changes in the 8.0.0 changelog The Vite 8.0.0 changelog lists breaking changes including: - removing import.meta.hot.accept resolution fallback - updating the default browser target - the “rolldown-vite” merge [5] 8) If you maintain Rollup/Vite plugin-tooling: Vite 8/rolldown-vite incompatibilities for specific hook/options The Vite migration guide (covering the Rolldown migration in this line of releases) explicitly states Rolldown does not support certain Rollup-like outputs and Vite hooks anymore, e.g. build.rollupOptions.output.format: 'system' and 'amd', plus missing support for hooks like shouldTransformCachedModule, resolveImportMeta, renderDynamicImport, and resolveFileUrl. [6] 9) Vite 8 migration path recommendation: use rolldown-vite first (on Vite 7) For larger projects, Vite recommends a gradual approach: first switch to the rolldown-vite package on Vite 7 to isolate Rolldown-specific issues, then upgrade to Vite 8. [4] Where to look for the full list - Vite 8 migration guide + detailed changes are linked from the official Vite 8 announcement and the Vite migration guide. [4][7] - The authoritative breaking list is in the Vite changelog for the relevant majors (V5, V7, V8). [3][2][5] If you tell me your current versions (e.g., Vite 5.x + framework + Node version) and whether you use any low-level Rollup/Vite hooks, I can narrow this to the most likely breakpoints in your setup.
Citations:
- 1: https://vite.dev/blog/announcing-vite7
- 2: https://github.com/vitejs/vite/blob/v7.0.1/packages/vite/CHANGELOG.md
- 3: https://github.com/vitejs/vite/blob/v8.0.8/docs/blog/announcing-vite5.md
- 4: https://vite.dev/blog/announcing-vite8
- 5: https://github.com/vitejs/vite/blob/8e05b61d/packages/vite/CHANGELOG.md
- 6: https://github.com/vitejs/vite/blob/main/docs/guide/migration.md
- 7: https://vite.dev/guide/migration
🌐 Web query:
Is @vitejs/plugin-react version 4.3.3 compatible with Vite 8?
💡 Result:
Short answer: You should assume @vitejs/plugin-react@4.3.3 is not officially compatible with Vite 8. Why (grounded in sources): - The plugin repo/release notes state that Vite 8 compatibility was added by updating the plugin’s peerDependency range (“Add Vite 8 to peerDependencies”) and explicitly says “This plugin is compatible with Vite 8.” That change is not guaranteed to have been present in version 4.3.3. - npm’s package metadata shows @vitejs/plugin-react has a peer dependency on Vite “^8.0.0”, which indicates compatibility only for plugin versions where that peer range is in effect. Recommendation: upgrade @vitejs/plugin-react to a later version (one that includes the “Vite 8” peerDependencies update) when using Vite 8.
Citations:
- 1: https://github.com/vitejs/vite-plugin-react/releases
- 2: https://registry.npmjs.org/%40vitejs%2Fplugin-react
- 3: https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/CHANGELOG.md
- 4: Unmet peer dependency with Vite 5 vitejs/vite-plugin-react#218
🌐 Web query:
Is vitest version 4.1.6 compatible with Vite 8?
💡 Result:
Yes—Vitest 4.1.6 is compatible with Vite 8. Vitest 4.1 (the line that includes 4.1.6) explicitly added support for Vite 8 [1]. Additionally, Vitest’s migration guide states Vitest 4.0 requires Vite >= 6.0.0, which includes Vite 8 [2]. Finally, the Vitest v4.1.6 release notes/releases activity show this exact version (4.1.6) is part of that Vite 8-capable 4.1 branch [3][4]. Note: some early Vite 8 beta quirks were addressed in Vitest (Vitest removed “vite 8.beta” support), but that’s about the beta period, not Vite 8 stable [5].
Citations:
- 1: https://vitest.dev/blog/vitest-4-1.html
- 2: https://vitest.dev/guide/migration.html
- 3: vitest-dev/vitest@v4.1.5...v4.1.6
- 4: vitest-dev/vitest@a8fd24c
- 5: fix: drop vite 8.beta support vitest-dev/vitest#9862
Vite 8 upgrade needs Node + plugin compatibility follow-up
vite@^8.0.14exists, but the Vite 5 → 8 jump includes breaking changes (notably Node.js requirement bumps to ~20.19+/22.12+ and the Rolldown bundler transition), which can break dev/build/test unless your environment/config are updated.vitest@^4.1.6is compatible with Vite 8, but@vitejs/plugin-react@^4.3.3is not guaranteed to support Vite 8—bump to a version that explicitly declares Vite 8 compatibility.- Also confirm
@vitejs/plugin-react-swcworks with Vite 8 (peerDependency/support may require an upgrade).
🤖 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 `@package.json` at line 65, The package.json bump to "vite": "^8.0.14" requires
follow-up: ensure Node engine and build tooling are upgraded (Node
~20.19+/22.12+), and upgrade plugin deps that list Vite 8 support — specifically
update `@vitejs/plugin-react` to a release that declares Vite 8 compatibility and
verify or bump `@vitejs/plugin-react-swc`; keep vitest@^4.1.6 (compatible) but run
dev/build/test locally and in CI to catch Rollup/Vite 8 bundler issues, and
update any config adapters or rollup plugins that report peerDependency
conflicts after changing vite, `@vitejs/plugin-react`, and
`@vitejs/plugin-react-swc` in package.json.
| <form | ||
| className="space-y-3 sm:space-y-4 flex-1 flex flex-col" | ||
| onSubmit={(e) => { | ||
| e.preventDefault(); | ||
| handleSubmit(); | ||
| }} | ||
| > |
There was a problem hiding this comment.
Form submission doesn't collect or send input data.
The form's onSubmit handler prevents default submission and calls handleSubmit(), but handleSubmit() (lines 19-32) only simulates a delay and shows a success popup—it never reads the form values. The inputs lack name attributes and aren't controlled (no value/onChange), so the user's name, email, subject, and message are never captured or sent anywhere.
📋 Proposed fix to collect form data
- <form
- className="space-y-3 sm:space-y-4 flex-1 flex flex-col"
- onSubmit={(e) => {
- e.preventDefault();
- handleSubmit();
- }}
->
+ <form
+ className="space-y-3 sm:space-y-4 flex-1 flex flex-col"
+ onSubmit={(e) => {
+ e.preventDefault();
+ const formData = new FormData(e.currentTarget);
+ const data = {
+ name: formData.get('name'),
+ email: formData.get('email'),
+ subject: formData.get('subject'),
+ message: formData.get('message'),
+ };
+ handleSubmit(data);
+ }}
+>Then add name attributes to each input:
- Line 225:
<input type="text" name="name" ... - Line 248:
<input type="email" name="email" ... - Line 271:
<select name="subject" ... - Line 301:
<textarea name="message" ...
And update handleSubmit signature to accept and use the data:
- const handleSubmit = async () => {
+ const handleSubmit = async (data?: {name: string; email: string; subject: string; message: string}) => {
setIsSubmitting(true);
- // Simulate API call
+ // TODO: Send data to backend API
+ console.log('Form data:', data);
await new Promise((resolve) => setTimeout(resolve, 1500));🤖 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/pages/Contact/Contact.tsx` around lines 206 - 212, The form currently
prevents default and calls handleSubmit() but never collects user input; add
name attributes to the four fields (the name text input, email input, subject
select, and message textarea) and then update handleSubmit to actually read and
send the values—either by making the fields controlled with useState (create
state vars and wire value/onChange for inputs and use those in handleSubmit) or
by changing handleSubmit to accept the submit event and use new
FormData(e.currentTarget) to extract name,email,subject,message and then perform
the existing async/send logic and success popup; ensure you update the form
onSubmit to forward the event or data to handleSubmit accordingly.
| <button | ||
| type="submit" | ||
| disabled={isSubmitting} | ||
| className={`absolute bottom-2 sm:bottom-3 right-2 sm:right-3 flex items-center gap-1.5 sm:gap-2 rounded-full px-3 sm:px-4 py-1.5 sm:py-2 text-xs sm:text-sm font-semibold transition-all duration-300 hover:scale-105 focus:outline-none focus:ring-2 focus:ring-purple-500 ${ | ||
| isSubmitting | ||
| ? "bg-purple-400 cursor-wait text-white" | ||
| : "bg-purple-600 hover:bg-purple-700 text-white" | ||
| }`} | ||
| > | ||
| > | ||
| {isSubmitting ? "Sending..." : "Send"} | ||
| <Send className="w-4 h-4" /> | ||
| </button> | ||
| </div> |
There was a problem hiding this comment.
Consider accessibility implications of absolutely positioned button.
The submit button is absolutely positioned inside the textarea's container, overlaying the bottom-right corner of the text input area. While this creates a modern chat-like interface, it can cause usability issues:
- Users typing longer messages may have text obscured by the button
- Users with larger font sizes or zoom may find the button covers more of their input
- The 4-row textarea height (line 304) is fixed, so long messages will scroll, but the button always covers the same corner
Unlike the Login and Signup forms in the codebase (see context snippets), which place the submit button outside and below the form inputs, this pattern reduces the effective usable area of the textarea.
Consider moving the button below the textarea or ensuring adequate padding/margin so text is never hidden.
♿ Proposed fix to move button outside textarea
<textarea
placeholder="Type your message here..."
required
rows={4}
className={`w-full p-2 sm:p-3 rounded-lg sm:rounded-xl text-sm sm:text-base resize-none transition-all duration-300 focus:outline-none focus:ring-2 focus:ring-purple-500 ${
mode === "dark"
? "bg-white/5 border border-white/20 text-white placeholder-gray-400"
: "bg-gray-50 border border-gray-300 text-gray-800 placeholder-gray-500"
}`}
></textarea>
+ </div>
- <button
+ <button
type="submit"
disabled={isSubmitting}
- className={`absolute bottom-2 sm:bottom-3 right-2 sm:right-3 flex items-center gap-1.5 sm:gap-2 rounded-full px-3 sm:px-4 py-1.5 sm:py-2 text-xs sm:text-sm font-semibold transition-all duration-300 hover:scale-105 focus:outline-none focus:ring-2 focus:ring-purple-500 ${
+ className={`w-full sm:w-auto sm:ml-auto flex items-center justify-center gap-1.5 sm:gap-2 rounded-full px-4 sm:px-6 py-2 sm:py-3 text-sm font-semibold transition-all duration-300 hover:scale-105 focus:outline-none focus:ring-2 focus:ring-purple-500 ${
isSubmitting
? "bg-purple-400 cursor-wait text-white"
: "bg-purple-600 hover:bg-purple-700 text-white"
}`}
- >
+ >
{isSubmitting ? "Sending..." : "Send"}
<Send className="w-4 h-4" />
</button>
- </div>🤖 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/pages/Contact/Contact.tsx` around lines 312 - 324, The submit button is
absolutely positioned inside the textarea container (the <button> with props
type="submit", disabled={isSubmitting} and child <Send />) which can obscure
typed text; fix by moving that button out of the textarea wrapper so it renders
as a sibling below the <textarea> (or alternatively remove absolute positioning
and add sufficient bottom padding to the textarea's container and adjust
tabindex/flow so the button follows normal DOM order), ensure styles for the
moved button preserve existing visual variants that use isSubmitting and the
same class names, and verify keyboard/focus order and visible focus ring remain
correct after relocation.
1 participant
Related Issue
Description
How Has This Been Tested?
Screenshots (if applicable)
Type of Change
Summary by CodeRabbit
Refactor
Chores