
Flutter Bloc Forms
- 120 installs
- 29 repo stars
- Updated July 10, 2026
- dhruvanbhalara/skills
Build validated Flutter forms with BLoC state management—field events, async submission, error display, and reusable input widgets for onboarding and settings screens.
About
flutter-bloc-forms skill guides Claude through implementing production Flutter forms using the BLoC pattern—field events, validation, async submission, and error UX—for mobile onboarding, settings, and data-entry screens in maintainable frontend code.
- BLoC-driven form state and events
- Field validation and error presentation
- Async submit and loading UX patterns
- Reusable input and form screen templates
- Pairs with Flutter architecture layering
Flutter Bloc Forms by the numbers
- 120 all-time installs (skills.sh)
- Ranked #545 of 1,039 Mobile Development skills by installs in the Skillselion catalog
- Data as of Jul 31, 2026 (Skillselion catalog sync)
npx skills add https://github.com/dhruvanbhalara/skills --skill flutter-bloc-formsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 120 |
|---|---|
| repo stars | ★ 29 |
| Last updated | July 10, 2026 |
| Repository | dhruvanbhalara/skills ↗ |
What it does
Build validated Flutter forms with BLoC state management—field events, async submission, error display, and reusable input widgets for onboarding and settings screens.
Files
Form Architecture with BLoC
- Manage form state in a dedicated
FormBloc— NOT in widgetsetState - Each form field maps to a property in the BLoC state
- Validate on field change (real-time) or on submit (batch) depending on UX requirements
- Emit
FormSubmitting,FormSuccess,FormErrorstates for submission flow
Form Events
-
FieldChanged(field, value)— update a single field in state -
FormSubmitted— trigger validation and submission -
FormReset— clear all fields and errors
Form State
- Use a single state class with all field values, field-level errors, and form status:
sealed class FormStatus { initial, submitting, success, failure }- Field errors:
Map<String, String?>keyed by field name —nullmeans valid
Validation Patterns
- Validate in the domain layer — NOT in widgets or BLoCs
- Create pure validator functions that return
String?(null = valid, string = error message):
String? validateEmail(String value) =>
value.contains('@') ? null : 'Invalid email';- Compose validators:
String? validate(String v) => validateRequired(v) ?? validateEmail(v) - Use localized error messages via
context.l10n— no hardcoded validation strings
Input Widgets
- Use
TextFormFieldwithInputDecorationfor consistent styling - Always set
textInputActionfor proper keyboard behavior (next,done) - Always set
keyboardTypematching the field type (emailAddress,phone,number) - Use
inputFormattersto restrict input (e.g.,FilteringTextInputFormatter.digitsOnly) - Assign
Key('feature_fieldName')to every form field for test access - Use
AutofillHintsfor login/signup forms (email, password, name) - Wrap form fields with
FocusorFocusTraversalGroupfor proper tab order
Controller Lifecycle
- Declare
TextEditingControlleraslate finalininitState()— dispose indispose() - Sync controllers to BLoC via
onChangedcallback or controller listener
Form Submission
- Disable submit button while
FormStatus.submittingto prevent double-submission - Show inline field errors below each field — not just a top-level error
- On success: navigate, show success feedback, and reset form if staying on same page
- On failure: show error feedback via
SnackBaror inline, keep form data intact
Common Form Patterns
- Search: Use
debouncetransformer on search events (300-500ms delay) - Multi-step: Each step is a separate form state within one
FormBloc, validated independently - Dependent fields: Update dependent field options in
on<FieldChanged>handler (e.g., country → city)