InheritedWidget — co to jest, przekazywanie danych w drzewie i jak działa

Czym jest InheritedWidget we Flutterze?

InheritedWidget — to widget, który udostępnia swoje dane wszystkim potomkom w Widget Tree. W przeciwieństwie do zwykłego widgetu, który przekazuje dane tylko przez konstruktor do elementów potomnych, InheritedWidget pozwala dowolnemu widgetowi w poddrzewie uzyskać dostęp do danych bez łańcucha parametrów. Rozwiązuje to problem "prop drilling" — przekazywania danych przez wiele pośrednich widgetów, które same nie korzystają z tych danych.

Wbudowane InheritedWidget

Flutter zawiera kilka wbudowanych InheritedWidget: Theme (schemat kolorów i style), MediaQuery (rozmiar ekranu, orientacja, gęstość pikseli), Localizations (zlokalizowane ciągi znaków), Directionality (kierunek tekstu), DefaultTextStyle (domyślny styl tekstu). Te widgety są ustawiane przez widgety główne takie jak MaterialApp i są dostępne w całej aplikacji.

Cykl życia InheritedWidget

InheritedWidget nie ma własnego stanu — przechowuje dane przekazane przez konstruktor. Gdy rodzic InheritedWidget przebudowuje się z nowymi danymi, wywoływana jest metoda updateShouldNotify w celu porównania starych i nowych danych. Jeśli metoda zwraca true, wszystkie zależne widgety są oznaczane do przebudowy. To prosty, ale skuteczny mechanizm reaktywnej aktualizacji.

Jak działa przekazywanie danych przez InheritedWidget

Mechanizm przekazywania danych przez InheritedWidget opiera się na Element Tree. Gdy widget wywołuje dependOnInheritedWidgetOfExactType, odpowiedni element rejestruje zależność od InheritedElement. Przy zmianie InheritedWidget, InheritedElement powiadamia wszystkie zależne elementy, które przebudowują się w następnej klatce.

Rejestracja zależności

Metoda dependOnInheritedWidgetOfExactType nie tylko znajduje InheritedWidget w drzewie — subskrybuje bieżący element na powiadomienia. Gdybyś użył findAncestorWidgetOfExactType zamiast dependOn, widget otrzymałby dane, ale nie przebudowywałby się przy ich zmianie. To ważna różnica: dependOn — to subskrypcja, a findAncestor — jednorazowe wyszukiwanie.

Przechodzenie drzewa InheritedWidget

Gdy widget żąda InheritedWidget, Flutter wznosi się po Element Tree od bieżącego elementu do korzenia, sprawdzając każdy InheritedElement pod kątem zgodności typu. Pierwszy znaleziony InheritedElement jest zwracany. Oznacza to, że najbliższy InheritedWidget w drzewie ma priorytet — możesz nadpisać dane na określonym poziomie, umieszczając InheritedWidget bliżej potomków.

class ThemeData {
  final Color primaryColor;
  final TextTheme textTheme;

  const ThemeData({required this.primaryColor, required this.textTheme});
}

class MyTheme extends InheritedWidget {
  final ThemeData data;

  const MyTheme({required this.data, required Widget child}) : super(child: child);

  static MyTheme of(BuildContext context) {
    final widget = context.dependOnInheritedWidgetOfExactType<MyTheme>();
    assert(widget != null, "MyTheme not found in tree");
    return widget!;
  }

  @override
  bool updateShouldNotify(MyTheme oldWidget) => oldWidget.data != data;
}

W tym przykładzie MyTheme używa statycznej metody of do udostępniania danych potomkom. Metoda dependOnInheritedWidgetOfExactType rejestruje zależność, a updateShouldNotify porównuje stare i nowe dane w celu określenia konieczności przebudowy zależnych widgetów.

Tworzenie własnego InheritedWidget

Tworzenie własnego InheritedWidget składa się z dwóch kroków: zdefiniowanie klasy dziedziczącej po InheritedWidget i implementacja statycznej metody of do dostępu z potomków. Dane są przekazywane przez konstruktor, a metoda updateShouldNotify określa, kiedy zależne widgety powinny się przebudowywać.

Krok 1: Definicja klasy InheritedWidget

Klasa musi dziedziczyć po InheritedWidget i przyjmować dane przez konstruktor z obowiązkowym parametrem child. Dane mogą być dowolnego typu: prymitywy, obiekty, funkcje. Główna zasada — dane muszą być niezmienne (immutable), aby można było niezawodnie porównywać stare i nowe wartości.

Krok 2: Statyczna metoda of

Statyczna metoda of przyjmuje BuildContext i zwraca dane InheritedWidget. Wewnątrz wywoływana jest dependOnInheritedWidgetOfExactType, która szuka najbliższego InheritedWidget określonego typu w drzewie. Jeśli InheritedWidget nie zostanie znaleziony, metoda rzuca wyjątek lub zwraca wartość domyślną w zależności od implementacji.

Krok 3: Użycie w widgetach

Aby uzyskać dostęp do danych, widget wywołuje MyWidget.of(context) wewnątrz metody build. Flutter automatycznie subskrybuje widget na aktualizacje. Jeśli dane się zmienią, widget przebuduje się w następnej klatce. Pozwala to tworzyć czysty i deklaratywny kod bez zbędnych parametrów.

class UserPreferences extends InheritedWidget {
  final String languageCode;
  final bool darkMode;

  const UserPreferences({
    required this.languageCode,
    required this.darkMode,
    required Widget child,
  }) : super(child: child);

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

  @override
  bool updateShouldNotify(UserPreferences oldWidget) =>
    oldWidget.languageCode != languageCode || oldWidget.darkMode != darkMode;
}

W tym przykładzie UserPreferences przechowuje ustawienia użytkownika. Metoda updateShouldNotify porównuje każde pole osobno, co zapobiega niepotrzebnym przebudowom przy zmianie tylko jednego parametru. Zastosuj podobne podejście dla własnych InheritedWidget z wieloma polami.

Metoda updateShouldNotify i zapobieganie niepotrzebnym przebudowom

updateShouldNotify — to kluczowa metoda InheritedWidget, która określa, czy należy powiadomić zależne widgety o zmianie danych. Jeśli metoda zwraca false, zależne widgety nie przebudowują się, nawet jeśli sam InheritedWidget otrzymał nową instancję z tymi samymi danymi. Jest to krytyczne dla wydajności.

Poprawna implementacja updateShouldNotify

Porównuj tylko te pola, które rzeczywiście się zmieniły i wpływają na wyświetlanie. Jeśli InheritedWidget zawiera 10 pól, ale tylko jedno z nich wpływa na UI, sprawdzaj tylko to pole. Dla kolekcji używaj głębokiego porównania lub niezmiennych struktur danych. Nie używaj == dla List lub Map, ponieważ są porównywane przez referencję.

• Prymitywy — używaj bezpośrednich porównań: oldWidget.value != value.
• Niezmienne obiekty — używaj nadpisanego ==: oldWidget.data != data (jeśli data nadpisuje ==).
• Kolekcje — używaj listEquals, mapEquals z package:flutter/foundation.dart.

Błędy przy implementacji updateShouldNotify

Najczęstszy błąd — zwracanie true bez porównania. Prowadzi to do przebudowy wszystkich zależnych widgetów przy każdej aktualizacji rodzica, nawet jeśli dane się nie zmieniły. Drugi błąd — zwracanie false, gdy dane się zmieniły, co prowadzi do nieaktualnego UI. Trzeci — złożone porównanie, które wykonuje się każdej klatki i spowalnia działanie.

InheritedWidget vs callbacki: co wybrać?

InheritedWidget i callbacki (przekazywanie funkcji przez konstruktor) rozwiązują różne zadania. InheritedWidget nadaje się do danych, które są potrzebne wielu widgetom na różnych poziomach drzewa. Callbacki są wygodne do jednokierunkowego przekazywania zdarzeń od rodzica do konkretnego potomka lub odwrotnie. Wybór zależy od architektury aplikacji i częstotliwości zmian.

Kiedy używać InheritedWidget

Używaj InheritedWidget, gdy dane są potrzebne wielu widgetom na różnych poziomach zagnieżdżenia: motyw aplikacji, ustawienia użytkownika, informacje o urządzeniu, dane bieżącej sesji. InheritedWidget jest szczególnie efektywny dla danych "globalnych", które zmieniają się rzadko, ale są potrzebne w różnych częściach UI.

Kiedy używać callbacków

Callbacki (funkcje zwrotne) nadają się do przekazywania zdarzeń od widgetu potomnego do rodzicielskiego: naciśnięcie przycisku, wybór elementu listy, wysłanie formularza. Callbacki jawnie wskazują, jakie działania może wykonać potomek, i nie tworzą ukrytych zależności. Do przekazywania danych w dół drzewa na niewielką liczbę poziomów również prościej użyć parametrów konstruktora.

InheritedWidget a biblioteki zarządzania stanem

Provider i Riverpod — popularne biblioteki zarządzania stanem we Flutterze, zbudowane na InheritedWidget. Rozszerzają one jego możliwości: dodają obsługę ChangeNotifier, automatyczne usuwanie przy demontażu, leniwą inicjalizację i uproszczoną składnię przez generyki.

Provider na bazie InheritedWidget

Provider używa InheritedWidget do przekazywania obiektu dowolnego typu w dół drzewa. ChangeNotifierProvider śledzi zmiany przez ChangeNotifier i wywołuje updateShouldNotify przy wywołaniu notifyListeners. To zwalnia programistę z ręcznego tworzenia InheritedWidget i implementacji updateShouldNotify.

Porównanie z bezpośrednim InheritedWidget

Bezpośredni InheritedWidget daje więcej kontroli i nie wymaga zewnętrznych zależności. Provider dostarcza gotową infrastrukturę: Consumer, Selector, MultiProvider, ProxyProvider. Wybór zależy od złożoności aplikacji. Dla prostych projektów bezpośredni InheritedWidget jest wystarczający, dla dużych — Provider lub Riverpod zmniejszają kod szablonowy.

// Bezpośredni InheritedWidget
class UserProvider extends InheritedWidget {
  final UserData userData;
  const UserProvider({required this.userData, required Widget child}) : super(child: child);
  static UserData of(BuildContext context) => context.dependOnInheritedWidgetOfExactType<UserProvider>()!.userData;
  @override
  bool updateShouldNotify(UserProvider old) => old.userData != userData;
}

// Odpowiednik Providera
return ChangeNotifierProvider<UserData>(
  create: (_) => UserData(),
  child: MyApp(),
);

Oba podejścia w przykładzie rozwiązują to samo zadanie — przekazanie UserData w dół drzewa. Provider skraca ilość kodu, ale ukrywa mechanikę InheritedWidget. Bezpośredni InheritedWidget daje pełną kontrolę i zrozumienie procesu, co jest szczególnie ważne przy nauce Fluttera i debugowaniu złożonych problemów z przebudową.