State Hoisting: بالا بردن وضعیت و جریان داده یکطرفه در Compose

State Hoisting در Jetpack Compose چیست

State Hoisting (بالا بردن وضعیت) — الگویی است که در آن تابع Composable وضعیتی ندارد، بلکه آن را از خارج دریافت می‌کند. به جای استفاده از var داخل تابع، از دو پارامتر استفاده می‌شود: مقدار برای نمایش و لامبدا-کالبک برای مدیریت تغییرات. از نظر فنی، این به معنای این است که کامپوننت فرعی بدون وضعیت (stateless) و والد با وضعیت (stateful) می‌شود.

مثال: کامپوننت TextField از Material3 متن وارد شده را داخل خود ذخیره نمی‌کند. آن value: String و onValueChange: (String) -> Unit را می‌پذیرد. والدی که TextField را فراخوان می‌کند، var value by remember { mutableStateOf("") } را اعلام کرده و value و onValueChange را ارسال می‌کند. این یک State Hoisting کلاسیک است: TextField — کامپوننت ساده (فقط نمایش می‌دهد و از ورود خبر می‌دهد)، والد — هوشمند (وضعیت را دارد).

Stateless در مقابل Stateful: کامپوننت Stateless آزمودن ساده‌تر است — آن به وضعیت داخلی وابسته نیست، رفتارش تماماً توسط پارامترهای ورودی تعیین می‌شود. کامپوننت Stateful برای نمونه‌سازی سریع مناسب است، اما استفاده مجدد از آن سخت‌تر است — آن به یک منبع داده محدود شده است. State Hoisting انتخاب را می‌دهد: هر کامپوننتی را می‌توان با انتقال وضعیت به بالا، stateless کرد.

جریان داده یکطرفه (UDF) و State Hoisting

UDF (Unidirectional Data Flow) — اصلی معماری است که در آن داده‌ها در یک جهت جریان دارند: از منبع حقیقت (ViewModel یا والد Composable) به UI، و رویدادها در جهت مخالف. State Hoisting پیاده‌سازی UDF در سطح کامپوننت‌های جداگانه است. به جای اینکه هر کامپوننت خودش تصمیم بگیرد که کی و چگونه وضعیتش را تغییر دهد، آن در باره رویداد به والد اطلاع می‌دهد، و والد تصمیم می‌گیرد چگونه وضعیت را تغییر دهد.

مزایای UDF: قابلیت پیش‌بینی — وضعیت تنها در یک جا تغییر می‌کند، که race conditions را از بین می‌برد؛ قابلیت ردیابی — از روی پیش‌های صدا زنی می‌توان زنجیره تغییرات را بازسازی کرد؛ آزمایش — منطق هاستفول را می‌توان در یک کلاس جداگانه قرار داده و بدون UI آزمود. در پروژه‌های بزرگ، UDF همراه با State Hoisting یک استاندارد ده فاکتو است.

تک منبع حقیقت (Single Source of Truth) — اصل دیگری که همراه UDF می‌آید. هر بخش وضعیت دقیقاً یک منبع دارد. اگر دو کامپوننت از یک وضعیت استفاده می‌کنند، منبع باید مشترک باشد (در سطح ViewModel یا والد مشترک). State Hoisting تضمین می‌کند که منبع در بالای سلسله مراتب قرار داشته و از تکرار وضعیت جلوگیری شود.

قواعد State Hoisting: کی و چگونه وضعیت را بالا ببریم

قاعده اصلی: وضعیت باید به مینیمال سطح ممکن بالا برده شود که برای همه کامپوننت‌هایی که به آن نیاز دارند کافی باشد. اگر وضعیت فقط داخل یک کامپوننت استفاده می‌شود — آن را محلی نگه دارید. اگر دو کامپوننت مجاور به یک وضعیت نیاز دارند — به والد مشترک بالا ببرید. اگر وضعیت در تمام صفحه مورد نیاز است — به ViewModel بالا ببرید.

قاعده بالا بردن مینیمال از پیچیدگی بی‌لورض جلوگیری می‌کند. بالا بردن وضعیت یک فیلد متنی به ViewModel اگر تنها داخل یک صفحه استفاده شود و در بازسازی Activity ذخیره نمی‌شود، بی‌معنی است. برای وضعیت UI که باید چرخش صفحه را تحمل کند اما برای منطق کسب و کار لازم نیست، از rememberSaveable در سطح والد صفحه به جای ViewModel استفاده کنید.

کی به 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 از طریق لامبدا
        EmailField(
            email = uiState.email,
            onEmailChange = { viewModel.onEmailChanged(it) }
        )

        // فیلد رمز عبور — همینطور
        PasswordField(
            password = uiState.password,
            onPasswordChange = { viewModel.onPasswordChanged(it) }
        )

        // دکمه — فقط enabled را دریافت می‌کند (فقط خواندنی)
        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 را به صورت تنها خواندنی دریافت می‌کند — این شکل دیگری از State Hoisting است که در آن وضعیت بالا برده نمی‌شود (دکمه نمی‌تواند خودش را فعال کند)، بلکه آماده ارسال می‌شود. این رویکرد با کمترین وابستگی کامپوننت‌ها، حداکثر انعطاف‌پذیری را فراهم می‌کند.

State Hoisting در مقابل وضعیت محلی: معیارهای انتخاب

هر وضعیتی نیاز به بالا بردن ندارد. وضعیت محلی (State داخل Composable) موجه است زمانی که: داده‌ها فقط داخل یک کامپوننت مورد نیاز هستند، بر عناصر مجاور تأثیر نمی‌گذارند، نیازی به تحمل بازسازی بخش مشخص نیست. مثالاً، وضعیت انیمیشن، فوکوس فیلد ورودی، موقعیت افقی پیمایش — مقدر است محلی نگه داشته شوند.

وقتی State Hoisting ضروری است: وضعیت توسط چند کامپوننت فرعی استفاده می‌شود؛ تغییر در یک فرعی باید در دیگری منعکس شود؛ منطق تغییر وضعیت باید جداگانه از UI آزموده شود؛ وضعیت باید در بازسازی Activity ذخیره شود. در این موارد، وضعیت محلی باعث تکرار و ناهماهنگی داده‌ها می‌شود.

رویکرد ترکیبی: حداقل وضعیت را محلی نگه داشته و باقی را بالا ببرید. قاعده Compose: «وضعیت را تا آنجا که لازم است بالا ببرید و تا آنجا که ممکن است پایین نگه دارید». در عمل، این به معنای شروع با remember محلی است، و تنها وقتی نیاز به دسترسی از کامپوننت دیگر پیدا شود — سطح را بالا ببرید. State Hoisting را احتیاطی انجام ندهید — این کد را بدون لزوم پیچیده می‌کند.