Flutter Dart state management

Keep changing data predictable and make every screen show the current source of truth.

Chapter goal: Keep changing data predictable and make every screen show the current source of truth.

Simple explanation

State is the current memory of an app or screen. A source of truth is the one place that owns the correct current value.

In Flutter Dart, this chapter is about deciding who owns changing data and who is allowed to update it. Start with the idea above. Then connect each symbol to a value or action in the example.

Do not try to remember every symbol. First ask what data the program has, what it does with that data, and what result it creates. Technical words become easier when you connect them to those three questions.

Why this topic is important

Unclear state causes stale screens, duplicated values, and changes that are difficult to trace. In Flutter Dart, the syntax may look different from other languages, but the thinking skill transfers: name the data, choose the right operation, and make the next step obvious.

When to use it

Manage state for counters, forms, authentication, carts, loading, errors, filters, and cached server data.

Example code

class Counter extends StatefulWidget {
  const Counter({super.key});
  State<Counter> createState() => _CounterState();
}
class _CounterState extends State<Counter> {
  int count = 0;
  void increment() => setState(() => count++);
  Widget build(BuildContext context) => Text('Count: $count');
}

Line-by-line explanation

• class Counter extends StatefulWidget { — This begins a class: a blueprint that groups related data and behavior.
• const Counter({super.key}); — This line supports one focused piece of application logic. Read it together with the block directly around it.
• State<Counter> createState() => _CounterState(); — This stores or updates createState(). The value on the right is worked out first, then saved under that name.
• class _CounterState extends State<Counter> { — This begins a class: a blueprint that groups related data and behavior.
• int count = 0; — This stores or updates count. The value on the right is worked out first, then saved under that name.
• void increment() => setState(() => count++); — This stores or updates increment(). The value on the right is worked out first, then saved under that name.
• Widget build(BuildContext context) => Text('Count: $count'); — This stores or updates context). The value on the right is worked out first, then saved under that name.

What the output means

UI output: the screen shows "Count: 0" first. After the button is pressed, setState rebuilds the widget and it shows "Count: 1".

The output is evidence that the program followed the instructions. If your result is different, read from the first line and write down how each value changes. That is debugging, not failure.

Mistake example

class Counter extends StatefulWidget {
  const Counter({super.key});
  State<Counter> createState() => _CounterState();
}
class _CounterState extends State<Counter> {
  int count = null; // the same state is stored in more than one place
  void increment() => setState(() => count++);
  Widget build(BuildContext context) => Text('Count: $count');
}

This version intentionally shows how the same state is stored in more than one place. The changed assignment stores a missing value, or a required line is removed, so later code cannot complete its job safely.

Fixed version

class Counter extends StatefulWidget {
  const Counter({super.key});
  State<Counter> createState() => _CounterState();
}
class _CounterState extends State<Counter> {
  int count = 0;
  void increment() => setState(() => count++);
  Widget build(BuildContext context) => Text('Count: $count');
}

The corrected version restores the real value or required operation. It fixes the chapter-specific problem: the same state is stored in more than one place.

Common mistakes

• Keeping the same state in several places.
• Changing state without notifying its readers.
• Using app-wide state for a value needed by one small component.

Warning: Change one part at a time. If you change many lines together, it becomes harder to learn which change caused the result.

Real use cases

• Update a Flutter widget after setState.
• Manage React state with hooks.
• Track server-owned player state safely in RedM.

Small real-project example

A profile screen tracks whether it is loading, failed, or ready, instead of guessing from partial data.

enum LoadState { loading, error, success }

class ProfileState {
  final LoadState status;
  final String? name;
  const ProfileState(this.status, {this.name});
}

class ProfileNotifier extends ValueNotifier<ProfileState> {
  ProfileNotifier() : super(const ProfileState(LoadState.loading));

  Future<void> load() async {
    value = const ProfileState(LoadState.loading);
    try {
      final name = await fetchProfileName();
      value = ProfileState(LoadState.success, name: name);
    } catch (_) {
      value = const ProfileState(LoadState.error);
    }
  }
}

How the project example works

• LoadState names the three screen states a real profile screen can be in.
• ProfileState bundles the current status with optional data.
• load() sets loading first, so the UI can show a spinner immediately.
• Success stores the name; failure switches to error instead of keeping stale data.

Practice exercise

1. Add a reset action.
2. Keep one source of truth.
3. Explain which code owns the state and which code only reads it.

Tip: If the exercise feels too large, complete only steps 1 to 3. Small working code teaches more than a large unfinished project.

Mini quiz

1. What is a source of truth?
2. Who is allowed to change the state?
3. What causes a stale screen?

How to read AI-generated code

Do not copy AI code first. Read it like a detective. Find the data, follow the changes, and locate the final output. Ask AI to explain a line only after you have made your own guess.

• What data goes in?
• What values are stored?
• What calculation or decision happens?
• What is printed, displayed, saved, or returned?
• What can go wrong?
• Can you rename one value and still explain the code?

Flutter reading check

Find the widget tree first. Then find which values can change, where setState is called, which callback handles the button or TextField, and where navigation or async data enters the screen.

Before you move on

• I can explain this topic in my own words.
• I can read the small example without AI.
• I can change the example and predict the new result.
• I can find and fix one simple mistake.
• I can name one real project that uses this idea.

Next topic

Next, learn best practices and clean code. Before opening it, explain this chapter out loud in under one minute.