State Hoisting: حالت بلند کرنا اور Compose میں یک طرفہ ڈیٹا بہاؤ

Jetpack Compose میں State Hoisting کیا ہے

State Hoisting ایک پیٹرن ہے جس میں Composable فنکشن حالت کا مالک نہیں ہوتا بلکہ اسے باہر سے حاصل کرتا ہے۔ فنکشن کے اندر var کے بجائے دو پیرامیٹر استعمال کیے جاتے ہیں: ڈسپلے کے لیے ایک قدر اور تبدیلیوں کو سنبھالنے کے لیے ایک لیمبڈا کال بیک۔ تکنیکی طور پر، اس کا مطلب ہے کہ چائلڈ جزو بے حالت (stateless) ہو جاتا ہے، جبکہ پیرنٹ حالت دار (stateful) ہوتا ہے۔

مثال: Material3 کا TextField جزو داخلی طور پر درج کردہ متن کو ذخیرہ نہیں کرتا۔ یہ value: String اور onValueChange: (String) -> Unit قبول کرتا ہے۔ TextField کو کال کرنے والا پیرنٹ var value by remember { mutableStateOf("") } اعلان کرتا ہے اور value اور onValueChange منتقل کرتا ہے۔ یہ کلاسک State Hoisting ہے: TextField ایک سادہ جزو ہے (صرف ڈسپلے کرتا ہے اور ان پٹ کی اطلاع دیتا ہے)، پیرنٹ ذہین ہے (حالت کا مالک)۔

بے حالت بمقابلہ حالت دار: بے حالت جزو جانچنا آسان ہے — یہ اندرونی حالت پر منحصر نہیں، اس کا رویہ مکمل طور پر ان پٹ پیرامیٹرز سے طے ہوتا ہے۔ حالت دار جزو تیز پروٹوٹائپنگ کے لیے آسان ہے لیکن دوبارہ استعمال مشکل ہے: یہ ایک ڈیٹا ماخذ سے مضبوطی سے منسلک ہوتا ہے۔ State Hoisting آپ کو انتخاب دیتا ہے: حالت کو اوپر لے جا کر کسی بھی جزو کو بے حالت بنایا جا سکتا ہے۔

یک طرفہ ڈیٹا بہاؤ (UDF) اور State Hoisting

UDF (یک طرفہ ڈیٹا بہاؤ) ایک آرکیٹیکچرل اصول ہے جہاں ڈیٹا ایک سمت میں چلتا ہے: سچائی کے ماخذ (ViewModel یا پیرنٹ Composable) سے UI تک، اور واقعات مخالف سمت میں بہتے ہیں۔ State Hoisting انفرادی جزو کی سطح پر UDF کا نفاذ ہے۔ ہر جزو کے اپنی حالت کو کب اور کیسے تبدیل کرنے کا فیصلہ کرنے کے بجائے، یہ پیرنٹ کو کسی واقعہ کے بارے میں مطلع کرتا ہے، اور پیرنٹ فیصلہ کرتا ہے کہ حالت کو کیسے تبدیل کرنا ہے۔

UDF کے فوائد: پیش قیاسی — حالت صرف ایک جگہ تبدیل ہوتی ہے، مسابقت کی صورتوں کو ختم کرتی ہے؛ ٹریس ایبلٹی — کال اسٹیک تبدیلیوں کی زنجیر کو دوبارہ تشکیل دینے دیتا ہے؛ جانچ — حالت دار منطق کو علیحدہ کلاس میں نکالا جا سکتا ہے اور UI کے بغیر جانچا جا سکتا ہے۔ بڑے منصوبوں میں، State Hoisting کے ساتھ UDF حقیقی معیار ہے۔

سچائی کا واحد ماخذ (Single Source of Truth) ایک اور اصول ہے جو UDF کے ساتھ آتا ہے۔ حالت کے ہر ٹکڑے کا بالکل ایک ماخذ ہوتا ہے۔ اگر دو جزو ایک ہی حالت استعمال کرتے ہیں، تو ماخذ مشترکہ ہونا چاہیے (ViewModel یا مشترکہ پیرنٹ سطح پر)۔ State Hoisting یقینی بناتا ہے کہ ماخذ درجہ بندی میں اوپر ہے اور حالت کا تکرار نہیں ہوتا۔

State Hoisting کے قواعد: کب اور کیسے حالت بلند کریں

بنیادی اصول: حالت کو کم سے کم ممکنہ سطح تک بلند کیا جانا چاہیے جو تمام اجزاء کے لیے کافی ہو جنہیں اس کی ضرورت ہے۔ اگر حالت صرف ایک جزو کے اندر استعمال ہوتی ہے — اسے مقامی رکھیں۔ اگر دو ملحقہ اجزاء کو ایک ہی حالت کی ضرورت ہے — اسے مشترکہ پیرنٹ تک بلند کریں۔ اگر حالت پوری اسکرین پر ضروری ہے — اسے ViewModel تک بلند کریں۔

کم سے کم بلندی کا اصول غیر ضروری پیچیدگی کو روکتا ہے۔ ٹیکسٹ فیلڈ کی حالت کو ViewModel میں بلند کرنے کا کوئی فائدہ نہیں اگر یہ صرف ایک اسکرین کے اندر استعمال ہوتی ہے اور Activity کی دوبارہ تخلیق پر محفوظ نہیں ہوتی۔ اسکرین پیرنٹ سطح پر rememberSaveable استعمال کریں، ViewModel میں نہیں، UI حالت کے لیے جو اسکرین گردش سے بچنی چاہیے لیکن کاروباری منطق کو اس کی ضرورت نہیں۔

ViewModel میں کب بلند کریں: اگر حالت کو Activity کی دوبارہ تخلیق پر باقی رہنا ہے، اگر متعدد اسکرینوں کو اس کی ضرورت ہے، اگر حالت کی تبدیلی کاروباری منطق (نیٹ ورک درخواستیں، ڈیٹا بیس) کو متحرک کرتی ہے۔ ViewModel سطح پر State Hoisting MVVM آرکیٹیکچر میں ایک معیاری پیٹرن ہے، جہاں UI پرت بے حالت اور ViewModel حالت دار ہے۔

    // ❌ برا: جزو اپنی حالت کا مالک ہے
@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 کی مثالیں

دو فیلڈز (ای میل، پاس ورڈ) اور ایک بٹن والی لاگ ان اسکرین پر غور کریں۔ تینوں اجزاء State Hoisting کے ذریعے حالت حاصل کرتے ہیں: ای میل اور پاس ورڈ پیرنٹ کے زیر انتظام ہیں، بٹن اپنی فعال حالت ایک قدر کے طور پر حاصل کرتا ہے۔

    // اسکرین سطح پر State Hoisting
@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val uiState by viewModel.uiState.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        // ای میل فیلڈ — لیمبڈا کے ذریعے 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)
    }
}

// بے حالت جزو: ای میل + کال بیک حاصل کرتا ہے
@Composable
fun EmailField(email: String, onEmailChange: (String) -> Unit) {
    OutlinedTextField(
        value = email,
        onValueChange = onEmailChange,
        label = { Text("ای میل") },
        singleLine = true
    )
}

// بے حالت بٹن جزو
@Composable
fun LoginButton(enabled: Boolean, onClick: () -> Unit) {
    Button(onClick = onClick, enabled = enabled) {
        Text("لاگ ان")
    }
}

EmailField اور PasswordField مکمل طور پر بے حالت ہیں۔ انہیں کسی بھی ڈیٹا ماخذ سے منسلک کرکے کسی بھی اسکرین پر دوبارہ استعمال کیا جا سکتا ہے۔ LoginButton enabled کو صرف پڑھنے کے لیے حاصل کرتا ہے — یہ State Hoisting کی ایک اور شکل ہے جہاں حالت بلند نہیں ہوتی (بٹن خود کو فعال نہیں کر سکتا) بلکہ تیار شدہ نیچے بھیجی جاتی ہے۔ یہ نقطہ نظر کم سے کم جزو وابستگی کے ساتھ زیادہ سے زیادہ لچک فراہم کرتا ہے۔

State Hoisting بمقابلہ مقامی حالت: انتخاب کا معیار

ہر حالت کو بلند کرنے کی ضرورت نہیں۔ مقامی حالت (Composable کے اندر State) اس وقت جائز ہے جب: ڈیٹا صرف ایک جزو کے اندر ضروری ہو، پڑوسی عناصر کو متاثر نہ کرے، اور کسی مخصوص حصے کی دوبارہ تشکیل سے بچنے کی ضرورت نہ ہو۔ مثال کے طور پر، اینی میشن حالت، ان پٹ فیلڈ فوکس، موجودہ اسکرول پوزیشن — انہیں مقامی رکھنا معقول ہے۔

State Hoisting کب ضروری ہے: حالت متعدد چائلڈ اجزاء کے ذریعے استعمال ہوتی ہے؛ ایک چائلڈ میں تبدیلی دوسرے میں ظاہر ہونی چاہیے؛ حالت کی تبدیلیوں کی منطق کو UI سے الگ جانچنا ضروری ہے؛ حالت کو Activity کی دوبارہ تخلیق پر باقی رہنا چاہیے۔ ان صورتوں میں، مقامی حالت ڈیٹا کا تکرار اور عدم مطابقت پیدا کرتی ہے۔

مخلوط نقطہ نظر: کم سے کم حالت مقامی رکھیں، باقی بلند کریں۔ Compose کا اصول: “حالت کو جتنا ضروری ہو اتنا اوپر اور جتنا ممکن ہو اتنا نیچے بلند کریں۔” عملی طور پر، اس کا مطلب مقامی remember سے شروع کرنا اور صرف اس وقت سطح بلند کرنا جب کسی دوسرے جزو سے رسائی کی ضرورت ہو۔ State Hoisting کو پیشگی طور پر لاگو نہ کریں — یہ بغیر ضرورت کے کوڈ کو پیچیدہ بناتا ہے۔