BuildContext — apa itu, konsep kunci dan prinsip kerja

Apa itu BuildContext?

BuildContext — adalah antarmuka yang diimplementasikan oleh kelas Element, yang memberikan informasi kepada widget tentang lokasinya di hierarki UI. Setiap instance BuildContext unik untuk posisi tertentu di pohon dan tidak dapat dipindahkan ke tempat lain. Jika widget mengubah induknya (misalnya, dipindahkan ke wadah lain), ia menerima BuildContext baru.

Tujuan utama BuildContext adalah akses ke InheritedWidget. Melalui konteks, widget menemukan instance Theme, MediaQuery, Navigator atau Directionality terdekat dengan naik ke atas pohon. Mekanisme ini mendasari seluruh sistem tema, navigasi, dan tata letak adaptif di Flutter. Tanpa BuildContext, tidak ada widget yang dapat memperoleh data ini.

Menurut dokumen arsitektur Flutter (Google, 2026), BuildContext juga digunakan untuk menemukan objek RenderObject yang terkait dengan widget, untuk mengukur dimensi dan memposisikan. Metode seperti findRenderObject() dan size tersedia tepat melalui konteks. Konteks juga menyediakan akses ke lokalisasi melalui Localizations.of(context).

BuildContext adalah elemen, bukan widget

Pemahaman arsitektur yang penting: BuildContext adalah antarmuka yang diimplementasikan oleh Element, bukan Widget. Element adalah “lem” antara Widget (konfigurasi) dan RenderObject (tampilan sebenarnya). Ketika dalam dokumentasi disebut “konteks widget” — yang dimaksud adalah elemen yang mengelola widget tersebut. Metode build menerima konteks seperti itu — konteks widget yang dibuat, bukan widget anak yang dikembalikan.

Bagaimana BuildContext bekerja?

Mekanisme kerja BuildContext didasarkan pada penelusuran pohon elemen dari bawah ke atas. Ketika widget memanggil Theme.of(context), konteks memulai pencarian dari elemen saat ini dan bergerak ke atas menuju akar, memeriksa setiap elemen untuk keberadaan InheritedWidget dengan tipe Theme. InheritedWidget pertama yang ditemukan dikembalikan — ini menjamin bahwa widget menerima tema dari definisi terdekat.

Setiap BuildContext menyimpan referensi ke konteks induk (parent) dan ke konteks anak. Ini adalah koneksi dua arah yang memungkinkan pergerakan di pohon baik ke atas (ke induk) maupun ke bawah (ke keturunan). Di Flutter, untuk mencari InheritedWidget hanya digunakan pergerakan ke atas — widget hanya dapat memperoleh data dari leluhur, bukan dari keturunan. Ini adalah batasan arsitektur fundamental.

Menurut kode sumber Flutter (Flutter SDK, 2026), BuildContext berisi metode: visitAncestorElements, visitChildElements, findAncestorWidgetOfExactType, dependOnInheritedWidgetOfExactType dan getRenderObject. Dua yang terakhir adalah yang paling sering digunakan: dependOnInheritedWidgetOfExactType tidak hanya menemukan InheritedWidget, tetapi juga berlangganan perubahannya (widget akan dibangun ulang ketika InheritedWidget berubah).

Berlangganan melalui konteks

dependOnInheritedWidgetOfExactType — metode kunci BuildContext yang memastikan reaktivitas. Ketika widget memanggil Theme.of(context), ia tidak hanya menerima tema — ia berlangganan perubahannya. Jika Theme berubah (misalnya, saat beralih tema gelap/terang), semua widget yang berlangganan secara otomatis dibangun ulang. Ini adalah mekanisme reaktivitas di Flutter.

BuildContext vs Element

BuildContext adalah antarmuka, dan Element — implementasinya. Dalam kode Flutter Anda selalu bekerja melalui antarmuka BuildContext, tanpa mengetahui tipe elemen spesifik (StatelessElement, StatefulElement, ProxyElement, dll.). Ini sengaja dilakukan: pengembang tidak perlu mengetahui detail implementasi elemen — antarmuka cukup untuk akses ke lingkungan.

Tipe elemen yang berbeda mengimplementasikan BuildContext secara berbeda: StatelessElement hanya meneruskan panggilan build, StatefulElement mengelola State, dan InheritedElement melacak langganan melalui dependOnInheritedWidgetOfExactType. Namun dari sudut pandang pengembang, semuanya adalah BuildContext dengan API yang seragam.

Contoh kode di Dart

Penggunaan dasar BuildContext untuk akses ke tema dan kueri media:

class ThemedText extends StatelessWidget {
  const ThemedText({super.key});

  @override
  Widget build(BuildContext context) {
    final theme = Theme.of(context);
    final media = MediaQuery.of(context);

    return Container(
      padding: EdgeInsets.all(media.size.width * 0.02),
      child: Text(
        'Styled Text',
        style: theme.textTheme.headlineMedium,
      ),
    );
  }
}

Contoh dengan navigasi melalui BuildContext. Navigator.of(context) menggunakan konteks untuk mencari Navigator terdekat ke atas pohon:

class _NavigateButtonState extends State<NavigateButton> {
  void _navigate() {
    Navigator.of(context).push(
      MaterialPageRoute(
        builder: (_) => const DetailsScreen(),
      ),
    );
  }

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: _navigate,
      child: const Text('Go to Details'),
    );
  }
}

Contoh menemukan ukuran widget melalui BuildContext. Metode findRenderObject() mengembalikan RenderObject dari mana ukuran dapat diperoleh:

void _printSize(BuildContext context) {
  final renderBox = context.findRenderObject() as RenderBox?;
  if (renderBox != null) {
    print('Widget size: ${renderBox.size}');
  }
}

Penting: findRenderObject() mengembalikan null jika widget belum dipasang atau sudah dilepas. Selalu periksa hasilnya untuk null sebelum digunakan. Memanggil metode ini di dalam build sebelum konstruksi selesai juga dapat mengembalikan null.

InheritedWidget dan BuildContext

InheritedWidget — widget khusus yang secara efisien menyebarkan data ke bawah pohon melalui BuildContext. Ketika widget anak memanggil MyInheritedWidget.of(context), BuildContext naik ke pohon, menemukan InheritedWidget terdekat dari tipe yang sesuai dan mengembalikan datanya. Dalam proses ini, konteks berlangganan perubahan: jika InheritedWidget berubah, semua widget yang berlangganan secara otomatis dibangun ulang.

Kombinasi BuildContext + InheritedWidget menggantikan variabel global dan prop-drilling (meneruskan data melalui rantai konstruktor). Alih-alih meneruskan tema melalui 10 tingkat widget, setiap widget dapat memperolehnya langsung melalui Theme.of(context). Ini membuat kode lebih bersih dan mengurangi jumlah parameter yang diteruskan.

Menurut Flutter Team (Google, April 2026), InheritedWidget adalah mekanisme yang sangat efisien sehingga semua solusi resmi untuk manajemen status dibangun di atasnya: Provider membungkus InheritedWidget, Riverpod menggunakannya sebagai salah satu lapisan, dan Flutter SDK sendiri (Theme, MediaQuery, Navigator, Localizations) sepenuhnya didasarkan pada arsitektur ini.

Membuat InheritedWidget sendiri

Membuat InheritedWidget sendiri memungkinkan penyebaran data tanpa ketergantungan eksternal. Kelas memperluas InheritedWidget dan menyediakan metode statis of(BuildContext context). Ini adalah alternatif minimalis untuk Provider dalam skenario sederhana:

class AppConfig extends InheritedWidget {
  final String apiUrl;
  final bool useDarkMode;

  const AppConfig({
    super.key,
    required this.apiUrl,
    required this.useDarkMode,
    required super.child,
  });

  static AppConfig of(BuildContext context) {
    return context.dependOnInheritedWidgetOfExactType<AppConfig>()!;
  }

  @override
  bool updateShouldNotify(AppConfig oldWidget) {
    return apiUrl != oldWidget.apiUrl || useDarkMode != oldWidget.useDarkMode;
  }
}

Sekarang widget apa pun yang lebih rendah di pohon dapat mengakses konfigurasi: final config = AppConfig.of(context);. Jika konfigurasi berubah, semua widget yang berlangganan akan secara otomatis dibangun ulang.

Kesalahan umum

Kesalahan umum pertama — menyimpan BuildContext setelah dispose atau menggunakannya dalam callback asinkron tanpa memeriksa mounted. BuildContext terikat pada elemen, dan elemen dapat dimusnahkan (saat widget dihapus dari pohon). Penggunaan konteks setelah penghancuran elemen menyebabkan pengecualian. Solusi — gunakan context.mounted (tersedia di versi Flutter yang lebih baru) atau periksa mounted di State.

Kesalahan kedua — memanggil Theme.of(context) di initState. Pada tahap initState, konteks belum sepenuhnya dipasang di pohon. Pencarian InheritedWidget di initState dapat mengembalikan null atau melempar pengecualian. Semua panggilan of(context) harus dilakukan di build atau didChangeDependencies, di mana konteks dijamin berada di pohon.

Kesalahan ketiga — menggunakan BuildContext dari satu widget untuk memanipulasi widget lain. BuildContext tidak dirancang untuk interaksi antar widget di luar hierarki “orangtua-anak”. Jika perlu mengelola status widget lain — gunakan callback, controller, atau alat manajemen status.

Kesalahan keempat — meneruskan BuildContext ke fungsi asinkron yang bertahan lebih lama dari dispose widget. Skenario tipikal: Navigator.of(context) disimpan dalam variabel dan digunakan setelah pengguna meninggalkan layar. Solusi — jangan simpan konteks dalam objek statis atau berumur panjang.

Konteks dalam operasi asinkron

Pola keamanan untuk bekerja dengan BuildContext dalam operasi asinkron: selalu periksa mounted sebelum menggunakan konteks dan jangan simpan konteks dalam closure yang mungkin bertahan lebih lama dari widget:

Future<void> _safeNavigation(BuildContext context) async {
  await Future.delayed(const Duration(seconds: 2));
  if (!context.mounted) return;
  Navigator.of(context).push(MaterialPageRoute(...));
}

Praktik terbaik

Bekerja dengan BuildContext memerlukan pemahaman tentang siklus hidup dan batasannya. Aturan pertama: gunakan konteks hanya di dalam metode yang menerimanya sebagai parameter (build, didChangeDependencies). Jangan simpan konteks di bidang kelas atau variabel statis — ini hampir selalu menyebabkan bug.

Aturan kedua: untuk akses ke data dari InheritedWidget, lebih suka didChangeDependencies daripada build. Jika data hanya diperlukan untuk inisialisasi, bukan untuk rendering, didChangeDependencies adalah tempat yang tepat. Ini memungkinkan pemisahan logika inisialisasi dari pembangunan UI dan menghindari panggilan berulang pada setiap pembaruan.

Aturan ketiga: saat bekerja dengan operasi asinkron, gunakan callback yang tidak bergantung pada konteks atau periksa mounted. Jika operasi asinkron memerlukan navigasi atau akses ke tema, dapatkan data ini sebelumnya (dalam konteks sinkron build atau initState) dan simpan dalam variabel lokal, bukan di konteks.

Kapan konteks diperlukan dan kapan tidak

• Diperlukan: akses ke Theme, MediaQuery, Navigator, Localizations, ScaffoldMessenger
• Diperlukan: pencarian RenderObject untuk mengukur dimensi
• Diperlukan: pembuatan SnackBar, BottomSheet, Dialog
• Tidak diperlukan: pemanggilan metode logika bisnis, permintaan HTTP, bekerja dengan database
• Tidak diperlukan: konstruksi widget di luar build (di pabrik, konstruktor)