setState() — mahiyyəti, iş mexanizmi və tətbiqi

setState() nədir?

setState() — Flutter-də State sinfinə daxil olan, widget-ın daxili vəziyyətinin dəyişdiyi və UI-nin yenidən qurulması zərurəti barədə framework-ə məlumat vermək üçün nəzərdə tutulmuş metoddur. setState çağırılmazsa, Flutter dəyişikliklərdən xəbərdar olmur — State sahələri dəyişdirilsə belə, interfeys valideyn tərəfindən növbəti məcburi yenidən qurmaya qədər dəyişməz qalır.

Metodun imzası: void setState(VoidCallback fn). Callback setState daxilində sinxron şəkildə icra olunur və yalnız onun tamamlanmasından sonra State dirty kimi işarələnir. Bu, bütün dəyişikliklərin yenidən qurmadan əvvəl atomik şəkildə tətbiq olunmasını təmin edir. Dart Language Specification-ə görə (Dart Team, 2026), setState-in atomikliyi build-in qismən yenilənmiş vəziyyəti görə biləcəyi yarış vəziyyətinin qarşısını alır.

setState arqument qəbul etmir, dəyər qaytarmır və ləğv edilə bilməz. Bu, State sinfinin final (sealed) metodudur. Tərtibatçı onun davranışını dəyişə bilməz — yalnız təyinatı üzrə istifadə edə bilər. setState-i State-dən kənarda (məsələn, başqa sinifdən) çağırmaq mümkün deyil, çünki metod State sinfində elan edilmişdir.

setState vəziyyəti dəyişmir — siz dəyişirsiniz

Geniş yayılmış yanlış fikir — setState-in özünün vəziyyəti dəyişdiyini düşünmək. Bu doğru deyil. setState yalnız ötürülən callback-i çağırır (burada tərtibatçı sahələri dəyişir) və sonra framework-ə build ehtiyacı barədə siqnal verir. Callback məcburidir — null və ya boş callback ötürmək xətaya səbəb olacaq.

setState() necə işləyir?

setState()-in iş mexanizmini dörd mərhələyə bölmək olar. Birinci — metodun callback ilə çağırılması. İkinci — callback-in sinxron icrası, onun daxilində State sahələri dəyişdirilir. Üçüncü — State xüsusi _dirty sahəsində dirty (çirkli) kimi işarələnir. Dördüncü — cari mikrotapşırığın (microtask) sonunda Flutter bütün dirty-elementləri gəzir və onların build-ni ağacda görünmə ardıcıllığı ilə çağırır.

Vacib detal: setState build-i dərhal çağırmır. Flutter toplu yeniləmə strategiyasından istifadə edir: bütün dirty-elementlər toplanır və bir kadrda yenidən qurulur. Bu o deməkdir ki, setState bir sinxron blok daxilində bir neçə dəfə çağırılıbsa, build yalnız bir dəfə — bütün dəyişikliklər tamamlandıqdan sonra icra olunacaq. Belə optimallaşdırma bir kadrda çoxsaylı yenidən qurmaların qarşısını alır.

Flutter Engine Team məlumatlarına görə (Google, 2025), dirty-flag mexanizmi BuildOwner._dirtyElements üzərindən keçidə əsaslanır. Hər bir dirty StatefulElement siyahıya əlavə olunur və kadr yeniləmə mərhələsində işlənir. Əgər widget emaldan əvvəl ağacdan silinibsə, o avtomatik olaraq dirty-elementlər siyahısından çıxarılır.

setState zəmanətləri

• Callback dirty işarələməsindən əvvəl sinxron icra olunur
• build hər kadrda birdən çox olmayaraq çağırılır (hətta çoxsaylı setState-də belə)
• UI yeniləməsi növbəti kadrda baş verir (adətən 60 FPS-də ~16ms)
• dispose-dən sonra çağırış qadağandır — istisna atılır
• build zamanı setState çağırışı qadağandır — sonsuz dövr

Dart dilində kod nümunələri

setState()-in sayğac artımı ilə əsas nümunəsi. Düzgün istifadəni nümayiş etdirir: callback daxilində sahənin dəyişdirilməsi:

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

  void _increment() {
    setState(() {
      _count++; // callback daxilində sahənin mutasiyası
    });
  }

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

Mətn sahəsi və kontroller ilə nümunə — setState() şifrə görünməsinin idarə edilməsi üçün:

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();
  }
}

Bu nümunədə setState() yalnız _obscured boolean sahəsini dəyişir, bu da TextField-in yeni ikona və göstərmə rejimi ilə yenidən qurulmasına səbəb olur. Mətn kontrolleri yenidən yaradılmır — o, initState-də bir dəfə işə salınır və dispose-də azad edilir.

Bir setState-də çoxsaylı mutasiyalar

Bir neçə sahəni dəyişmək lazımdırsa, bütün dəyişikliklər bir setState daxilində yerinə yetirilir. Bu, build-in ardıcıl vəziyyəti görməsinə zəmanət verir:

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

Üç sahə bir callback-də dəyişdirilir — build bir dəfə icra olunacaq və bütün dəyişiklikləri eyni anda görəcək. Əgər hər çağırış ayrıca setState olsaydı, build dirty-elementlərin toplu emalı sayəsində yenə də bir dəfə icra olunacaqdı.

Asinxronluq və setState

setState()-in ən vacib nüanslarından biri — onun asinxron əməliyyatlarla davranışı. setState callback-i sinxron icra olunur, lakin onun daxilində await çağırılarsa, await-dən sonrakı kod setState işini bitirdikdən sonra icra olunacaq. Bu o deməkdir ki, await-dən sonrakı sahə dəyişiklikləri cari setState tərəfindən ələ keçirilməyəcək.

Düzgün yanaşma: asinxron əməliyyat setState xaricində yerinə yetirilir və setState onun tamamlanmasından sonra çağırılır. Nəticənin alınması ilə setState çağırışı arasındakı bütün kod await-dən sonra sinxron kontekstdə icra olunur:

// DÜZGÜN: await setState xaricində
Future<void> _loadData() async {
  final result = await ApiService.fetchData();
  setState(() {
    _data = result;
    _isLoading = false;
  });
}

// SƏHV: await setState daxilində — yeniləmə zəmanəti yoxdur
void _loadDataWrong() {
  setState(() async {
    _data = await ApiService.fetchData(); // setState await tamamlanmadan qayıdır
    _isLoading = false; // bu kod setState tərəfindən ələ keçirilmir
  });
}

Flutter sənədlərinə görə (Dart async patterns, 2026), setState-ə async-callback ötürmək antipattern-dir, çünki setState VoidCallback (sinxron funksiya) gözləyir, async funksiya isə nəzərə alınmayan Future qaytarır. Belə callback-də ilk await-dən sonrakı dəyişikliklər framework tərəfindən düzgün işlənməyəcək.

Asinxron ssenarilərdə mounted yoxlanması

Asinxron əməliyyatdan sonra setState() çağırmazdan əvvəl həmişə mounted-i yoxlayın:

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

Əgər widget asinxron əməliyyatın icrası zamanı ağacdan silinibsə, mounted false olacaq və setState çağırılmayacaq. Bu, istisnanın və resurs sızmalarının qarşısını alır.

Performans və optimallaşdırma

setState() — rahat, lakin düşüncəsiz istifadə edildikdə potensial bahalı mexanizmdir. Hər setState çağırışı bütün widget-ı və onun bütün varislərini (const deyillərsə) yenidən qurur. Dərin ağaclarda və ya tez-tez çağırışlarda bu, FPS düşmələrinə səbəb ola bilər.

Əsas optimallaşdırma strategiyaları: yenidən qurma sahəsini minimallaşdırmaq (dəyişən UI hissələrini ayrıca StatefulWidget-lərə çıxarmaq), dəyişməz varislər üçün const istifadə etmək və yalnız kiçik UX detalı dəyişdikdə valideyn widget-larda setState çağırmaqdan qaçmaq. Əgər vəziyyət yüksək tezliklə yenilənirsə (animasiya, məlumat axını), AnimatedBuilder və ya ValueListenableBuilder-ə baxın.

Flutter Performance Best Practices məlumatlarına görə (Flutter.dev, fevral 2026), real tətbiqlərin profilləşdirilməsi göstərir ki, bütün setState çağırışlarının 40%-ə qədərini const uşaq widget-lar və ya reaktiv builder-lər (StreamBuilder, FutureBuilder) ilə əvaz etmək olar. Bu, orta kadr qurma müddətini 15–25% azaldır.

setState nə vaxt artıqdır

setState alternativləri

Çox yönlü olmasına baxmayaraq setState(), böyük layihələrdə əsasən lokal vəziyyət üçün tətbiq olunur. Qlobal və ya paylaşılan vəziyyət üçün hər biri setState-i əvəz edən və ya sarğılayan ixtisaslaşdırılmış həllər istifadə olunur.

Provider ChangeNotifier + notifyListeners-dən setState-in analoqu kimi istifadə edir, lakin bir neçə widget-ın abunə olma imkanı ilə. Bloc Streams-dən istifadə edir — vəziyyət StreamController-ə hadisələr əlavə etməklə dəyişdirilir. Riverpod yanaşmaları birləşdirir, StatefulWidget-ə bağlı olmadan həm lokal (StateProvider), həm də asinxron (AsyncNotifier) idarəetmə təklif edir. Hər üç yanaşma setState-i əl ilə çağırmaq ehtiyacını aradan qaldırır — UI yeniləməsi məlumat dəyişdikdə avtomatik baş verir.

Flutter Community Survey 2025 məlumatlarına görə (Flutter Foundation, dekabr 2025), tərtibatçıların 74%-i setState-dən əlavə ən azı bir vəziyyət idarəetmə alətindən istifadə edir. Eyni zamanda, 92%-i mətn sahəsi, checkbox və ya sadə sayğacın lokal məlumatları üçün setState-dən istifadə etməyə davam edir — bu, best practice hesab olunur.

setState nə vaxt saxlanmalıdır

• Vəziyyət yalnız bir widget tərəfindən istifadə olunur
• Sadə boolean və ya ədədi dəyər (fokus, görünmə, sayğac)
• Prototipləşdirmə və sürətli təcrübələr
• Kontrollerlər (TextEditingController, PageController) onsuz da StatefulWidget tələb edir

Tipik səhvlər

Birinci və ən təhlükəli səhv — dispose-dən sonra setState çağırmaq. Asinxron əməliyyat initState-də başladı, istifadəçi ekranı tərk etdi, widget silindi və asinxron əməliyyatın callback-i setState çağırır — tətbiq istisna ilə çökür. Həll — çağırmazdan əvvəl həmişə mounted yoxlayın.

İkinci səhv — build daxilində setState çağırmaq. Bu, sonsuz dövrəyə gətirib çıxarır: build → setState → dirty → build → setState → ... Flutter belə çağırışı bloklamır (StackOverflowError alacaqsınız). setState yalnız hadisəyə cavab olaraq çağırıla bilər (düyməyə basma, Future-in tamamlanması, axından məlumat alma).

Üçüncü səhv — setState çağırmadan State sahələrini dəyişdirmək. Tərtibatçı _count++ yazır və UI-nin yenilənəcəyini gözləyir. Flutter sahə dəyişikliklərini avtomatik izləyə bilmir — ona setState vasitəsilə açıq siqnal lazımdır. Bu, Vue.js kimi reaktiv framework-lərdən fundamental fərqdir, burada məlumat dəyişikliyi avtomatik yeniləməni tetikleyir.

Dördüncü səhv — asinxron callback (async-lambda) ilə setState çağırmaq. Asinxronluq bölməsində təsvir edildiyi kimi, await-dən sonrakı dəyişikliklər ələ keçirilməyəcək, bu da çətin təkrarlanan xətalara səbəb olur. Sinxron callback istifadə edin və setState-i await-dən sonra çağırın.

Təhlükəsiz setState üçün qeydlər

• Asinxron callback-lərdə həmişə mounted yoxlayın
• build daxilində setState çağırmayın
• setState-ə async-lambda ötürməyin
• State sahələrini setState xaricində dəyişdirməyin
• Bir neçə sahə dəyişirsinizsə — bunu bir setState-də edin