स्पंदन। कुंजी! वे किस लिए हैं?

key पैरामीटर लगभग हर विजेट निर्माता में पाया जा सकता है, लेकिन यह पैरामीटर शायद ही कभी विकास में उपयोग किया जाता है। विजेट्स ट्री में विजेट्स को स्थानांतरित करते समय Keys राज्य को बनाए रखती है। व्यवहार में, इसका मतलब है कि वे उपयोगकर्ता के स्क्रॉल स्थान को बचाने या संग्रह को बदलने पर स्थिति को बचाने के लिए उपयोगी हो सकते हैं।

यह लेख निम्नलिखित वीडियो से अनुकूलित है। यदि आप पढ़ने के बजाय सुनना / देखना पसंद करते हैं, तो वीडियो आपको समान सामग्री प्रदान करेगा।

keys बारे में गुप्त जानकारी

अधिकांश समय ... आपको keys आवश्यकता नहीं है। सामान्य तौर पर, उन्हें जोड़ने में कोई बुराई नहीं है, लेकिन यह भी आवश्यक नहीं है, क्योंकि वे बस एक नए कीवर्ड के रूप में जगह लेते हैं या एक नए चर के दोनों किनारों पर घोषणा करते हैं (मैं आपके बारे में बात कर रहा हूं, Map<Foo, Bar> aMap = Map<Foo, Bar>() )।

लेकिन अगर आपको लगता है कि आप कलेक्शन में विजेट्स जोड़ या हटा रहे हैं, जिसमें कुछ स्टेट्स हैं और एक ही तरह के हैं, तो आपको keys ध्यान देना चाहिए!

विगेट्स के संग्रह को बदलते समय आपको keys आवश्यकता क्यों है, यह प्रदर्शित करने के लिए, मैंने दो रंगीन विगेट्स के साथ एक बहुत ही सरल अनुप्रयोग लिखा है जो एक बटन क्लिक करने पर स्थानों को बदलते हैं:

आवेदन के इस संस्करण में, मेरे पास Row में यादृच्छिक रंग ( StatelessWidget ) के दो स्टेटलेस विजेट हैं और इसमें कलर विजेट के क्रम को संग्रहीत करने के लिए स्टेट ( StatefulWidget ) के साथ StatefulWidget विजेट हैं। जब मैं नीचे FloatingActionButton बटन पर क्लिक करता हूँ, तो रंग विगेट्स सही ढंग से सूची में अपना स्थान बदलते हैं:

 void main() => runApp(new MaterialApp(home: PositionedTiles())); class PositionedTiles extends StatefulWidget { @override State<StatefulWidget> createState() => PositionedTilesState(); } class PositionedTilesState extends State<PositionedTiles> { List<Widget> tiles = [ StatelessColorfulTile(), StatelessColorfulTile(), ]; @override Widget build(BuildContext context) { return Scaffold( body: Row(children: tiles), floatingActionButton: FloatingActionButton( child: Icon(Icons.sentiment_very_satisfied), onPressed: swapTiles), ); } swapTiles() { setState(() { tiles.insert(1, tiles.removeAt(0)); }); } } class StatelessColorfulTile extends StatelessWidget { Color myColor = UniqueColorGenerator.getColor(); @override Widget build(BuildContext context) { return Container( color: myColor, child: Padding(padding: EdgeInsets.all(70.0))); } } 

लेकिन अगर हम अपने कलर विजेट्स में स्टेट जोड़ते हैं (उन्हें StatefulWidget बनाते हैं) और उनमें कलर स्टोर करते हैं, तो जब हम बटन पर क्लिक करते हैं तो ऐसा लगता है जैसे कुछ भी नहीं हो रहा है:

 List<Widget> tiles = [ StatefulColorfulTile(), StatefulColorfulTile(), ]; ... class StatefulColorfulTile extends StatefulWidget { @override ColorfulTileState createState() => ColorfulTileState(); } class ColorfulTileState extends State<ColorfulTile> { Color myColor; @override void initState() { super.initState(); myColor = UniqueColorGenerator.getColor(); } @override Widget build(BuildContext context) { return Container( color: myColor, child: Padding( padding: EdgeInsets.all(70.0), )); } } 

स्पष्टीकरण के रूप में: ऊपर का कोड छोटी गाड़ी है, जिसमें उपयोगकर्ता द्वारा बटन क्लिक करने पर यह कलर एक्सचेंज नहीं दिखाता है। इस त्रुटि को ठीक करने के लिए, आपको रंगीन StatefulWidget विजेट्स में key पैरामीटर जोड़ना होगा, और तब विजेट्स को स्वैप करना होगा जो हम चाहते हैं:

 List<Widget> tiles = [ StatefulColorfulTile(key: UniqueKey()), // Keys added here StatefulColorfulTile(key: UniqueKey()), ]; ... class StatefulColorfulTile extends StatefulWidget { StatefulColorfulTile({Key key}) : super(key: key); // NEW CONSTRUCTOR @override ColorfulTileState createState() => ColorfulTileState(); } class ColorfulTileState extends State<ColorfulTile> { Color myColor; @override void initState() { super.initState(); myColor = UniqueColorGenerator.getColor(); } @override Widget build(BuildContext context) { return Container( color: myColor, child: Padding( padding: EdgeInsets.all(70.0), )); } } 

लेकिन यह केवल तभी आवश्यक है जब आपके पास सबट्री में राज्य के साथ विगेट्स हों जो आप बदल रहे हैं। यदि आपके संग्रह में विजेट के पूरे सबट्री की कोई स्थिति नहीं है, तो किसी भी कुंजी की आवश्यकता नहीं है।
वहाँ तुम जाओ! सब सब में, आप सभी को Flutter में keys का उपयोग करने के लिए जानने की आवश्यकता है। लेकिन अगर आप थोड़ा गहरा जाना चाहते हैं कि क्या हो रहा है ...

यह समझना कि keys कभी-कभी क्यों आवश्यक होती है

आप अभी भी यहाँ हैं, है ना? अच्छी तरह से तो फ़्लटर मैज बनने के लिए तत्व पेड़ों और विगेट्स की वास्तविक प्रकृति का पता लगाने के करीब आते हैं! Uhahaha! हा-हा! हा-हा! उम, सॉरी।

जैसा कि आप जानते हैं, प्रत्येक विजेट के अंदर फ़्लटर संबंधित तत्व बनाता है। जिस तरह फ्लटर एक विजेट ट्री बनाता है, वह एक एलिमेंट ट्री (एलिमेंटट्री) भी बनाता है। ElementTree बेहद सरल है, इसमें प्रत्येक विजेट की केवल प्रकार की जानकारी और बाल तत्वों की एक कड़ी शामिल है। आप एलीमेंटट्री को अपने फ्लटर एप्लिकेशन के कंकाल के रूप में सोच सकते हैं। यह आपके एप्लिकेशन की संरचना को दिखाता है, लेकिन स्रोत विजेट के लिंक पर सभी अतिरिक्त जानकारी मिल सकती है।

उपरोक्त उदाहरण में पंक्ति विजेट में इसके प्रत्येक बच्चे के लिए आदेशित स्लॉट्स का एक सेट है। जब हम रो में रंग विजेट्स को फिर से व्यवस्थित करते हैं, तो फ़्लटर एलीमेंटट्री के चारों ओर घूमता है ताकि यह जांच सके कि अनुप्रयोग का कंकाल संरचना समान है या नहीं।

सत्यापन की शुरुआत एक रोवरमेंट के साथ होती है, और फिर बाल तत्वों पर आगे बढ़ती है। एलीमेंट्री यह जांचता है कि नए विजेट में पुराने के समान ही प्रकार और key , और यदि ऐसा है, तो तत्व नए विजेट के लिए अपने लिंक को अपडेट करता है। कोड के स्टेटलेस संस्करण में, विगेट्स की key नहीं होती है, इसलिए स्पंदन केवल प्रकार की जांच करता है। (यदि एक बार में बहुत अधिक जानकारी है, तो ऊपर दिए गए एनिमेटेड चार्ट को देखें।)

राज्य विजेट के लिए ElementTree के नीचे थोड़ा अलग दिखता है। पहले की तरह ही विगेट्स और एलिमेंट्स हैं, लेकिन विगेट्स के लिए कुछ स्टेट ऑब्जेक्ट्स भी हैं, और कलर इनफॉर्मेशन को स्टोर किया जाता है, न कि खुद विजेट्स में।

key बिना रंगीन StatefulWidget विजेट विजेट के मामले में, जब मैं दो विजेट का क्रम बदलता हूं, तो फ़्लटर एलीमेंटट्री के चारों ओर जाता है, रोवीडगेट के प्रकार की जांच करता है और लिंक को अपडेट करता है। फिर रंग विजेट तत्व जांचता है कि संबंधित विजेट एक ही प्रकार का है और लिंक को अपडेट करता है। दूसरी विजेट के साथ भी यही होता है। चूँकि स्पंदन एलीमेंटट्री और इसकी संगत स्थिति का उपयोग करता है, इसलिए यह निर्धारित करने के लिए कि वास्तव में आपके डिवाइस पर क्या प्रदर्शित होता है, हमारे दृष्टिकोण से, ऐसा लगता है कि विगेट्स स्वैप नहीं किए गए हैं!

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

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

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

मुझे keys उपयोग कब करना चाहिए?

संक्षिप्त उत्तर: यदि आपको एप्लिकेशन में keys जोड़ने की आवश्यकता है, तो आपको उन्हें उस राज्य के साथ विजेट सबट्री के शीर्ष पर जोड़ना चाहिए जिसे आप सहेजना चाहते हैं।

एक सामान्य गलती जो मैंने देखी वह यह है कि लोगों को लगता है कि उन्हें केवल राज्य के साथ पहले विजेट के लिए key को परिभाषित करने की आवश्यकता है, लेकिन बारीकियां हैं। मुझे विश्वास नहीं है? यह दिखाने के लिए कि हम किन परेशानियों में पड़ सकते हैं, मैंने अपने रंग विजेट्स को Padding विजेट्स में लपेट दिया, जबकि कलर विजेट्स की कुंजी छोड़ दी।

 void main() => runApp(new MaterialApp(home: PositionedTiles())); class PositionedTiles extends StatefulWidget { @override State<StatefulWidget> createState() => PositionedTilesState(); } class PositionedTilesState extends State<PositionedTiles> { // Stateful tiles now wrapped in padding (a stateless widget) to increase height // of widget tree and show why keys are needed at the Padding level. List<Widget> tiles = [ Padding( padding: const EdgeInsets.all(8.0), child: StatefulColorfulTile(key: UniqueKey()), ), Padding( padding: const EdgeInsets.all(8.0), child: StatefulColorfulTile(key: UniqueKey()), ), ]; @override Widget build(BuildContext context) { return Scaffold( body: Row(children: tiles), floatingActionButton: FloatingActionButton( child: Icon(Icons.sentiment_very_satisfied), onPressed: swapTiles), ); } swapTiles() { setState(() { tiles.insert(1, tiles.removeAt(0)); }); } } class StatefulColorfulTile extends StatefulWidget { StatefulColorfulTile({Key key}) : super(key: key); @override ColorfulTileState createState() => ColorfulTileState(); } class ColorfulTileState extends State<ColorfulTile> { Color myColor; @override void initState() { super.initState(); myColor = UniqueColorGenerator.getColor(); } @override Widget build(BuildContext context) { return Container( color: myColor, child: Padding( padding: EdgeInsets.all(70.0), )); } } 

अब, एक बटन के स्पर्श में, विगेट्स पूरी तरह से यादृच्छिक रंग प्राप्त करते हैं!

यह कैसे विजेट पेड़ और ElementTree जोड़ा Padding विगेट्स के साथ देखो:

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

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

चूँकि वह इसी key साथ इस स्तर पर रंग विजेट तत्व नहीं खोज सकता है, वह एक नया बनाता है और इस स्थिति में विजेट नारंगी बनाता है, एक नई स्थिति को इनिशियलाइज़ करता है!

यदि हम Padding विगेट्स के लिए keys परिभाषित करते हैं:

 void main() => runApp(new MaterialApp(home: PositionedTiles())); class PositionedTiles extends StatefulWidget { @override State<StatefulWidget> createState() => PositionedTilesState(); } class PositionedTilesState extends State<PositionedTiles> { List<Widget> tiles = [ Padding( // Place the keys at the *top* of the tree of the items in the collection. key: UniqueKey(), padding: const EdgeInsets.all(8.0), child: StatefulColorfulTile(), ), Padding( key: UniqueKey(), padding: const EdgeInsets.all(8.0), child: StatefulColorfulTile(), ), ]; @override Widget build(BuildContext context) { return Scaffold( body: Row(children: tiles), floatingActionButton: FloatingActionButton( child: Icon(Icons.sentiment_very_satisfied), onPressed: swapTiles), ); } swapTiles() { setState(() { tiles.insert(1, tiles.removeAt(0)); }); } } class StatefulColorfulTile extends StatefulWidget { StatefulColorfulTile({Key key}) : super(key: key); @override ColorfulTileState createState() => ColorfulTileState(); } class ColorfulTileState extends State<ColorfulTile> { Color myColor; @override void initState() { super.initState(); myColor = UniqueColorGenerator.getColor(); } @override Widget build(BuildContext context) { return Container( color: myColor, child: Padding( padding: EdgeInsets.all(70.0), )); } } 

स्पंदन समस्या को नोटिस करता है और लिंक को सही ढंग से अपडेट करता है, जैसा कि यह हमारे पिछले उदाहरण में था। ब्रह्मांड में क्रम बहाल है।

मुझे किस प्रकार की Key उपयोग करना चाहिए?

स्पंदन एपीआई ने हमें कई Key वर्गों का विकल्प दिया। आपको किस प्रकार की key उपयोग करना चाहिए, यह इस बात पर निर्भर करता है कि उन तत्वों की विशिष्ट विशेषता क्या है जिन्हें keys आवश्यकता keys । उस जानकारी को देखें जिसे आप संबंधित विजेट में संग्रहीत करते हैं।

निम्नलिखित टू-डू एप्लिकेशन [1] पर विचार करें, जहां आप प्राथमिकता के आधार पर कार्य सूची में आइटम के क्रम को बदल सकते हैं, और जब किया जाता है, तो आप उन्हें हटा सकते हैं।

ValueKey
इस मामले में, हम उम्मीद कर सकते हैं कि कार्यान्वयन पर पैराग्राफ का पाठ स्थायी और अद्वितीय होगा। यदि ऐसा है, तो यह संभवतः ValueKey लिए एक अच्छा उम्मीदवार है, जहां पाठ "मूल्य" है।

 return TodoItem( key: ValueKey(todo.task), todo: todo, onDismissed: (direction) => _removeTodo(context, todo), ); 

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

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

हालांकि, एक चीज जिसे आप उपयोग नहीं करना चाहते हैं, वह है कि आपकी key एक यादृच्छिक संख्या है। हर बार जब एक विजेट बनाया जाता है, तो एक नया यादृच्छिक नंबर उत्पन्न होगा और आप फ़्रेम के बीच स्थिरता खो देंगे। इस परिदृश्य में, आप keys उपयोग नहीं कर सकते हैं!

PageStorageKeys
PageStorageKeys विशेष keys जिनमें स्क्रॉल की वर्तमान स्थिति होती है ताकि एप्लिकेशन इसे बाद में उपयोग के लिए सहेज सके।

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

अक्सर (लेकिन हमेशा नहीं!) GlobalKeys वैश्विक चरों की तरह GlobalKeys सा होता है। अक्सर उन्हें InheritedWidgets या Redux, या BLoC टेम्पलेट जैसी किसी चीज़ से बदला जा सकता है।

संक्षिप्त निष्कर्ष

सामान्य तौर पर, Keys उपयोग करें यदि आप विजेट उपप्रकारों के बीच स्थिति बनाए रखना चाहते हैं। यह सबसे अधिक बार होता है जब आप एक ही प्रकार के विजेट का संग्रह बदलते हैं। विजेट सबट्री के शीर्ष पर key रखें जिसे आप सहेजना चाहते हैं, और विजेट में संग्रहीत डेटा के आधार पर key प्रकार का चयन करें।

बधाई हो, अब आप फ्लटर मैज बनने की राह पर हैं! अरे मैंने एक जादूगर कहा? मेरा मतलब जादूगर [2] की तरह है, जो एप्लिकेशन सोर्स कोड लिखता है ... जो लगभग उतना ही अच्छा है। ... लगभग।

[१] To-do एप्लीकेशन कोड लिखने की प्रेरणा यहाँ प्राप्त हुई
https://github.com/brianegan/flutter_architecture_samples/tree/master/vanilla
[२] लेखक शब्द sorcerer का उपयोग करता sorcerer और बाद में इसमें एक अतिरिक्त पत्र sourcerer करने से पहले sourcerer