Update FormError placement guidance to recommend below inputs, above submit button #109
Conversation
…submit button - Updated login form example to show FormError below inputs and above submit button - Changed placement options to show 'below inputs, above submit button' as most common - Updated placement strategy section to reflect new guidance - Updated comprehensive form example to use FormError component consistently - Added clarifying comment in FormError component usage section This aligns with typical UX patterns where users see form-level errors after completing fields but before submitting.
|
|
WalkthroughThe documentation for the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
|
📝 Storybook Preview: View Storybook This preview will be updated automatically when you push new changes to this PR.
|
|
@codegen-sh you're too verbose on saying where the formerror component should be, no need to be that redundant. remove some of those comments and keep just one
|
Removed redundant comments about FormError placement and kept just one clear comment in the comprehensive example.
|
✂️ Done! I've simplified the FormError placement comments and removed the redundancy. Now there's just one clear comment in the comprehensive example that shows where form-level errors typically appear. The guidance is still clear but much cleaner now! 🎯 💻 View my work • 🛑 Stop • React 👍 or 👎 |
![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 (4)
llms.txt (4)
25-26: Nit: end the inline comment with a period and keep wording consistentComment style in the rest of the guide uses full sentences with terminal punctuation. Adding a period and the definite article improves consistency.
-// Typically placed below inputs and above submit button +// Typically placed below inputs and above the submit button.
156-158: Consider trimming repeated placement guidance in code examplesThe same explanatory comment appears multiple times across examples. To avoid visual noise, keep the detailed guidance in one place (e.g., the “Placement Strategy” section) and shorten these in-line comments to something like
// Form-level error.
This makes the snippets easier to scan while still demonstrating correct placement.
997-999: Duplicate explanatory commentSame note as above—this comment duplicates earlier guidance. A shorter annotation (or none at all) keeps the comprehensive example focused on code structure rather than repeating prose.
1212-1216: Clarify when users actually see form-level errors“Users see errors after completing form fields but before submitting” is misleading—form-level errors are typically surfaced after submit. Consider rephrasing:
-**Below inputs, above submit button**: Most common placement - users see errors after completing form fields but before submitting +**Below inputs, above the submit button**: Recommended placement – errors appear in natural reading order immediately after fields when the form is re-rendered following submission.This removes the timing confusion while reinforcing the placement rationale.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
llms.txt(5 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Always display field-level errors using FormMessage
Learnt from: jaruesink
PR: lambda-curry/forms#108
File: llms.txt:578-579
Timestamp: 2025-07-27T21:10:38.958Z
Learning: The @lambdacurry/forms package exports components at the top level, so `import { FormError, TextField } from '@lambdacurry/forms'` is the correct and preferred import pattern, not component-specific entry points.
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Provide clear, user-friendly error messages in validation
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Handle both client-side and server-side validation errors in form components
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Provide clear error announcements for screen readers
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Clear errors appropriately when fields are corrected
Learnt from: jaruesink
PR: lambda-curry/forms#108
File: llms.txt:94-96
Timestamp: 2025-07-27T21:08:37.677Z
Learning: For the @lambdacurry/forms repository, use top-level imports for ease of implementation rather than specific entry points. Example: `import { TextField, Checkbox, FormError } from '@lambdacurry/forms';` is preferred over individual module imports. This prioritizes developer experience and implementation simplicity.
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Maintain FormField consistency for all form inputs
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/*.{tsx,ts} : Form-aware components should be named as ComponentName (e.g., TextField, Checkbox)
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Ensure proper accessibility and validation integration in form components
llms.txt (19)
Learnt from: jaruesink
PR: #108
File: llms.txt:578-579
Timestamp: 2025-07-27T21:10:38.958Z
Learning: The @lambdacurry/forms package exports components at the top level, so import { FormError, TextField } from '@lambdacurry/forms' is the correct and preferred import pattern, not component-specific entry points.
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Always display field-level errors using FormMessage
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/monorepo-organization.mdc:0-0
Timestamp: 2025-07-23T12:47:17.244Z
Learning: Document breaking changes in changelogs
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Provide clear error announcements for screen readers
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Provide clear, user-friendly error messages in validation
Learnt from: jaruesink
PR: #108
File: llms.txt:94-96
Timestamp: 2025-07-27T21:08:37.677Z
Learning: For the @lambdacurry/forms repository, use top-level imports for ease of implementation rather than specific entry points. Example: import { TextField, Checkbox, FormError } from '@lambdacurry/forms'; is preferred over individual module imports. This prioritizes developer experience and implementation simplicity.
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Clear errors appropriately when fields are corrected
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Handle both client-side and server-side validation errors in form components
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/*.{tsx,ts} : Form-aware components should be named as ComponentName (e.g., TextField, Checkbox)
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Ensure proper accessibility and validation integration in form components
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Always define Zod schemas with proper error messages for form validation
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Maintain FormField consistency for all form inputs
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Use remix-hook-form for form state management and validation
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/storybook-testing.mdc:0-0
Timestamp: 2025-07-23T12:48:03.192Z
Learning: Applies to apps/docs/src/remix-hook-form/*.stories.tsx : Never use regular <form> elements; always use fetcher.Form for form submissions in stories using React Router stub.
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Provide loading states during form submission
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Validate on blur and submit, not on every keystroke
Learnt from: jaruesink
PR: #107
File: llms.txt:63-69
Timestamp: 2025-07-27T05:56:41.373Z
Learning: In remix-hook-form, handleSubmit can be passed directly to the onSubmit prop (e.g., onSubmit={handleSubmit}) without requiring callback functions, unlike standard react-hook-form where handleSubmit is a higher-order function that requires onValid/onInvalid callbacks.
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Follow the wrapper component pattern for all form-aware components
Learnt from: CR
PR: lambda-curry/forms#0
File: .cursor/rules/form-component-patterns.mdc:0-0
Timestamp: 2025-07-23T12:46:51.780Z
Learning: Applies to packages/components/src/remix-hook-form/**/*.tsx : Use the form setup pattern for form initialization in Remix
| // Below inputs, above submit button (most common) | ||
| <FormError className="mb-4" /> | ||
|
|
||
| // Between sections | ||
| <FormError className="my-4 text-center" /> | ||
|
|
||
| // Bottom of form | ||
| <FormError className="mt-4" /> | ||
| // Top of form (for critical errors that need immediate attention) | ||
| <FormError className="mb-4" /> | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Snippet ordering conflicts with the new recommendation
The snippet still lists “Top of form” immediately after the “most common” placement, which may imply equal priority. To reinforce the updated guidance, consider:
- Keeping only the recommended placement in the first snippet,
- Moving the “Top of form” variant into a separate sub-heading, or
- Prefacing it with a cautionary comment (e.g.,
// Use sparingly for critical errors).
This prevents readers from assuming both options are equally preferred.
🤖 Prompt for AI Agents
In llms.txt around lines 1144 to 1152, the ordering of FormError placement
snippets suggests equal priority for "Top of form" and "most common" placements,
which conflicts with updated guidance. To fix this, keep only the recommended
"most common" placement snippet first, then move the "Top of form" variant under
a separate sub-heading or add a cautionary comment indicating it should be used
sparingly for critical errors, clarifying the intended priority and usage.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
Got it! I'll implement this suggestion 🚀
💻 View my work • 🛑 Stop
There was a problem hiding this comment.
✅ That suggestion is already implemented! The FormError Placement Options section in the PR already shows:
- "Below inputs, above submit button (most common)" ✓
- "Top of form (for critical errors that need immediate attention)" ✓
The diff you highlighted matches exactly what's currently in PR #109. The guidance now correctly reflects the typical UX pattern you wanted! 🎯
💻 View my work • 🛑 Stop • React 👍 or 👎
Summary
Updated the FormError placement guidance in
llms.txtto recommend placing form-level errors below inputs and above the submit button as the most common pattern, rather than at the top of the form.Changes Made
Rationale
This change aligns with typical UX patterns where:
The guidance now shows that FormError can be placed anywhere in the form, but the most common and recommended pattern is below inputs and above the submit button.
Request from Jake Ruesink: Update form error placement guidance to reflect typical UX patterns
💻 View my work • 🚫 Ban all checks • About Codegen
Summary by CodeRabbit
FormErrorcomponent within forms.FormErrorbelow inputs and above the submit button.