flutter

Flutter

Purpose

Build Flutter applications whose widget tree rebuilds only where it must. Flutter's performance model is simple and unforgiving: a setState at the top of the tree rebuilds everything below it.

When to Use

• Building or reviewing a Flutter application.
• Choosing and applying a state-management approach.
• Diagnosing jank or excessive rebuilds.
• Integrating with platform-native code.

Capabilities

• Widget composition and the StatelessWidget/StatefulWidget boundary.
• State management with Riverpod, Bloc, or Provider — and when plain state suffices.
• Build-method optimization: const constructors, selective rebuilds, keys.
• Async: Future, Stream, FutureBuilder, and their failure states.
• Platform channels for native functionality.

Inputs

• The feature set and target platforms.
• The current state-management approach, if any.
• The jank or rebuild symptom, if debugging.

Outputs

• A widget tree where rebuilds are scoped to what changed.
• State that is testable without a widget tree.
• Async UI that handles loading, error, and empty explicitly.

Workflow

1. Compose small widgets — A 300-line build method rebuilds as one unit. Extracting subtrees into widgets is the primary performance tool in Flutter, not a style preference.
2. Mark everything possible const — A const widget is never rebuilt. This is the cheapest optimization available and most codebases leave it on the table.
3. Scope the rebuild — Consumer, Selector, or a Riverpod provider that watches one field. setState in a parent rebuilds every child that is not const.
4. Handle all three async states — Loading, error, and data. FutureBuilder without an error branch shows a spinner forever when the request fails.
5. Profile in profile mode — Debug mode is meaningfully slower and will mislead you in both directions. Use the DevTools timeline on a real device.

Best Practices

• const constructors are the highest-leverage change in most Flutter codebases. Enable prefer_const_constructors in the linter and fix every warning.
• Never build a widget inside a build method as a function call (Widget _buildHeader()). It defeats the element-tree diffing entirely. Extract a real widget class.
• Keys matter when reordering or removing items from a list of stateful widgets. Without them, state attaches to the wrong item.
• Business logic does not belong in a widget. If it cannot be tested without pumping a widget tree, it is in the wrong place.
• ListView.builder, not ListView(children: [...]), for anything that could be long. The latter builds every child immediately.
• An AnimationController without a dispose is a leak that ticks forever.