Siklus Hidup Widget dan State

Kenapa lifecycle penting?

Widget tidak hidup selamanya. Ia dibuat, ditampilkan, diperbarui, lalu dihancurkan saat user pindah halaman. Class State punya beberapa method lifecycle yang dipanggil Flutter di tiap fase. Memahaminya mencegah bug klasik seperti memory leak atau error karena memanggil setState pada widget yang sudah mati.

initState: persiapan sekali di awal

initState dipanggil tepat sekali saat State dibuat, sebelum build pertama. Tempat yang tepat untuk inisialisasi controller, memulai timer, atau memanggil API pertama kali.

class _JamDigitalState extends State<JamDigital> {
  late Timer _timer;
  DateTime _sekarang = DateTime.now();

  @override
  void initState() {
    super.initState();
    _timer = Timer.periodic(const Duration(seconds: 1), (_) {
      setState(() {
        _sekarang = DateTime.now();
      });
    });
  }

  @override
  void dispose() {
    _timer.cancel();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    final jam = _sekarang.hour.toString().padLeft(2, '0');
    final menit = _sekarang.minute.toString().padLeft(2, '0');
    final detik = _sekarang.second.toString().padLeft(2, '0');
    return Text('Sekarang: $jam:$menit:$detik');
  }
}

dispose: bersih-bersih sebelum mati

dispose dipanggil saat State dihancurkan permanen, misalnya user menutup halaman. Semua resource seperti Timer, TextEditingController, AnimationController, atau subscription stream wajib dibersihkan di sini. Lupa dispose controller adalah penyebab memory leak paling umum di Flutter.

didUpdateWidget dan didChangeDependencies

didUpdateWidget dipanggil saat parent rebuild dan memberi konfigurasi widget baru ke State yang sama. Berguna kalau State perlu bereaksi terhadap perubahan properti dari parent. Sedangkan didChangeDependencies dipanggil saat dependensi seperti InheritedWidget (misalnya Theme atau MediaQuery) berubah.

Urutan pemanggilan

Urutan normalnya: constructor, initState, didChangeDependencies, build. Saat parent memberi data baru: didUpdateWidget lalu build. Saat widget dibuang: deactivate lalu dispose. Hafalkan urutan ini, karena banyak bug misterius terjawab hanya dengan tahu method mana yang jalan duluan.

Catatan teknis: Jebakan paling terkenal adalah memanggil setState setelah dispose, biasanya dari callback async yang selesai setelah user pindah halaman. Hasilnya error merah "setState() called after dispose()". Solusinya: cek if (!mounted) return; sebelum setState di dalam callback async, atau batalkan operasi async di dispose.