Pomijanie, @Stable i @Immutable

Czasami typ jest rzeczywiście bezpieczny, ale Compose nie potrafi tego udowodnić. Adnotacje pozwalają obiecać stabilność, dzięki czemu pomijanie znów zaczyna działać.

@Immutable informuje Compose, że po utworzeniu instancji żadna z jej właściwości nigdy się nie zmieni. To najsilniejsza gwarancja stabilności.

Warto używać @Immutable dla danych przypominających konfigurację: motywów, stylów i obiektów wartości, które tworzy się raz i nigdy nie modyfikuje po utworzeniu.

@Stable jest łagodniejsza: właściwości mogą się zmieniać, ale gdy to nastąpi, Compose zostanie powiadomiony za pośrednictwem stanu Compose. equals() musi pozostać spójne.

Należy używać @Stable dla klas, których modyfikowalne pola są oparte na mutableStateOf, aby Compose nadal poprawnie śledził każdą zmianę.

Te adnotacje są kontraktem. Jeśli oznaczy się typ jako stabilny, a następnie będzie go po cichu modyfikować, interfejs użytkownika pokaże nieaktualne dane i pojawią się błędy.

Zamiast List należy przekazywać ImmutableList z kotlinx.collections.immutable. Compose traktuje go jako stabilny, więc funkcje Composable wyświetlające listy mogą być pomijane.

Parametry-lambdy są już stabilne, ale należy pamiętać, że lambda przechwytująca zmieniające się wartości jest nową instancją przy każdej rekompozycji.

Jedna adnotacja na poziomie class obejmuje każde użycie tego typu jako parametru. Nie trzeba dodawać adnotacji w każdym miejscu wywołania.

Najpierw należy preferować rzeczywistą niezmienność za pomocą val. Adnotacji należy używać tylko wtedy, gdy kompilator rzeczywiście nie potrafi samodzielnie wywnioskować stabilności.

Po dodaniu adnotacji należy sprawdzić, czy funkcja Composable rzeczywiście jest pomijana. Błędna obietnica jest gorsza niż jej brak.

Używaj @Immutable dla danych, które nigdy się nie zmieniają, a @Stable dla modyfikowalnych danych opartych na stanie. Należy dotrzymywać kontraktu, bo w przeciwnym razie interfejs użytkownika będzie pokazywał nieprawdę. ✅