@State e @Binding a confronto

Sia @State sia @Binding gestiscono dati modificabili, ma svolgono ruoli diversi. Scegliere quello giusto mantiene chiara la proprietà. 🎯

Usi @State quando questa view è la fonte di verità. Crea e memorizza il valore per conto proprio.

Usi @Binding quando il valore si trova altrove e questa view deve solo leggerlo e scriverlo.

@State inizializza un valore. @Binding non lo fa mai: lo riceve sempre da un parent che lo possiede.

@State è locale alla view, quindi lo contrassegni come private. Nessun elemento esterno dovrebbe accedervi e impostarlo direttamente.

Un @Binding non è private; il parent deve poter passare un valore quando crea il child.

Lo @State del proprietario diventa un @Binding del child tramite il simbolo del dollaro. Questo è il ponte tra i due.

La view più in alto che possiede realmente i dati usa @State. Tutto ciò che si trova sotto lo prende in prestito con @Binding.

Si chieda: creo io questo valore? Se sì, @State. Se me lo passa un parent, @Binding. Questa scelta raramente la tradirà.

Se usa @State quando intendeva @Binding, il child modifica una copia. Il parent non vede mai la modifica e l'interfaccia si desincronizza silenziosamente.

Un dato è @State nel suo proprietario e @Binding in ogni view che lo prende in prestito. Stesso valore, responsabilità diverse. 🔄

Usi @State per possedere un valore e @Binding per prenderne uno in prestito. Abbini il wrapper a chi crea i dati e le view resteranno sincronizzate. 🧠