State Hoisting: άνωση κατάστασης και μονόδρομη ροή δεδομένων στο Compose

Τι είναι το State Hoisting στο Jetpack Compose

State Hoisting (άνωση κατάστασης) — είναι ένα μοτίβο όπου η συνάρτηση Composable δεν κατέχει την κατάσταση, αλλά τη λαμβάνει από έξω. Αντί για var μέσα στη συνάρτηση, χρησιμοποιούνται δύο παράμετροι: η τιμή για εμφάνιση και ένα lambda-callback για το χειρισμό των αλλαγών. Τεχνικά, αυτό σημαίνει ότι το θυγατρικό στοιχείο γίνεται stateless (δεν έχει δική του κατάσταση) και το γονικό stateful (κατέχει την κατάσταση).

Παράδειγμα: το στοιχείο TextField από το Material3 δεν αποθηκεύει το κείμενο που εισάγεται μέσα του. Δέχεται value: String και onValueChange: (String) -> Unit. Ο γονέας που καλεί το TextField δηλώνει var value by remember { mutableStateOf("") } και μεταβιβάζει τιμή και onValueChange. Αυτό είναι κλασικό State Hoisting: TextField — απλό στοιχείο (απλώς εμφανίζει και αναφέρει την εισαγωγή), ο γονέας — έξυπνος (κατέχει την κατάσταση).

Stateless vs Stateful: Ένα Stateless στοιχείο δοκιμάζεται ευκολότερα — δεν εξαρτάται από εσωτερική κατάσταση, η συμπεριφορά του καθορίζεται πλήρως από τις εισαγόμενες παραμέτρους. Ένα Stateful στοιχείο είναι βολικό για γρήγορη δημιουργία πρωτοτύπων, αλλά δυσκολότερα επαναχρησιμοποιείται — είναι στενά δεμένο σε μία πηγή δεδομένων. Το State Hoisting δίνει τη δυνατότητα επιλογής: κάθε στοιχείο μπορεί να γίνει stateless με μετακίνηση της κατάστασης προς τα πάνω.

Μονόδρομη ροή δεδομένων (UDF) και State Hoisting

UDF (Unidirectional Data Flow) — είναι μια αρχιτεκτονική αρχή όπου τα δεδομένα κινούνται σε μία κατεύθυνση: από την πηγή αλήθειας (ViewModel ή γονικό Composable) προς το UI, και τα συμβάντα στην αντίθετη κατεύθυνση. Το State Hoisting είναι η υλοποίηση του UDF σε επίπεδο μεμονωμένων στοιχείων. Αντί κάθε στοιχείο να αποφασίζει από μόνο του πότε και πώς να αλλάξει την κατάστασή του, ενημερώνει τον γονέα για το συμβάν, και ο γονέας αποφασίζει πώς να αλλάξει την κατάσταση.

Πλεονεκτήματα UDF: προβλεψιμότητα — η κατάσταση αλλάζει μόνο σε ένα σημείο, εξαλείφοντας τις race conditions; ιχνηλασιμότητα — από την στοίβα κλήσεων μπορεί να ανασυντεθεί η αλυσίδα αλλαγών; δοκιμή — η stateful λογική μπορεί να εξαχθεί σε ξεχωριστή κλάση και να δοκιμαστεί χωρίς UI. Σε μεγάλα έργα, το UDF σε συνδυασμό με το State Hoisting είναι το de facto πρότυπο.

Μοναδική πηγή αλήθειας (Single Source of Truth) — μία ακόμη αρχή που συνοδεύει το UDF. Κάθε τμήμα κατάστασης έχει ακριβώς μία πηγή. Αν δύο στοιχεία χρησιμοποιούν την ίδια κατάσταση, η πηγή πρέπει να είναι κοινή (σε επίπεδο ViewModel ή κοινού γονέα). Το State Hoisting εγγυάται ότι η πηγή βρίσκεται ψηλότερα στην ιεραρχία και δεν συμβαίνει αντιγραφή κατάστασης.

Κανόνες State Hoisting: πότε και πώς να ανυψώσουμε την κατάσταση

Βασικός κανόνας: η κατάσταση πρέπει να ανυψωθεί στο μικρότερο δυνατό επίπεδο που είναι αρκετό για όλα τα στοιχεία που τη χρειάζονται. Αν η κατάσταση χρησιμοποιείται μόνο μέσα σε ένα στοιχείο — αφήστε την τοπική. Αν δύο γειτονικά στοιχεία χρειάζονται την ίδια κατάσταση — ανυψώστε την στον κοινό γονέα. Αν η κατάσταση χρειάζεται σε όλη την οθόνη — ανυψώστε την στο ViewModel.

Κανόνας ελάχιστης άνωσης αποτρέπει την περιττή πολυπλοκότητα. Δεν έχει νόημα να ανυψώσετε την κατάσταση ενός πεδίου κειμένου στο ViewModel αν χρησιμοποιείται μόνο μέσα σε μία οθόνη και δεν αποθηκεύεται κατά την αναδημιουργία της Activity. Χρησιμοποιήστε rememberSaveable σε επίπεδο γονέα οθόνης, όχι ViewModel, για κατάσταση UI που πρέπει να επιβιώσει σε περιστροφή οθόνης αλλά δεν χρειάζεται από την επιχειρηματική λογική.

Πότε να ανυψώσετε στο ViewModel: αν η κατάσταση πρέπει να διατηρηθεί κατά την αναδημιουργία της Activity, αν χρειάζεται από πολλές οθόνες, αν η αλλαγή κατάστασης πυροδοτεί επιχειρηματική λογική (αιτήσεις δικτύου, βάση δεδομένων). Το State Hoisting σε επίπεδο ViewModel είναι ένα τυπικό μοτίβο στην αρχιτεκτονική MVVM, όπου το επίπεδο UI είναι stateless και το ViewModel stateful.

    // ❌ Κακό: το στοιχείο κατέχει δική του κατάσταση
@Composable
fun BadTextField(label: String) {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it }, label = { Text(label) })
}

    // ✅ Καλό: State Hoisting — κατάσταση στον γονέα
@Composable
fun GoodTextField(value: String, onValueChange: (String) -> Unit, label: String) {
    TextField(value = value, onValueChange = onValueChange, label = { Text(label) })
}

    // Χρήση: ο γονέας κατέχει την κατάσταση
@Composable
fun Form() {
    var name by rememberSaveable { mutableStateOf("") }
    GoodTextField(value = name, onValueChange = { name = it }, label = "Name")
}

Παραδείγματα State Hoisting σε πραγματικά στοιχεία

Εξετάστε την οθόνη σύνδεσης που έχει δύο πεδία (email, κωδικός πρόσβασης) και ένα κουμπί. Και τα τρία στοιχεία λαμβάνουν κατάσταση μέσω State Hoisting: το email και ο κωδικός πρόσβασης διαχειρίζονται από τον γονέα, το κουμπί λαμβάνει την κατάσταση enabled ως τιμή.

    // State Hoisting σε επίπεδο οθόνης
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        // Πεδίο Email — State Hoisting μέσω lambda
        EmailField(
            email = uiState.email,
            onEmailChange = { viewModel.onEmailChanged(it) }
        )

        // Πεδίο κωδικού πρόσβασης — παρόμοια
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // Κουμπί — λαμβάνει μόνο enabled (read-only)
        LoginButton(enabled = uiState.isFormValid, onClick = viewModel::login)
    }
}

// Stateless στοιχείο: λαμβάνει email + callback
@Composable
fun EmailField(email: String, onEmailChange: (String) -> Unit) {
    OutlinedTextField(
        value = email,
        onValueChange = onEmailChange,
        label = { Text("Email") },
        singleLine = true
    )
}

// Stateless στοιχείο κουμπιού
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("Σύνδεση")
    }
}

EmailField και PasswordField — πλήρως stateless. Μπορούν να επαναχρησιμοποιηθούν σε οποιαδήποτε οθόνη, συνδεδεμένα σε οποιαδήποτε πηγή δεδομένων. Το LoginButton λαμβάνει enabled ως read-only — αυτή είναι μία ακόμη μορφή State Hoisting όπου η κατάσταση δεν ανυψώνεται (το κουμπί δεν μπορεί να ενεργοποιηθεί από μόνο του), αλλά μεταβιβάζεται έτοιμη. Αυτή η προσέγγιση παρέχει μέγιστη ευελιξία με ελάχιστη σύζευξη στοιχείων.

State Hoisting εναντίον τοπικής κατάστασης: κριτήρια επιλογής

Δεν κάθε κατάσταση πρέπει να ανυψωθεί. Η τοπική κατάσταση (State μέσα σε Composable) είναι δικαιολογημένη όταν: τα δεδομένα χρειάζονται μόνο μέσα σε ένα στοιχείο, δεν επηρεάζουν τα γειτονικά στοιχεία, δεν πρέπει να επιβιώσουν την ανασύνθεση μιας συγκεκριμένης ενότητας. Για παράδειγμα, κατάσταση κινούμενων γραφικών, εστίαση πεδίου εισαγωγής, τρέχουσα θέση κύλισης — είναι λογικό να παραμένουν τοπικές.

Πότε το State Hoisting είναι απαραίτητο: η κατάσταση χρησιμοποιείται από πολλά θυγατρικά στοιχεία; η αλλαγή σε ένα θυγατρικό πρέπει να αντανακλάται σε ένα άλλο; πρέπει να δοκιμάσετε τη λογική αλλαγής κατάστασης ξεχωριστά από το UI; η κατάσταση πρέπει να διατηρηθεί κατά την αναδημιουργία της Activity. Σε αυτές τις περιπτώσεις, η τοπική κατάσταση δημιουργεί αντιγραφή και ασυνέπεια δεδομένων.

Υβριδική προσέγγιση: κρατήστε την ελάχιστη κατάσταση τοπικά, ανυψώστε την υπόλοιπη. Ο κανόνας του Compose: «ανυψώστε την κατάσταση όσο ψηλά χρειάζεται και όσο χαμηλά είναι δυνατόν». Στην πράξη, αυτό σημαίνει να ξεκινήσετε με τοπικό remember, και μόνο όταν προκύψει η ανάγκη πρόσβασης από άλλο στοιχείο — να ανυψώσετε το επίπεδο. Μην εφαρμόζετε το State Hoisting προληπτικά — περιπλέκει τον κώδικα χωρίς λόγο.