Skipping, @Stable e @Immutable

A volte un tipo è realmente sicuro, ma Compose non può dimostrarlo. Le annotazioni consentono di promettere la stabilità, così lo skip torna a funzionare.

@Immutable comunica a Compose che, una volta costruita un'istanza, nessuna delle sue proprietà cambierà mai. È la garanzia di stabilità più forte.

Scelga @Immutable per dati simili a configurazioni: temi, stili e oggetti valore creati una volta e mai modificati dopo la costruzione.

@Stable è meno restrittiva: le proprietà possono cambiare, ma quando succede Compose riceverà una notifica tramite lo stato Compose. equals() deve rimanere coerente.

Usi @Stable sulle classi i cui campi mutabili sono supportati da mutableStateOf, così Compose continua a monitorare correttamente ogni cambiamento.

Queste annotazioni sono un contratto. Se contrassegna un tipo come stabile ma lo modifica senza notificarlo, l'interfaccia mostra dati obsoleti e iniziano a comparire bug.

Invece di List, passi ImmutableList da kotlinx.collections.immutable. Compose la considera stabile, quindi i Composable che visualizzano la lista possono essere saltati.

I parametri lambda sono già stable, ma ricordi che una lambda che cattura valori soggetti a cambiamento è una nuova istanza a ogni ricomposizione.

Una sola annotazione sulla class copre ogni utilizzo di quel tipo come parametro. Non deve annotare ogni punto in cui viene effettuata una chiamata.

Preferisca innanzitutto la reale immutability con val. Annoti un tipo solo quando il compilatore non riesce davvero a dedurne autonomamente la stabilità.

Dopo aver aggiunto l'annotazione, controlli che il Composable venga effettivamente saltato. Una promessa errata è peggiore dell'assenza di promesse.

Usi @Immutable per dati che non cambiano mai e @Stable per dati mutabili supportati dallo stato. Rispetti il contratto, altrimenti l'interfaccia mente. ✅