मेरी रेक: लत्ता से धन के लिए

प्रागितिहास

मैं अब एक साल के लिए फ्रंट-एंड डेवलपर के रूप में काम कर रहा हूं। मेरा पहला प्रोजेक्ट "दुश्मन" बैकएंड था। ऐसा होता है कि संचार स्थापित होने पर यह कोई बड़ी समस्या नहीं है।

लेकिन हमारे मामले में ऐसा नहीं था।

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

हमने महसूस किया कि हमें यह जांचने की जरूरत है कि जो डेटा हमें भेजा गया है, उस पर भरोसा करने से पहले बैकएंड क्या देता है। हमने सामने के छोर से डेटा सत्यापन के मुद्दे पर अनुसंधान के लिए एक कार्य बनाया।

यह अध्ययन मुझे कमीशन दिया गया था।

मैंने उस उपकरण की सूची बनाई है जो मैं उस उपकरण में होना चाहता हूं जिसे मैं डेटा सत्यापन के लिए उपयोग करना चाहता हूं।

सबसे महत्वपूर्ण चयन बिंदु निम्नलिखित बिंदु थे:

• सत्यापन का घोषणात्मक विवरण (योजना), जो एक सत्यापनकर्ता फ़ंक्शन में बदल जाता है जो सही / गलत (वैध, वैध नहीं) लौटाता है
• कम प्रवेश दहलीज;
• सत्यापन के विवरण के साथ वैध डेटा की समानता;
• कस्टम मान्यताओं के एकीकरण में आसानी;
• कस्टम त्रुटि संदेशों के एकीकरण में आसानी।

परिणामस्वरूप, मुझे कई सत्यापन लाइब्रेरी मिलीं, जिनमें TOP-5 (ajv, joi, roi ...) की समीक्षा की गई। वे सभी बहुत अच्छे हैं। लेकिन यह मुझे प्रतीत हुआ कि 5% जटिल मामलों को हल करने के लिए - उन्होंने 95% सबसे सामान्य मामलों को बल्कि क्रिया और भारी होने के लिए बर्बाद किया।

इसलिए, मैंने सोचा: क्यों न खुद कुछ विकसित किया जाए जो मेरे अनुकूल हो।
चार महीने बाद, मेरी चौकड़ी मान्यता पुस्तकालय का सातवां संस्करण सामने आया।
यह एक स्थिर संस्करण था, पूरी तरह से परीक्षण किया गया, nk पर 11k डाउनलोड। हमने तीन महीने के लिए एक अभियान में तीन परियोजनाओं पर इसका इस्तेमाल किया।

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

लेकिन खामियों की भी पहचान की गई।

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

वास्तु रेक

"स्ट्रोको" - योजना की एक टाइप की गई भाषा

मैं व्यक्ति के ऑब्जेक्ट के लिए योजना के पुराने संस्करण का एक उदाहरण दूंगा।

const personSchema = { name: 'string', age: 'number', linkedin: ['string', 'null'] } 

यह योजना तीन गुणों के साथ एक ऑब्जेक्ट को मान्य करती है: नाम - एक स्ट्रिंग, उम्र होनी चाहिए - एक संख्या होनी चाहिए, लिंक्डइन में एक खाते से लिंक होना चाहिए - या तो शून्य होना चाहिए (यदि कोई खाता नहीं है) या स्ट्रिंग (यदि कोई खाता है)।

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

 type Person = { name: string age: number linkedin: string | null } 

(जैसा कि आप देख सकते हैं - परिवर्तन अधिक संभावना कॉस्मेटिक हैं)

जब मैंने एक निर्णय लिया, तो सबसे अधिक सत्यापन विकल्पों के लिए क्या उपयोग किया जाना चाहिए (उदाहरण के लिए, ऊपर उपयोग किए गए)। मैंने उपयोग करने के लिए चुना - तार, जैसा कि यह था, सत्यापनकर्ताओं के नाम।

लेकिन तार के साथ समस्या यह है कि वे संकलक या त्रुटि विश्लेषक के लिए उपलब्ध नहीं हैं। उनके लिए स्ट्रिंग 'संख्या' 'संख्या' से बहुत अलग नहीं है।

निर्णय

चौकड़ी का नया संस्करण 8.0.0। मैंने चौकड़ी से दूर करने का फैसला किया - योजना के अंदर सत्यापनकर्ताओं के नाम के रूप में तार का उपयोग।

आरेख अब इस तरह दिखता है:

 const personSchema = { name: v.string age: v.number, linkedin: [v.string, null] } 

इस बदलाव के दो बड़े फायदे हैं:

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

टाइपस्क्रिप्ट समर्थन करते हैं

सामान्य तौर पर, पहले सात संस्करण शुद्ध जावास्क्रिप्ट में विकसित किए गए थे। टाइपस्क्रिप्ट के साथ एक परियोजना पर स्विच करते समय, इसके लिए किसी तरह पुस्तकालय को अनुकूलित करने की आवश्यकता थी। इसलिए, लाइब्रेरी के लिए टाइप घोषणाएँ लिखी गईं।

लेकिन यह एक माइनस था - कार्यक्षमता जोड़ते समय, या लाइब्रेरी के कुछ तत्वों को बदलते समय, हमेशा प्रकार की घोषणाओं को अपडेट करना भूल जाना आसान था।

इस तरह की छोटी-मोटी असुविधाएँ भी थीं:

 const checkPerson = v(personSchema) // (0) // ... const person: any = await axios.get('https://myapi.com/person/42') if (!checkPerson(person)) {// (1) throw new TypeError('Invalid person response') } console.log(person.name) // (2) 

जब हमने लाइन (0) पर ऑब्जेक्ट वैलिडेटर बनाया। हम लाइन (1) पर बैकएंड से वास्तविक उत्तर की जांच करने और त्रुटि को संभालने के बाद चाहेंगे। ऑन लाइन (2) ताकि person प्रकार का व्यक्ति हो। लेकिन ऐसा हुआ नहीं। दुर्भाग्य से, ऐसा चेक एक प्रकार का गार्ड नहीं था।

निर्णय

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

एक उदाहरण इस तरह दिखता है:

 const checkPerson = v<Person>(personSchema) // (0) // ... const person: any = await axios.get('https://myapi.com/person/42') if (!checkPerson(person)) {// (1) throw new TypeError('Invalid person response') } console.log(person.name) // (2) 

अब ऑन लाइन (2) person टाइप Person ।

पठनीयता

ऐसे दो मामले भी थे जहां कोड को खराब तरीके से पढ़ा गया था: मूल्यों के एक निश्चित सेट के अनुपालन की जाँच करना (एनम की जाँच करना) और वस्तु के अन्य गुणों की जाँच करना।

a) एनाम की जाँच करें
शुरू में, एक विचार था, मेरी राय में एक अच्छा। हम अपनी वस्तु में फ़ील्ड "लिंग" जोड़कर इसका प्रदर्शन करेंगे।
सर्किट का पुराना संस्करण इस तरह दिखता था:

 const personSchema = { name: 'string', age: 'number', linkedin: ['null', 'string'], sex: v.enum('male', 'female') } 

विकल्प बहुत पठनीय है। लेकिन हमेशा की तरह, सब कुछ एक छोटे से योजना से चला गया।
उदाहरण के लिए, इस कार्यक्रम में घोषित एनम होने के बाद:

 enum Sex { Male = 'male', Female = 'female' } 

स्वाभाविक रूप से मैं इसे सर्किट के अंदर उपयोग करना चाहता हूं। ताकि मूल्यों में से एक को बदलने पर (उदाहरण के लिए, 'पुरुष' -> 'एम', 'महिला' -> 'एफ'), सत्यापन योजना भी बदल जाए।

इसलिए, लगभग हमेशा enum सत्यापन इस तरह लिखा गया था:

 const personSchema = { name: 'string', age: 'number', linkedin: ['null', 'string'], sex: v.enum(...Object.values(Sex)) } 

जो देखने में काफी भद्दा लगता है।

b) वस्तु के अवशिष्ट गुणों का सत्यापन

मान लीजिए कि हम अपनी वस्तु में ऐसी विशेषता जोड़ते हैं - इसके अतिरिक्त क्षेत्र हो सकते हैं, लेकिन उनमें से सभी को सामाजिक नेटवर्क से लिंक होना चाहिए - इसका मतलब है कि उन्हें या तो null होना चाहिए या एक स्ट्रिंग।

पुरानी योजना इस तरह दिखेगी:

 const personSchema = { name: 'string', age: 'number', linkedin: ['null', 'string'], sex: v.enum(...Object.values(Sex)), ...v.rest(['null', 'string']) // Rest props are string | null } 

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

निर्णय

जैसा कि ऊपर वर्णित है, तार अब सत्यापन योजनाओं का हिस्सा नहीं हैं। केवल तीन प्रकार के जावास्क्रिप्ट वैल्यूज़ ही वैलिडेशन स्कीम थे। ऑब्जेक्ट - ऑब्जेक्ट की सत्यापन योजना का वर्णन करने के लिए। विवरण के लिए सरणी - वैधता के लिए कई विकल्प। अन्य सभी सत्यापन विकल्पों के लिए फंक्शन (लाइब्रेरी जनरेट या कस्टम) -।

इस प्रावधान ने कार्यक्षमता को जोड़ने की अनुमति दी, जिसने कई बार सर्किट की पठनीयता को बढ़ाने की अनुमति दी।

वास्तव में, अगर हम स्ट्रिंग 'पुरुष' के साथ मूल्य की तुलना करना चाहते हैं। क्या हमें वास्तव में मूल्य और स्ट्रिंग 'पुरुष' के अलावा कुछ और जानने की जरूरत है।

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

अगर हमें समानता-मन के लिए संख्या की जांच करने की आवश्यकता है। फिर हम इसे इस तरह लिखते हैं:

 const check42 = v(42) check42(42) // => true check42(41) // => false check42(43) // => false check42('42') // => false 

आइए देखें कि यह व्यक्ति स्कीमा को कैसे प्रभावित करता है (अतिरिक्त गुणों को ध्यान में रखे बिना):

 const personSchema = { name: v.string, age: v.number, linkedin: [null, v.string], // null is primitive value sex: ['male', 'female'] // 'male', 'female' are primitive values } 

पूर्वनिर्धारित enums का उपयोग करना, हम इसे इस तरह से फिर से लिख सकते हैं:

 const personSchema = { name: v.string, age: v.number, linkedin: [null, v.string], sex: Object.values(Sex) // same as ['male', 'female'] } 

इस मामले में, अनावश्यक विधि को एनम विधि का उपयोग करने और प्रसार ऑपरेटर का उपयोग करके ऑब्जेक्ट से मान्य मानों को इस विधि में पैरामीटर के रूप में निकालने के लिए हटा दिया गया था।

क्या एक आदिम मूल्य माना जाता है: संख्या, तार, वर्ण, true , false , null और undefined ।

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

अवशिष्ट गुणों को मान्य करने के लिए, इसे ऑब्जेक्ट के अन्य सभी क्षेत्रों के लिए एक विशेष संपत्ति का उपयोग करने के लिए चुना गया था:

 const personSchema = { name: v.string, age: v.number, linkedin: [null, v.string], sex: Object.values(Sex), [v.rest]: [null, v.string] } 

इस प्रकार, सर्किट अधिक पठनीय दिखता है। और टाइपस्क्रिप्ट विज्ञापनों की तरह।

सत्यापनकर्ता उस फ़ंक्शन से संबंधित है जिसने इसे बनाया है

पुराने संस्करणों में, त्रुटि स्पष्टीकरण सत्यापनकर्ता का हिस्सा नहीं थे। उन्हें v फंक्शन के अंदर एक अरै में जोड़ा गया।

इससे पहले, सत्यापन त्रुटियों की व्याख्या प्राप्त करने के लिए, आपके पास एक सत्यापनकर्ता होना चाहिए (जाँच करने के लिए) और v (अमान्यता का स्पष्टीकरण प्राप्त करने के लिए)। यह सब इस प्रकार है:

a) हम आरेख में स्पष्टीकरण जोड़ते हैं

 const checkPerson = v({ name: v('string', 'wrong name') age: v('number', 'wrong age'), linkedin: v(['null', 'string'], 'wrong linkedin'), sex: v( v.enum(...Object.values(Sex)), 'wrong sex value' ), ...v.rest( v( ['null', 'string'], 'wrong social networks link' ) ) // Rest props are string | null }) 

सर्किट के किसी भी तत्व के लिए - आप v संकलक फ़ंक्शन के दूसरे तर्क का उपयोग करके त्रुटि का स्पष्टीकरण जोड़ सकते हैं।

बी) स्पष्टीकरण सरणी को साफ़ करें

सत्यापन से पहले, इस वैश्विक सरणी को साफ़ करना आवश्यक था जिसमें सभी स्पष्टीकरण सत्यापन के दौरान दर्ज किए गए थे।

 v.clearContext() // same as v.explanations = [] 

c) मान्य करें

 const isPersonValid = checkPerson(person) 

इस जाँच के दौरान, यदि एक वैधता का पता लगाया गया था, और सर्किट बनाने के चरण में - इसे एक स्पष्टीकरण दिया गया था, इस स्पष्टीकरण को v.explanation Global array में रखा गया है।

घ) त्रुटि से निपटने

 if (!isPersonValid) { throw new TypeError('Invalid person response: ' + v.explanation.join('; ')) } // ex. Throws 'Invalid person response: wrong name; wrong age' 

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

निर्णय

इस समस्या को निम्नानुसार हल किया गया था: स्पष्टीकरण सत्यापन समारोह का हिस्सा बन गया। इसके प्रकार से क्या समझा जा सकता है:
प्रकार सत्यापनकर्ता = (मूल्य: कोई भी, स्पष्टीकरण ?: कोई []) => बूलियन

अब यदि आपको त्रुटि के स्पष्टीकरण की आवश्यकता है, तो आप उस सरणी को पास करते हैं जिसमें आप स्पष्टीकरण जोड़ना चाहते हैं।

इस प्रकार, सत्यापनकर्ता एक स्वतंत्र इकाई बन जाता है। एक ऐसा तरीका भी जोड़ा गया है जो वैल्यू के वैल्यू वैलिड होने पर एक फंक्शन को वैल्यूएशन फंक्शन में बदल सकता है, और वैल्यू वैलिड न होने पर एक्सप्लेनेशन का व्यू देता है।

अब स्पष्टीकरण के साथ सत्यापन इस तरह दिखता है:

 const checkPerson = v<Person>({ name: v(v.string, 'wrong name'), age: v(v.number, 'wrong age'), linkedin: v([null, v.string], 'wrong linkedin') sex: v(Object.values(Sex), 'wrong sex') [v.rest]: v([null, v.string], 'wrong social network') }) // ... const explanations = [] if (!checkPerson(person, explanation)) { throw new TypeError('Wrong person: ' + explanations.join('; ')) } // OR const getExplanation = v.explain(checkPerson) const explanations = getExplanation(person) if (explanations) { throw new TypeError('Wrong person: ' + explanations.join('; ')) } 

अंतभाषण

मैंने तीन परिसरों पर प्रकाश डाला जिसकी वजह से मुझे सब कुछ फिर से लिखना पड़ा:

• उम्मीद है कि लोग लाइनों को लिखते समय गलत नहीं हैं
• वैश्विक चर का उपयोग करना (इस मामले में, v.explanation array)
• विकास के दौरान छोटे उदाहरणों के साथ परीक्षण - वास्तविक बड़े मामलों में उपयोग किए जाने पर उत्पन्न होने वाली समस्याओं को नहीं दिखाता था।

लेकिन मुझे खुशी है कि मैंने इन समस्याओं का विश्लेषण किया, और जारी किया गया संस्करण पहले से ही हमारी परियोजना में उपयोग किया जाता है। और मुझे आशा है कि यह हमारे लिए उपयोगी होगा जो पिछले एक से कम नहीं है।

आप सभी को पढ़ने के लिए धन्यवाद, मुझे उम्मीद है कि मेरा अनुभव आपके लिए उपयोगी होगा।