agentleFS
evancaevanca/flutter-ai-rules/skills/flutter-change-notifier/SKILL.md

flutter-change-notifier

Skill669 starsChanged 3 months agoMITView on GitHub

Use when setting up ChangeNotifier models, providing them to the widget tree, consuming state with Consumer or Provider.of, or optimizing rebuilds.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 3 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Place shared state above the widgets that use it in the widget tree.

    line 35
  2. Distinctive:

    Never directly mutate widgets or call methods on them to change state — rebuild widgets with new data instead.

    line 36
  3. Very specific:

    Use MultiProvider when you need to provide multiple models:

    line 50
  4. Very specific:

    Always specify the generic type (Consumer<CartModel>, not Consumer).

    line 80
  5. Very specific:

    Use the child parameter to pass widgets that don't depend on the model — they are built once and reused.

    line 81
  6. Very specific:

    Place Consumer widgets as deep in the widget tree as possible to minimize the scope of rebuilds:

    line 82
  7. Very specific:

    Use Provider.of<T>(context, listen: false) when you only need to call methods on the model, not react to state changes:

    line 98
  8. Very specific:

    Do not wrap large widget subtrees in a Consumer if only a small part depends on the model.

    line 108
  9. Distinctive:

    Avoid rebuilding widgets unnecessarily — structure your widget tree and provider usage carefully.

    line 109
  10. Very specific:

    Use listen: false in callbacks (e.g., onPressed) where you trigger actions but don't need rebuilds.

    line 110
  11. Very specific:

    Write unit tests for your ChangeNotifier models to verify state changes and notifications:

    line 116

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Flutter ChangeNotifier Skill

This skill defines how to correctly use ChangeNotifier with the provider package for state management in Flutter.


1. Model

Extend ChangeNotifier to manage state. Keep internal state private and expose unmodifiable views. Call notifyListeners() on every state change.

class CartModel extends ChangeNotifier {
  final List<Item> _items = [];

  UnmodifiableListView<Item> get items => UnmodifiableListView(_items);

  void add(Item item) {
    _items.add(item);
    notifyListeners();
  }

  void removeAll() {
    _items.clear();
    notifyListeners();
  }
}
  • Place shared state above the widgets that use it in the widget tree.
  • Never directly mutate widgets or call methods on them to change state — rebuild widgets with new data instead.

2. Providing the Model

ChangeNotifierProvider(
  create: (context) => CartModel(),
  child: MyApp(),
)
  • ChangeNotifierProvider automatically disposes of the model when it is no longer needed.
  • Use MultiProvider when you need to provide multiple models:
MultiProvider(
  providers: [
    ChangeNotifierProvider(create: (_) => CartModel()),
    ChangeNotifierProvider(create: (_) => UserModel()),
  ],
  child: MyApp(),
)

3. Consuming State

Consumer

Consumer<CartModel>(
  builder: (context, cart, child) => Stack(
    children: [
      if (child != null) child,
      Text('Total price: ${cart.totalPrice}'),
    ],
  ),
  child: const SomeExpensiveWidget(), // rebuilt only once
)
  • Always specify the generic type (Consumer<CartModel>, not Consumer).
  • Use the child parameter to pass widgets that don't depend on the model — they are built once and reused.
  • Place Consumer widgets as deep in the widget tree as possible to minimize the scope of rebuilds:
HumongousWidget(
  child: AnotherMonstrousWidget(
    child: Consumer<CartModel>(
      builder: (context, cart, child) {
        return Text('Total price: ${cart.totalPrice}');
      },
    ),
  ),
)

Provider.of with listen: false

Use Provider.of<T>(context, listen: false) when you only need to call methods on the model, not react to state changes:

Provider.of<CartModel>(context, listen: false).removeAll();

4. Optimization Rules

  • Do not wrap large widget subtrees in a Consumer if only a small part depends on the model.
  • Avoid rebuilding widgets unnecessarily — structure your widget tree and provider usage carefully.
  • Use listen: false in callbacks (e.g., onPressed) where you trigger actions but don't need rebuilds.

5. Testing

Write unit tests for your ChangeNotifier models to verify state changes and notifications:

test('adding item updates total', () {
  final cart = CartModel();
  var notified = false;
  cart.addListener(() => notified = true);

  cart.add(Item('Book'));

  expect(cart.items.length, 1);
  expect(notified, isTrue);
});

References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.