यूनिडायरेक्शनल डेटा फ़्लो — यह क्या है, Android और iOS में UDF

यूनिडायरेक्शनल डेटा फ़्लो क्या है?

यूनिडायरेक्शनल डेटा फ़्लो (UDF) एक आर्किटेक्चरल पैटर्न है जहां डेटा एक बंद लूप में एक दिशा में चलता है, जो View और Model के बीच फीडबैक लूप को समाप्त करता है। द्वि-दिशीय बाइंडिंग के विपरीत, जहां UI में परिवर्तन तुरंत मॉडल को अपडेट करता है, UDF को प्रत्येक स्थिति परिवर्तन के लिए एक स्पष्ट क्रिया (Intent, Event, Action) की आवश्यकता होती है। यह डेटा प्रवाह को पूरी तरह से पूर्वानुमेय बनाता है: किसी भी समय, यह निर्धारित किया जा सकता है कि किस क्रिया ने वर्तमान स्थिति को जन्म दिया।

UDF की अवधारणा वेब फ्रेमवर्क — Redux (JavaScript, 2015) और Elm (2012) — से आई और इसे मोबाइल डेवलपमेंट के लिए अनुकूलित किया गया। Google I/O 2024 के अनुसार, UDF Jetpack Compose के लिए अनुशंसित आर्किटेक्चर बन गया है, जो LiveData के साथ क्लासिक MVVM को विस्थापित कर रहा है। iOS पर, Point-Free के The Composable Architecture (TCA) में एक समान दृष्टिकोण लागू किया गया है, जिसका उपयोग Swift Community Survey (2024) के अनुसार 15% से अधिक iOS डेवलपर्स करते हैं।

UDF का मुख्य लाभ एकल स्रोत सत्य (SSOT) है: सभी एप्लिकेशन स्थिति एक स्थान पर संग्रहीत होती है और सख्ती से परिभाषित संचालन के माध्यम से संशोधित की जाती है। यह डिबगिंग, परीक्षण और बग पुनरुत्पादन को सरल बनाता है, क्योंकि प्रत्येक स्थिति परिवर्तन लॉग किया जाता है और उसी Intents को पुनः भेजकर पुनरुत्पादित किया जा सकता है।

UDF कैसे काम करता है: State → View → Intent → Reducer चक्र

मूल UDF चक्र चार चरणों से बना है: State (वर्तमान स्थिति) View में प्रदर्शित होती है; उपयोगकर्ता एक क्रिया करता है जो Intent बन जाती है; Intent को Reducer (शुद्ध फ़ंक्शन) में संसाधित किया जाता है, जो एक नई State बनाता है; नई स्थिति पुनः रेंडरिंग के लिए View को भेजी जाती है। यह चक्र प्रत्येक उपयोगकर्ता या सिस्टम ईवेंट पर दोहराया जाता है।

चक्र के प्रत्येक तत्व की सख्त जिम्मेदारी है: State — एक अपरिवर्तनीय ऑब्जेक्ट जो किसी विशिष्ट क्षण में स्क्रीन स्थिति का वर्णन करता है; View — एक फ़ंक्शन जो State प्रदर्शित करता है; Intent — एक मान जो उपयोगकर्ता के आशय का वर्णन करता है (जैसे, LoginIntent.Submit); Reducer — बिना दुष्प्रभावों के एक शुद्ध फ़ंक्शन, जो वर्तमान State और Intent लेता है और एक नई State लौटाता है। दुष्प्रभाव (नेटवर्क अनुरोध, डेटाबेस संचालन) को एक अलग Middleware या Effect परत में ले जाया जाता है।

Google Android Architecture लेख (2024) के अनुसार, Reducer की शुद्धता एक महत्वपूर्ण आवश्यकता है: यदि Reducer में नेटवर्क कॉल या डेटाबेस लेखन है, तो डेटा प्रवाह का परीक्षण और डिबगिंग असंभव हो जाता है। सभी दुष्प्रभावों को Reducer को कॉल करने से पहले ViewModel कोरूटीन या Swift Task में निष्पादित किया जाना चाहिए, और परिणाम को एक नए Intent के रूप में भेजा जाना चाहिए।

Android में UDF: ViewModel + StateFlow + Intent

Android में, UDF कार्यान्वयन तीन Jetpack घटकों पर बनाया गया है: ViewModel जीवनचक्र प्रबंधित करता है, StateFlow एक प्रतिक्रियाशील स्थिति स्ट्रीम प्रदान करता है, Intent (sealed class) सभी संभावित उपयोगकर्ता क्रियाओं का वर्णन करता है। View Compose में collectAsState() या View सिस्टम में observe() के माध्यम से StateFlow की सदस्यता लेता है।

sealed class LoginIntent {
    data object Submit : LoginIntent()
    data class UpdateEmail(val value: String) : LoginIntent()
    data class UpdatePassword(val value: String) : LoginIntent()
}

data class LoginState(
    val email: String = "",
    val password: String = "",
    val isLoading: Boolean = false,
    val error: String? = null
)

class LoginViewModel : ViewModel() {
    private val _state = MutableStateFlow(LoginState())
    val state: StateFlow<LoginState> = _state.asStateFlow()

    fun onIntent(intent: LoginIntent) {
        when (intent) {
            is LoginIntent.UpdateEmail -> {
                _state.update { it.copy(email = intent.value) }
            }
            is LoginIntent.UpdatePassword -> {
                _state.update { it.copy(password = intent.value) }
            }
            is LoginIntent.Submit -> {
                _state.update { it.copy(isLoading = true, error = null) }
                loginUseCase(_state.value.email, _state.value.password)
                    .onSuccess {
                        _state.update { it.copy(isLoading = false) }
                    }
                    .onFailure { e ->
                        _state.update { it.copy(isLoading = false, error = e.message) }
                    }
            }
        }
    }
}

@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val state by viewModel.state.collectAsState()

    LoginForm(
        email = state.email,
        onEmailChange = { viewModel.onIntent(LoginIntent.UpdateEmail(it)) },
        password = state.password,
        onPasswordChange = { viewModel.onIntent(LoginIntent.UpdatePassword(it)) },
        isLoading = state.isLoading,
        onSubmit = { viewModel.onIntent(LoginIntent.Submit) }
    )
}

उदाहरण Android में पूर्ण UDF चक्र प्रदर्शित करता है: LoginIntent सभी संभावित क्रियाओं (ईमेल परिवर्तन, पासवर्ड परिवर्तन, फॉर्म सबमिशन) का वर्णन करता है, LoginState अपरिवर्तनीय स्थिति है, LoginViewModel Intents को संसाधित करता है और StateFlow को अपडेट करता है, और Compose स्क्रीन collectAsState() के माध्यम से स्थिति की सदस्यता लेती है। प्रत्येक स्थिति परिवर्तन एक विशिष्ट Intent के प्रसंस्करण का परिणाम है, जो डेटा प्रवाह को पूरी तरह से पारदर्शी बनाता है।

iOS में UDF: TCA और Observable पैटर्न

iOS पर, UDF को The Composable Architecture (TCA) Point-Free या iOS 17+ के साथ मूल Observable पैटर्न के माध्यम से कार्यान्वित किया जाता है। TCA State + Action + Reducer + Store का तैयार चक्र प्रदान करता है, जहां Store एकमात्र स्रोत सत्य है, और View @Observable या ObservableObject के माध्यम से परिवर्तनों की सदस्यता लेता है।

struct LoginState: Equatable {
    var email = ""
    var password = ""
    var isLoading = false
    var error: String?
}

enum LoginAction {
    case emailChanged(String)
    case passwordChanged(String)
    case submit
    case loginResponse(Result<User, Error>)
}

let loginReducer = Reducer<LoginState, LoginAction> { state, action in
    switch action {
    case .emailChanged(let email):
        state.email = email
        return .none
    case .passwordChanged(let password):
        state.password = password
        return .none
    case .submit:
        state.isLoading = true
        state.error = nil
        return .run { send in
            let result = await loginUseCase(state.email, state.password)
            await send(.loginResponse(result))
        }
    case .loginResponse(.success):
        state.isLoading = false
        return .none
    case .loginResponse(.failure(let error)):
        state.isLoading = false
        state.error = error.localizedDescription
        return .none
    }
}

struct LoginView: View {
    let store: StoreOf<LoginReducer>

    var body: some View {
        WithViewStore(store, observe: { $0 }) { viewStore in
            Form {
                TextField("Email", text: viewStore.binding(get: \.email, send: { .emailChanged($0) }))
                SecureField("Password", text: viewStore.binding(get: \.password, send: { .passwordChanged($0) }))
                Button("लॉग इन करें") { viewStore.send(.submit) }
            }
        }
    }
}

loginReducer एक शुद्ध फ़ंक्शन है: यह सीधे नेटवर्क अनुरोध नहीं करता बल्कि एक Effect लौटाता है जो TCA रनटाइम द्वारा निष्पादित किया जाएगा। यह परीक्षणों में प्रभावों को प्रतिस्थापित करके रिड्यूसर को अलगाव में परीक्षण करने की अनुमति देता है। View WithViewStore के माध्यम से Store परिवर्तनों की सदस्यता लेता है और send() के माध्यम से Actions भेजता है। Store नष्ट होने पर TCA स्वचालित रूप से प्रभावों को रद्द करने का संचालन करता है, मेमोरी लीक को रोकता है।

UDF बनाम MVVM: क्या अंतर है?

MVVM और UDF अक्सर भ्रमित होते हैं, लेकिन उनके बीच एक मूलभूत अंतर है। MVVM एक संरचनात्मक पैटर्न है जो कोड को तीन परतों (Model, View, ViewModel) में अलग करता है लेकिन डेटा प्रवाह की दिशा को परिभाषित नहीं करता है। UDF एक व्यवहारिक पैटर्न है जो बताता है कि उस संरचना के भीतर डेटा कैसे चलता है। LiveData के साथ MVVM में, द्वि-दिशीय बाइंडिंग और एकदिशीय प्रवाह दोनों संभव हैं — UDF MVVM में सख्त Intent प्रसंस्करण नियम जोड़ता है।

Android Developers दस्तावेज़ीकरण (2024) के अनुसार, Compose के लिए अनुशंसित आर्किटेक्चर MVVM के अंदर UDF है: ViewModel State संग्रहीत करता है और Intents को संसाधित करता है, View State की सदस्यता लेता है और Intents भेजता है। Google बिना व्यावसायिक तर्क वाली सरल स्क्रीन के लिए केवल DataBinding के माध्यम से द्वि-दिशीय बाइंडिंग के साथ क्लासिक MVVM की अनुशंसा करता है। Jetpack Compose के लिए, प्राथमिक परिदृश्य स्पष्ट ईवेंट हैंडलिंग के साथ UDF है।

तुलना तालिका:

UDF लागू करते समय सामान्य गलतियाँ

सबसे आम गलती Reducer के अंदर दुष्प्रभाव है। MVVM के आदी डेवलपर नेटवर्क अनुरोधों को सीधे Intent हैंडलर में रखते हैं, जो Reducer को अशुद्ध बनाता है और परीक्षण क्षमता को तोड़ता है। सभी प्रभावों को एक मान (Effect / SideEffect) के रूप में लौटाया जाना चाहिए और फ्रेमवर्क बुनियादी ढांचे द्वारा निष्पादित किया जाना चाहिए। Android में, इसके लिए ViewModel में कोरूटीन का उपयोग किया जाता है; TCA में — Effect.run।

दूसरी गलती अत्यधिक विस्तृत Intents है। प्रत्येक कीस्ट्रोक, स्लाइडर मूवमेंट और टेक्स्ट परिवर्तन एक अलग Intent उत्पन्न करता है। इनपुट फ़ील्ड के लिए यह अत्यधिक है — ऐसे मामलों में, फॉर्म के अंदर एकदिशीय प्रवाह के साथ बाइंडिंग (स्थानीय स्थिति) का उपयोग करना स्वीकार्य है, और केवल महत्वपूर्ण क्रियाओं (सबमिट, नेविगेशन) के लिए वैश्विक Intent भेजना चाहिए।

तीसरी गलती प्रभाव रद्दीकरण संचालन का अभाव है। यदि उपयोगकर्ता स्क्रीन छोड़ देता है जबकि कोरूटीन या Task अभी भी निष्पादित हो रहा है, तो परिणाम पहले से नष्ट हो चुके View पर लागू हो सकता है। Android में, viewModelScope.cancel() या takeWhileActive() का उपयोग करें; TCA में, Store नष्ट होने पर प्रभाव स्वचालित रूप से रद्द हो जाते हैं। Google Issue Tracker (2024) के अनुसार, अधूरे कोरूटीन से लीक Compose अनुप्रयोगों में क्रैश के शीर्ष 5 कारणों में से हैं।