setState() — podstata, mechanismus fungování a použití

Co je setState()?

setState() — vestavěná metoda třídy State ve Flutter, určená k upozornění frameworku, že se vnitřní stav widgetu změnil a je třeba přestavět UI. Bez zavolání setState Flutter o změnách neví — i když byla pole State modifikována, rozhraní zůstane nezměněné až do dalšího vynuceného přestavění rodičem.

Signatura metody: void setState(VoidCallback fn). Callback se provádí synchronně uvnitř setState a teprve po jeho dokončení je State označen jako dirty. To zaručuje, že všechny změny jsou aplikovány atomicky před přestavbou. Podle Dart Language Specification (Dart Team, 2026) atomicita setState zabraňuje závodním stavům, kde by build mohl vidět částečně aktualizovaný stav.

setState nepřijímá argumenty, nevrací hodnotu a nelze jej přepsat. Je to konečná (sealed) metoda třídy State. Vývojář nemůže změnit její chování — může ji pouze používat podle určení. Pokus o zavolání setState mimo State (např. z jiné třídy) je nemožný, protože metoda je deklarována ve třídě State.

setState nemění stav — měníte jej vy

Častá mylná představa — že setState sám mění stav. To není pravda. setState pouze volá předaný callback (ve kterém vývojář mění pole) a poté signalizuje frameworku potřebu build. Callback je povinný — předání null nebo prázdného callbacku způsobí chybu.

Jak funguje setState()?

Mechanismus fungování setState() lze rozdělit do čtyř fází. První — zavolání metody s callbackem. Druhá — synchronní provedení callbacku, uvnitř kterého se mění pole State. Třetí — State je označen jako dirty ve speciálním poli _dirty. Čtvrtá — na konci aktuální microtask Flutter projde všechny dirty prvky a zavolá jejich build v pořadí výskytu ve stromu.

Důležitý detail: setState nevolá build okamžitě. Flutter používá strategii dávkové aktualizace: všechny dirty prvky jsou shromážděny a přestavěny v jednom snímku. To znamená, že pokud je setState zavolán několikrát v rámci jednoho synchronního bloku, build se provede pouze jednou — po dokončení všech změn. Tato optimalizace zabraňuje vícenásobným přestavbám v jednom snímku.

Podle Flutter Engine Team (Google, 2025) je mechanismus dirty-příznaků založen na průchodu BuildOwner._dirtyElements. Každý dirty StatefulElement je přidán do seznamu a zpracován ve fázi aktualizace snímku. Pokud byl widget ze stromu odstraněn před zpracováním, je automaticky vyloučen ze seznamu dirty prvků.

Záruky setState

• Callback se provádí synchronně před označením dirty
• build je volán nejvýše jednou za snímek (i při vícenásobném setState)
• Aktualizace UI nastává v následujícím snímku (obvykle ~16ms při 60 FPS)
• Po dispose je volání zakázáno — vyhazuje se výjimka
• Během build je volání setState zakázáno — nekonečná smyčka

Příklady kódu v Dart

Základní příklad setState() s inkrementací čítače. Demonstruje správné použití: změna pole uvnitř callbacku:

class _CounterState extends State<CounterWidget> {
  int _count = 0;

  void _increment() {
    setState(() {
      _count++; // mutace pole uvnitř callbacku
    });
  }

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: _increment,
      child: Text('$_count'),
    );
  }
}

Příklad s textovým polem a controllerem — setState() pro správu viditelnosti hesla:

class _PasswordFieldState extends State<PasswordField> {
  bool _obscured = true;
  final _controller = TextEditingController();

  void _toggleVisibility() {
    setState(() {
      _obscured = !_obscured;
    });
  }

  @override
  Widget build(BuildContext context) {
    return TextField(
      controller: _controller,
      obscureText: _obscured,
      decoration: InputDecoration(
        suffixIcon: IconButton(
          icon: Icon(_obscured ? Icons.visibility : Icons.visibility_off),
          onPressed: _toggleVisibility,
        ),
      ),
    );
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }
}

V tomto příkladu setState() mění pouze boolean pole _obscured, což způsobí přestavbu TextField s novou ikonou a režimem zobrazení. Textový controller není znovu vytvářen — je inicializován jednou v initState a uvolněn v dispose.

Více mutací v jednom setState

Pokud je třeba změnit několik polí, všechny změny se provádějí uvnitř jednoho setState. To zaručuje, že build uvidí konzistentní stav:

setState(() {
  _isLoading = false;
  _items = newItems;
  _error = null;
});

Tři pole se mění v jednom callbacku — build se provede jednou a uvidí všechny změny současně. Pokud by každé volání bylo samostatné setState, build by se stejně provedl jednou díky dávkovému zpracování dirty prvků.

Asynchronnost a setState

Jeden z nejdůležitějších nuancí setState() — jeho chování s asynchronními operacemi. Callback setState se provádí synchronně, ale pokud je uvnitř něj zavolán await, kód po await se provede až po dokončení setState. To znamená, že změny polí po await nebudou zachyceny aktuálním setState.

Správný přístup: asynchronní operace se provádí mimo setState a setState se volá po jejím dokončení. Veškerý kód mezi obdržením výsledku a voláním setState se provádí v synchronním kontextu po await:

// SPRÁVNĚ: await mimo setState
Future<void> _loadData() async {
  final result = await ApiService.fetchData();
  setState(() {
    _data = result;
    _isLoading = false;
  });
}

// ŠPATNĚ: await uvnitř setState — žádná záruka aktualizace
void _loadDataWrong() {
  setState(() async {
    _data = await ApiService.fetchData(); // setState se vrátí před dokončením await
    _isLoading = false; // tento kód není zachycen setState
  });
}

Podle dokumentace Flutter (Dart async patterns, 2026) je předávání async-callbacku do setState antipattern, protože setState očekává VoidCallback (synchronní funkci), zatímco async funkce vrací Future, který je ignorován. Změny po prvním await v takovém callbacku nebudou frameworkem správně zpracovány.

Kontrola mounted v asynchronních scénářích

Před voláním setState() po asynchronní operaci vždy zkontrolujte mounted:

if (mounted) {
  setState(() => _data = data);
}

Pokud byl widget během provádění asynchronní operace odstraněn ze stromu, mounted bude false a setState se neprovolá. To zabraňuje výjimce a úniku zdrojů.

Výkon a optimalizace

setState() — pohodlný, ale potenciálně nákladný mechanismus, pokud se používá bez rozmyslu. Každé zavolání setState přestaví celý widget a všechny jeho potomky (pokud nejsou const). V hlubokých stromech nebo při častých voláních to může vést k poklesu FPS.

Hlavní strategie optimalizace: minimalizovat oblast přestavby (přesunout proměnlivé části UI do samostatných StatefulWidget), používat const pro neměnné potomky a vyhýbat se volání setState v rodičovských widgetech, pokud se změnil pouze malý detail UX. Pokud je stav aktualizován s vysokou frekvencí (animace, datový tok), zvažte AnimatedBuilder nebo ValueListenableBuilder.

Podle Flutter Performance Best Practices (Flutter.dev, únor 2026) profilování reálných aplikací ukazuje, že až 40 % všech volání setState lze nahradit const potomky widgetů nebo reaktivními buildery (StreamBuilder, FutureBuilder). To snižuje průměrnou dobu stavby snímku o 15–25 %.

Kdy je setState nadbytečný

Alternativy k setState

Navzdory všestrannosti setState() se ve velkých projektech používá hlavně pro lokální stav. Pro globální nebo sdílený stav se používají specializovaná řešení, z nichž každé nahrazuje nebo obaluje setState.

Provider používá ChangeNotifier + notifyListeners jako analog setState, ale s možností odběru více widgetů. Bloc používá Streams — stav se mění přidáváním událostí do StreamController. Riverpod kombinuje přístupy a nabízí lokální (StateProvider) i asynchronní (AsyncNotifier) správu bez vazby na StatefulWidget. Všechny tři přístupy odstraňují potřebu ručně volat setState — aktualizace UI probíhá automaticky při změně dat.

Podle Flutter Community Survey 2025 (Flutter Foundation, prosinec 2025) 74 % vývojářů používá alespoň jeden nástroj pro správu stavu kromě setState. Přitom 92 % nadále používá setState pro lokální data textového pole, checkboxu nebo jednoduchého čítače — to je považováno za best practice.

Kdy ponechat setState

• Stav je používán pouze jedním widgetem
• Jednoduchá boolean nebo číselná hodnota (fokus, viditelnost, čítač)
• Prototypování a rychlé experimenty
• Controllery (TextEditingController, PageController) stejně vyžadují StatefulWidget

Typické chyby

První a nejnebezpečnější chyba — volání setState po dispose. Asynchronní operace začala v initState, uživatel opustil obrazovku, widget byl odstraněn a callback asynchronní operace volá setState — aplikace spadne s výjimkou. Řešení — vždy před voláním zkontrolujte mounted.

Druhá chyba — volání setState uvnitř build. To vede k nekonečné smyčce: build → setState → dirty → build → setState → ... Flutter takové volání neblokuje (dostanete StackOverflowError). setState lze volat pouze jako reakci na událost (stisk tlačítka, dokončení Future, přijetí dat z toku).

Třetí chyba — změna polí State bez volání setState. Vývojář napíše _count++ a očekává, že se UI aktualizuje. Flutter nedokáže automaticky sledovat změny polí — potřebuje explicitní signál přes setState. To je zásadní rozdíl oproti reaktivním frameworkům jako Vue.js, kde změna dat automaticky spouští aktualizaci.

Čtvrtá chyba — volání setState s asynchronním callbackem (async-lambda). Jak je popsáno v sekci o asynchronnosti, změny po await nebudou zachyceny, což vede k obtížně reprodukovatelným chybám. Používejte synchronní callback a volejte setState po await.

Poznámka k bezpečnému setState

• Vždy kontrolujte mounted v asynchronních callbackích
• Nevolejte setState uvnitř build
• Nepředávejte async-lambdu do setState
• Neměňte pole State mimo setState
• Pokud měníte více polí — dělejte to v jednom setState