🍒 🕣 💘 SwiftUI का जादू या फंक्शन बिल्डरों के बारे में 👿 ⚙️ 🏪

क्या आपने VStack में 10 से अधिक दृश्य जोड़ने का प्रयास किया है?

 var body: some View { VStack { Text("Placeholder1") Text("Placeholder2") // ...    3  10 . . . Text("Placeholder11") } }

मैंने कोशिश की - यह संकलन नहीं है। हां, मैं भी पहले आश्चर्यचकित था और स्विफ्ट फोरम और गीथूब के अध्ययन में डूब गया। मेरे अध्ययन का परिणाम था - "यह अभी भी ¯\_(ツ)_/¯ my ¯\_(ツ)_/¯ संकलित नहीं करता है"। लेकिन रुकिए, देखते हैं कि क्यों।

फंक्शन बिल्डर

आरंभ करने के लिए, यह समझने के लायक है कि इस तरह के वाक्यविन्यास आमतौर पर कैसे उपलब्ध होते हैं। हमारे लिए असामान्य तत्वों की ऐसी घोषणात्मक निर्माण का आधार फंक्शन बिल्डर तंत्र है।
स्विफ्ट-इवोल्यूशन में जीथब पर जॉन मैकॉल और डग ग्रेगर का एक प्रस्ताव है - फंक्शन बिल्डरों (प्रस्ताव: एसई-एक्सएक्सएक्सएक्स) , जिसमें वे विस्तार से वर्णन करते हैं कि वे किस समस्या का सामना कर रहे थे, फंक्शनल बिल्डर का उपयोग करने का निर्णय क्यों लिया गया था और यह क्या था। एक।

तो यह क्या है?

संक्षेप में इसका वर्णन करना मुश्किल है, लेकिन संक्षेप में - यह एक ऐसा तंत्र है जो आपको तर्कों को सूचीबद्ध करने की अनुमति देता है, एक खजाने के शरीर में कुछ सामग्री, और इस सब से एक सामान्य परिणाम देता है।
प्रस्ताव का उद्धरण : SE-XXXX :

मुख्य विचार यह है कि हम अभिव्यक्ति के परिणाम को लेते हैं, जैसे नेस्टेड अभिव्यक्तियाँ जैसे अगर और स्विच, और उन्हें एक परिणाम में बनाते हैं, जो वर्तमान फ़ंक्शन का रिटर्न मान बन जाता है। यह "बिल्ड" फ़ंक्शन बिल्डर द्वारा नियंत्रित किया जाता है, जो एक कस्टम विशेषता है।

मूल

मूल विचार यह है कि हम बयानों के एक खंड के "उपेक्षित" अभिव्यक्ति परिणामों को लेते हैं - जिनमें नेफेडस्विचस्टैटेमेंट्स के निकाय जैसे निहित स्थान शामिल हैं - और उन्हें एक ही परिणाम मान में बनाते हैं जो वर्तमान फ़ंक्शन का वापसी मूल्य बन जाता है। जिस तरह से इस संग्रह का प्रदर्शन किया गया है, उसे एफिल्ट बिल्डर द्वारा नियंत्रित किया जाता है, जो कि एक नए प्रकार का कस्टम-विशेषता प्रकार है;

इस तरह का एक तंत्र आपको अनावश्यक विराम चिह्नों के बिना, घोषणात्मक वृक्ष जैसा कोड लिखने की अनुमति देता है:

 let myBody = body { let chapter = spellOutChapter ? "Chapter" : "" div { if useChapterTitles { h1(chapter + "1. Loomings.") } p { "Call me Ishmael. Some years ago" } p { "There is now your insular city" } } }

यह नई @_functionBuilder विशेषता के लिए उपलब्ध है। यह विशेषता कुछ बिल्डर को चिह्नित करती है, यह एक संरचना हो सकती है। यह बिल्डर कई विशिष्ट तरीकों को लागू करता है। इसके अलावा, इस बिल्डर का उपयोग विभिन्न स्थितियों में एक उपयोगकर्ता विशेषता के रूप में, स्वयं द्वारा किया जाता है।
नीचे मैं दिखाऊंगा कि यह कैसे काम करता है और इस तरह के कोड को कैसे व्यवस्थित किया जाए।

यह क्यों है?

इसलिए Apple अंतर्निहित डोमेन-विशिष्ट भाषा DSL के लिए समर्थन करना चाहता है।
जॉन मैककॉल और डग ग्रेगर बताते हैं कि इस तरह के कोड को पढ़ना और लिखना बहुत आसान है - यह वाक्य रचना को सरल बनाता है, इसे अधिक संक्षिप्त बनाता है और, परिणामस्वरूप, कोड अधिक समर्थित हो जाता है। इसी समय, वे ध्यान दें कि उनका समाधान एक सार्वभौमिक डीएसएल नहीं है।
यह समाधान समस्याओं के एक विशिष्ट सेट पर केंद्रित है, जिसमें रैखिक और पेड़ संरचनाओं जैसे कि XML, JSON, व्यू पदानुक्रम, आदि का वर्णन करना शामिल है।

इसके साथ कैसे काम करें?

आप अपना खुद का फंक्शन बिल्डर बना सकते हैं, मेरे लिए यह समझना आसान था कि यह कैसे काम करता है। एक बिल्डर के एक आदिम उदाहरण पर विचार करें जो तार को समाप्‍त करता है।

 // 1.  Builder @_functionBuilder struct MyBuilder { static func buildBlock(_ atrs: String...) -> String { return atrs.reduce("", + ) } }

 // 2.          func stringsReduce(@MyBuilder block: () -> String) -> String { return block() }

 // 3.     let result = stringsReduce { "1" "2" } print(result) // "12"

हुड के तहत, यह इस तरह से काम करेगा:

 let result = stringsReduce { return MyBuilder.build("1", "2") }

यह महत्वपूर्ण है कि बिल्डर के कार्यान्वयन में, विधियों को विशिष्ट नामों के साथ और इस सूची से एक विशिष्ट प्रकार के मापदंडों के साथ बिल्कुल स्थिर होना चाहिए। आप केवल इनपुट पैरामीटर का प्रकार और नाम बदल सकते हैं।

 static func buildBlock(_ <*atrs*>: <*String*>...) -> <*String*>

विशिष्ट विधि नाम बिल्डर में खोजा जाएगा और संकलन चरण में प्रतिस्थापित किया जाएगा। और यदि विधि नहीं मिली है, तो संकलन त्रुटि उत्पन्न होगी।
और यह जादू है। जब आप बिल्डर को लागू करते हैं, तो संकलक आपको कुछ भी नहीं बताएगा। यह उपलब्ध तरीकों के बारे में नहीं कहेगा, यह एक स्वत: पूर्ण के साथ मदद नहीं करेगा। केवल जब आप क्लाइंट कोड लिखते हैं जो इस बिल्डर द्वारा संसाधित नहीं किया जा सकता है तो क्या आपको एक अप्रत्यक्ष त्रुटि मिलती है।
अब तक, मैंने जो एकमात्र समाधान पाया है, वह विधियों की एक सूची द्वारा निर्देशित किया जाना है।
तो हमें अन्य तरीकों की आवश्यकता क्यों है? उदाहरण के लिए, चेक के साथ ऐसे कोड का समर्थन करना

 stringsReduce { if .random() { //   Bool "one string" } else { "another one" } "fixed string" }

इस सिंटैक्स का समर्थन करने के लिए, बिल्डर को buildEither(first:/second:) विधियों को लागू करने की आवश्यकता होती है

 static func buildEither(first: String) -> String { return first } static func buildEither(second: String) -> String { return second }

सामुदायिक प्रतिक्रिया

मजेदार बात यह है कि यह अभी स्विफ्ट 5.1 में नहीं है, यानी इस फीचर के साथ एक पुल का अनुरोध अभी तक नहीं डाला गया है, लेकिन फिर भी, ऐप्पल ने पहले ही इसे Xcode 11 बीटा में जोड़ दिया है। और फंक्शन बिल्डरों → पिक्स → स्विफ्ट फ़ोरम में, आप इस प्रस्ताव पर समुदाय की प्रतिक्रिया देख सकते हैं।

ViewBuilder

अब VStack वापस VStack और इसके VStack (संरेखण: रिक्ति: सामग्री :) के प्रलेखन देखें।
यह इस तरह दिखता है:

 init(alignment: HorizontalAlignment = .center, spacing: ? = nil, @ViewBuilder content: () -> Content)

और सामग्री तालिका से पहले एक कस्टम विशेषता है @ViewBuilder
इसे निम्नानुसार घोषित किया गया है:

 @_functionBuilder public struct ViewBuilder { /// Builds an empty view from an block containing no statements, `{ }`. public static func buildBlock() -> EmptyView /// Passes a single view written as a child view (e..g, `{ Text("Hello") }`) through /// unmodified. public static func buildBlock<Content>(_ content: Content) -> Content where Content : View }

उपयोगकर्ता विशेषता @ _functionBuilder , जो इसकी घोषणा की शुरुआत में पंजीकृत है।

और अगर आप दस्तावेज़ीकरण को और भी कम देखते हैं, तो आप कई स्थिर buildBlock विधियां देख सकते हैं जो तर्कों की संख्या में भिन्न हैं।

इसका मतलब है कि व्यू कोड

 var body: some View { VStack { Text("Placeholder1") Text("Placeholder2") Text("Placeholder3") } }

हुड के तहत इस तरह के लिए परिवर्तित कर दिया है

  var body: some View { VStack(alignment: .leading) { ViewBuilder.buildBlock(Text("Placeholder1"), Text("Placeholder2"), Text("Placeholder3")) } }

यानी बिल्डब्लॉक को पूरा करता है (:: _ :) बिल्डर विधि।

पूरी सूची से, अधिक से अधिक तर्कों के साथ विधि इस आदमी का बिल्डब्लॉक (::::::::: :) :) (10 तर्क):

 extension ViewBuilder { public static func buildBlock<C0, C1, C2, C3, C4, C5, C6, C7, C8, C9>(_ c0: C0, _ c1: C1, _ c2: C2, _ c3: C3, _ c4: C4, _ c5: C5, _ c6: C6, _ c7: C7, _ c8: C8, _ c9: C9) -> TupleView<(C0, C1, C2, C3, C4, C5, C6, C7, C8, C9)> where C0 : View, C1 : View, C2 : View, C3 : View, C4 : View, C5 : View, C6 : View, C7 : View, C8 : View, C9 : View }

और तदनुसार, मूल उदाहरण पर लौटते हुए, जब आप VStack और ग्यारह विचारों को अंदर उठाने की कोशिश करते हैं, तो कंपाइलर ViewBuilder'a buildBlock विधि को खोजने की कोशिश करता है, जिसमें 11 इनपुट तर्क हैं। लेकिन ऐसी कोई विधि नहीं है: इसलिए संकलन त्रुटि।
यह उन सभी संग्रहों के लिए सही है, जो इनिशियलाइज़र में @ViewBuilder विशेषता के साथ इनिशियलाइज़ेशन का उपयोग करते हैं: V | Z-Stack, List, Group और अन्य, जिनके अंदर आप एन्यूमरेशन के रूप में एक से अधिक दृश्य घोषित कर सकते हैं।
और यह दुखद है।

मेम (क्षमा करें, मुझे एक अच्छा मेम नहीं मिला)

कैसे हो?

हम ForEach का उपयोग करके इस सीमा को दरकिनार कर सकते हैं ForEach

 struct TestView : View { var body: some View { VStack { ForEach(texts) { i in Text(«\(i)») } } } var texts: [Int] { var result: [Int] = [] for i in 0...150 { result.append(i) } return result } }

या घोंसले के शिकार संग्रह:

 var body: some View { VStack { VStack { Text("Placeholder_1") Text("Placeholder_2") //   8 } Group { Text("11") Text("12") //   8 } } }

लेकिन इस तरह के फैसले बैसाखी की तरह दिखते हैं और एक उज्जवल भविष्य की उम्मीद है। लेकिन यह भविष्य कैसा है?
स्विफ्ट में पहले से ही वैराडिक पैरामीटर हैं । यह गणना द्वारा तर्क स्वीकार करने की एक विधि की क्षमता है। उदाहरण के लिए, सभी को ज्ञात print विधि आपको print(1, 2) और print(1, 2, 3, 4) दोनों लिखने की अनुमति देती है print(1, 2, 3, 4) और यह विधि के अनावश्यक अधिभार के बिना है।

 print(items: Any...)

लेकिन भाषा की यह विशेषता पर्याप्त नहीं है, क्योंकि buildBlock विधि इनपुट के रूप में विभिन्न सामान्य तर्कों को स्वीकार करती है।
Variadic जेनेरिक जोड़ने से इस समस्या का समाधान होगा। Variadic जेनेरिक आपको कई सामान्य प्रकारों से सार करने की अनुमति देते हैं, उदाहरण के लिए, कुछ इस तरह:

  static func buildBlock<…Component>(Component...) -> TupleView<(Component...)> where Component: View

और Apple बस इसे जोड़ने के लिए बाध्य है। सब कुछ इस तंत्र के खिलाफ है। और यह मुझे लगता है कि उन्होंने इसे केवल WWDC 2019 तक खत्म करने का प्रबंधन नहीं किया (लेकिन यह केवल अटकलें हैं)।

SwiftUI का जादू या फंक्शन बिल्डरों के बारे में