Flutter BLoC
Use BLoC/Cubit only when it matches the repository or the feature complexity.
Decisions
- Local state: ephemeral UI-only state.
- Cubit: simple feature state and direct actions.
- BLoC: complex event-driven flows, auditability, concurrency, strict transitions.
- Existing repo pattern wins over personal preference.
Rules
- Keep events user/system-intent focused.
- Keep states immutable and explicit.
- Avoid boolean soup; prefer clear status/value objects or sealed variants when available.
- Keep side effects in BLoC/Cubit or services, not widgets.
- Use
BlocListenerfor one-off effects. - Use
BlocSelectororbuildWhenfor narrow rebuilds. - Test success, failure, loading, empty, cancellation/concurrency cases when relevant.
- Use
bloc_testandmocktailonly when already present or accepted by the repo.
Output
- Existing state pattern
- Cubit/BLoC choice and why
- State model
- Event/action flow
- Tests and validation
Source: oElberte/dotfiles — distributed by TomeVault.