flutter-controller-pattern

Use a controller pattern where widgets dispatch intents and controllers coordinate use cases, moving business logic out of Flutter widgets with Riverpod. This centralizes orchestration and keeps domain rules in use cases.

The controller pattern in Flutter is a design approach where controllers own UI orchestration and expose explicit intent and query APIs. Widgets dispatch intents to the controller, which coordinates domain logic and use cases without cluttering the widget tree.

Test Riverpod controllers by verifying controller state, orchestration logic, and widget dispatch intents. The pattern requires controllers to provide tests for transitions and widget dispatch, ensuring centralized UI logic is fully testable.

Yes, you can migrate from an older provider-based pattern to a Riverpod controller by replacing old providers with a keepAlive controller. Connect your widget intents to the new controller to establish clear responsibility boundaries.

You should avoid the controller pattern for Flutter UI logic when a feature lacks centralized orchestration needs or does not require reusable intent methods across multiple widgets. Simple stateless widgets without domain rules do not need this orchestration layer.