View Protocol — मुख्य अवधारणाएँ, SwiftUI में View प्रोटोकॉल

SwiftUI में View Protocol क्या है?

View Protocol SwiftUI का केंद्रीय प्रोटोकॉल है जो परिभाषित करता है कि कोई भी दृश्य तत्व अपनी सामग्री का वर्णन कैसे करता है। UIKit के विपरीत, जहाँ प्रत्येक तत्व वर्गों के माध्यम से UIView से विरासत प्राप्त करता है, SwiftUI प्रोटोकॉल-उन्मुख दृष्टिकोण का उपयोग करता है: कोई भी प्रकार जो View प्रोटोकॉल का अनुपालन करता है, स्क्रीन पर प्रदर्शित किया जा सकता है।

View प्रोटोकॉल को एक एकल परिकलित गुण body के कार्यान्वयन की आवश्यकता होती है जो कुछ सामग्री लौटाता है। हालाँकि, इस सरलता के पीछे एक शक्तिशाली संरचना प्रणाली छिपी है: body कोई भी प्रकार लौटा सकता है जो View का अनुपालन करता है, जिसमें प्रिमिटिव (Text, Image, Button), कंटेनर (VStack, HStack, ZStack) और कस्टम समग्र घटक शामिल हैं।

WWDC 2023 के अनुसार, SwiftUI अनुप्रयोगों में 95% से अधिक स्क्रीन View प्रोटोकॉल को लागू करने वाली संरचनाओं की संरचना के माध्यम से बनाई जाती हैं। यह View Protocol को संपूर्ण SwiftUI आर्किटेक्चर की नींव बनाता है।

Value type बनाम reference type

SwiftUI के लिए आवश्यक है कि View एक मान प्रकार (value type) (struct) हो, न कि वर्ग। यह एक महत्वपूर्ण आर्किटेक्चरल निर्णय है: मान प्रकारों का पूर्वानुमानित जीवनकाल होता है, कोई साझा परिवर्तनशील स्थिति नहीं होती है, और SwiftUI को कुशलतापूर्वक यह निर्धारित करने की अनुमति देते हैं कि पदानुक्रम के कौन से हिस्से बदल गए हैं और पुनः आरेखण की आवश्यकता है।

यदि आप View को वर्ग बनाने का प्रयास करते हैं, तो कंपाइलर एक त्रुटि देगा: View प्रोटोकॉल DynamicViewProperty प्रोटोकॉल से विरासत प्राप्त करता है, जिसके लिए मान शब्दार्थ की आवश्यकता होती है। वर्ग View का अनुपालन कर सकते हैं, लेकिन यह मुहावरेदार दृष्टिकोण को तोड़ता है और स्वचालित अपडेट के लाभों को खो देता है।

body: View प्रोटोकॉल का परिकलित गुण

body View प्रोटोकॉल की एकमात्र अनिवार्य आवश्यकता है। यह एक परिकलित गुण है जो स्क्रीन पर प्रदर्शित सामग्री लौटाता है। वापसी प्रकार some View है, जिसका अर्थ है “एक प्रकार जो View का अनुपालन करता है, जो कंपाइलर द्वारा निर्धारित किया जाएगा”।

struct GreetingView: View {
    var name: String

    var body: some View {
        VStack {
            Text("Hello, \(name)!")
                .font(.title)
                .foregroundColor(.blue)
            Button("Start") {
                print("Button pressed")
            }
        }
    }
}

body कैसे काम करता है: SwiftUI body को हर बार कॉल करता है जब एप्लिकेशन की स्थिति बदलती है और पुनः आरेखण की आवश्यकता होती है। फ्रेमवर्क नए View ट्री की तुलना पुराने से करता है और केवल आवश्यक परिवर्तन लागू करता है (diffing)। यह पूरी तरह से घोषणात्मक दृष्टिकोण है — आप वर्णन करते हैं कि क्या प्रदर्शित किया जाना चाहिए, और SwiftUI इसे लागू करने का ध्यान रखता है।

एक महत्वपूर्ण विवरण: body में दुष्प्रभाव नहीं होने चाहिए। इसे एप्लिकेशन के जीवनकाल में कई बार कॉल किया जाता है, और यदि body बाहरी स्थिति को संशोधित करता है — तो यह अप्रत्याशित व्यवहार की ओर ले जाता है। दुष्प्रभावों के लिए, task, onChange या DispatchQueue का उपयोग करें।

तत्वों की संख्या की सीमा

SwiftUI एक बाधा लगाता है: body केवल एक मूल तत्व लौटा सकता है। यदि आपको एक ही स्तर पर कई तत्व प्रदर्शित करने की आवश्यकता है, तो उन्हें एक कंटेनर में लपेटें — VStack, HStack, ZStack या Group। @ViewBuilder के आगमन के साथ, यह सीमा कम ध्यान देने योग्य हो गई है, लेकिन अवधारणात्मक रूप से body हमेशा एक ही View लौटाता है।

some View: प्रोटोकॉल में अपारदर्शी प्रकार

some View अपारदर्शी प्रकार (opaque type) सिंटैक्स है जो Swift 5.1 में विशेष रूप से SwiftUI के लिए पेश किया गया था। इसका अर्थ है कि एक फ़ंक्शन या गुण एक ठोस प्रकार लौटाता है जो View प्रोटोकॉल का अनुपालन करता है, लेकिन कॉल करने वाला कोड नहीं जानता और उसे यह जानने की आवश्यकता नहीं है कि कौन सा सटीक प्रकार लौटाया गया है।

Swift कंपाइलर प्रत्येक body कार्यान्वयन के लिए संकलन समय पर ठोस प्रकार निर्धारित करता है, लेकिन इसे बाहरी दुनिया से छिपाता है। यह SwiftUI को सभी घटकों के सटीक प्रकारों को जानकर View पदानुक्रम को अनुकूलित करने की अनुमति देता है, साथ ही डेवलपर को हस्ताक्षर बदले बिना कार्यान्वयन बदलने की सुविधा देता है।

struct ContentView: View {
    var body: some View {
        Text("Hello, World!") // Compiler knows this is Text
    }
}

क्यों some View और सिर्फ View नहीं? यदि body केवल View (एक प्रोटोकॉल के रूप में) लौटाता, तो SwiftUI संकलन समय पर ठोस प्रकार निर्धारित नहीं कर पाता। इससे एक अस्तित्वगत कंटेनर (existential container) में लपेटने का अतिरिक्त खर्च आता। some View कंपाइलर को प्रोटोकॉल की लचीलापन बनाए रखते हुए अनुकूलन के लिए पर्याप्त जानकारी देता है।

some View की सीमाएँ

मुख्य सीमा यह है कि body को एक ही प्रकार लौटाना चाहिए। आप एक शर्त की एक शाखा में Text और दूसरी में Image बिना विशेष रैपर (AnyView, Group, या @ViewBuilder) के नहीं लौटा सकते। कंपाइलर संकलन समय पर इसकी जाँच करता है: सभी संभावित वापसी पथों का एक ही प्रकार होना चाहिए।

इस सीमा को दूर करने के लिए @ViewBuilder (एकल TupleView प्रकार बनाता है), Group (जो भी एकल प्रकार लौटाता है) या AnyView (प्रकार मिटाता है लेकिन अतिरिक्त खर्च जोड़ता है) का उपयोग किया जाता है। AnyView का उपयोग केवल तब करना चाहिए जब अन्य विकल्प संभव न हों, क्योंकि यह SwiftUI अनुकूलन को अक्षम करता है।

@ViewBuilder: कई Views की असेंबली

@ViewBuilder एक परिणाम निर्माता (result builder) है जिसका एनोटेशन बिना नेस्टेड कंटेनरों के कई Views को एक रचना में इकट्ठा करने की अनुमति देता है। @ViewBuilder स्वचालित रूप से कई अभिव्यक्तियों को एक टपल (TupleView) में लपेटता है या सही वापसी प्रकार के साथ सशर्त तर्क (If / else / switch) लागू करता है।

struct DashboardView: View {
    var isLoggedIn: Bool

    @ViewBuilder
    var body: some View {
        if isLoggedIn {
            Text("Welcome!")
                .font(.largeTitle)
            ProfileCard()
        } else {
            LoginButton()
                .padding()
        }
    }
}

@ViewBuilder कैसे काम करता है: कंपाइलर @ViewBuilder के अंदर कोड के प्रत्येक ब्लॉक को स्थिर विधियों buildBlock, buildEither, buildOptional आदि के कॉल में बदल देता है। यदि किसी ब्लॉक में कई अभिव्यक्तियाँ हैं — तो उन्हें TupleView में लपेटा जाता है। यदि ब्लॉक में सशर्त तर्क है — तो कंपाइलर ConditionalContent उत्पन्न करता है, शाखा प्रकार को छिपाते हुए।

@ViewBuilder एक सीमा लगाता है: एक ब्लॉक में अधिकतम 10 तत्व (TupleView सीमा)। यदि आपको दस से अधिक तत्वों को इकट्ठा करने की आवश्यकता है, तो Group, ForEach का उपयोग करें या उप-घटकों में विभाजित करें। यह सीमा इसलिए मौजूद है क्योंकि Swift प्रत्येक आर्टी 1 से 10 के लिए एक अलग buildBlock ओवरलोड उत्पन्न करता है।

View संरचना और मॉडिफायर

संरचना (Composition) SwiftUI का एक प्रमुख सिद्धांत है: जटिल इंटरफ़ेस छोटे, पुन: प्रयोज्य View घटकों से बनाए जाते हैं। प्रत्येक घटक View प्रोटोकॉल को लागू करता है और स्क्रीन के अपने हिस्से के लिए जिम्मेदार होता है। मॉडिफायर (font, padding, foregroundColor) View पर लागू होते हैं और बदली गई सेटिंग्स के साथ एक नया View लौटाते हैं।

SwiftUI में मॉडिफायर उत्परिवर्तन नहीं हैं, बल्कि मूल View के चारों ओर एक नया रैपर बनाना है। प्रत्येक मॉडिफायर एक नया प्रकार (ModifiedContent) लौटाता है, जो SwiftUI को मॉडिफायर ट्री बनाने और केवल बदले हुए हिस्सों को कुशलतापूर्वक पुनः आरेखित करने की अनुमति देता है। मॉडिफायर लगाने का क्रम मायने रखता है: अलग-अलग क्रम अलग-अलग दृश्य परिणाम देते हैं।

Text("Hello, SwiftUI!")
    .font(.title)        // ModifiedContent
    .padding()           // ModifiedContent<..., PaddingModifier>
    .background(.yellow) // ModifiedContent<..., BackgroundModifier>
    .cornerRadius(8)    // ModifiedContent<..., CornerRadiusModifier>

प्रदर्शन अनुकूलन: SwiftUI View के ठोस मानों की तुलना नहीं करता, बल्कि पहचान तंत्र (id, ForEach, संरचनाओं की स्थिर पहचान) के माध्यम से उनकी पहचान की तुलना करता है। यदि View की संरचना नहीं बदली है — तो body को कॉल नहीं किया जाता है। यह Equatable तुलना और पदानुक्रम में डेटा ऊपर भेजने के लिए PreferenceKey तंत्र के माध्यम से प्राप्त किया जाता है।

प्रभावी संरचना के लिए, जटिल स्क्रीन को स्वतंत्र उप-घटकों में विभाजित करने की अनुशंसा की जाती है, प्रत्येक अपनी न्यूनतम स्थिति के साथ। यह SwiftUI को पूरी स्क्रीन के बजाय पदानुक्रम के केवल बदले हुए हिस्सों को पुनः आरेखित करने की अनुमति देता है।