हम फ़्लो एरर सप्रेशन में सुधार कर रहे हैं ताकि वे गलती से न हों।

आने वाले वर्ष में, फ्लो अपने प्रकार प्रणाली में कई बदलाव और सुधार करने की योजना बना रहा है । हालाँकि, इसका एक परिणाम यह है कि आपको अपने कोड में और अधिक दमन करने की आवश्यकता हो सकती है क्योंकि मौजूदा मुद्दों को खोजने में फ़्लो बेहतर हो जाता है।

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

यह सब समझने का क्या मतलब है, चलो फ्लो की टाइप त्रुटियों की प्रकृति को खोदें।

एक प्रकार की त्रुटि क्या है?

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

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

function foo(x : number) : void {}
foo("hello");
/* error */
foo("hello");
       ^ Cannot call `foo` with `"hello"` bound to `x` because string [1] is incompatible with number [2].
References:
2: foo("hello");
       ^ [1]
1: function foo(x : number) : void {}
                    ^ [2]

function foo(x : number) : void {}
let y : string = "hello";
foo(y);
/* error */
foo(y);
       ^ Cannot call `foo` with `y` bound to `x` because string [1] is incompatible with number [2].
References:
2: let y : string = "hello";
           ^ [1]
1: function foo(x : number) : void {}
                    ^ [2]

इसलिए दमन में क्या खराबी है?

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

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

// library file lib.js
function foo(x : number) : void {}
// impl file
const {foo} = require("lib.js");
let y : string = "hello";
// $FlowFixMe
foo(y);

हम इस बारे में क्या करने जा रहे हैं?

इसे संबोधित करने के लिए हम निम्नलिखित बदलाव करने जा रहे हैं:

• प्राथमिक स्थानों को लागू करें। हम दमन के व्यवहार को बदल रहे हैं जैसे कि दमन केवल प्राथमिक स्थान पर रखे जाने पर त्रुटियों पर लागू होते हैं। उदाहरण के लिए, आपको फ़ंक्शन की परिभाषा में एक अमान्य कॉल को दबाने की अनुमति देने के बजाय, अब हमें आवश्यकता होगी कि दमन कॉल-साइट पर ही स्थित हो। इस तरह, फ़्लो अभी भी आपको फ़ंक्शन के अन्य संभवतः अमान्य कॉल के बारे में सचेत करने में सक्षम होगा।
• त्रुटि कोड जोड़ें। हम अपने सप्रेशन में त्रुटि कोड भी जोड़ रहे होंगे ताकि वे केवल निर्दिष्ट प्रकार की त्रुटियों को दबाएं। यह दबाने से अप्रत्याशित रूप से एक तरह की त्रुटि को रोक देगा जिससे आप मुठभेड़ की उम्मीद नहीं कर रहे थे।
• दमन सिंटैक्स को मानकीकृत करें। पहले एक त्रुटि दमन के लिए स्वीकार्य वाक्यविन्यास को किसी .flowconfigदिए गए प्रोजेक्ट के लिए मैन्युअल रूप से कॉन्फ़िगर किया जा सकता है , जिससे परियोजनाओं में असंगत दमन सिंटैक्स की अनुमति मिलती है। उपरोक्त परिवर्तनों के भाग के रूप में हम दमन सिंटैक्स का मानकीकरण भी करेंगे; केवल $FlowFixMe[incompatible-type]या $FlowExpectedError[incompatible-type]स्वरूपों का समर्थन।

रोल आउट

हम मानते हैं कि इस परिवर्तन के कारण आपके कोडबेस में बहुत सी त्रुटियां अमान्य हो सकती हैं, खासकर यदि आप लाइब्रेरी कोड में दमन रखने की आदत में थे। इस बोझ को कम करने के लिए, हमारे पास कुछ सुझाव हैं:

• अपने प्राथमिक स्थानों पर अपने नए अमान्य दमन को स्थानांतरित करने के लिए, हम फ्लो टूल में प्रदान किए गए add-commentsऔर remove-commentsउपयोगिताओं के संयोजन की सलाह देते हैं । रनिंग ./tool remove-commentsकिसी भी टिप्पणी को हटा देगा जो अब एक त्रुटि को दबाती नहीं है क्योंकि वे एक प्राथमिक स्थान पर नहीं हैं, और ./tool add-commentsअनपेक्षित स्थानों पर नए दमन डालेंगे। ./toolस्क्रिप्ट GitHub पर फ्लो भंडार क्लोनिंग द्वारा पहुँचा जा सकता।
• त्रुटि कोड के बिना दबाएं उनके स्थान पर किसी भी और सभी त्रुटियों को दबाने के लिए जारी रहेगा, लेकिन एक बार जब हम त्रुटि कोड सुविधा को रोल आउट कर देते हैं, तो आप उपरोक्त कोड के माध्यम से अपने कोडबेस में उचित कोड जोड़ सकते हैं। अपनी सभी पुरानी टिप्पणियों को हटाने और उन्हें फिर से जोड़ने add-commentsसे नए जोड़े गए टिप्पणी में त्रुटि कोड शामिल होगा।