ओम-यम-यम और डेटा सत्यापन

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

• एप्लिकेशन का क्लाइंट हिस्सा एपीआई से डेटा प्राप्त करता है और इसे सत्यापित करता है। सबसे पहले, एपीआई अचानक और कभी-कभी बिना नोटिस बदल सकता है, और दूसरी बात, "सर्वर लोग" खुद कभी-कभी यह नहीं जानते हैं कि उनका एपीआई क्या कर सकता है, उदाहरण के लिए, किसी क्षेत्र में, गारंटीकृत सरणी के बजाय, भले ही खाली हो, पूर्णिमा हो सकती है। null दिया जाए। क्लाइंट पर डेटा का वर्णन करते समय, प्रोग्रामर यह निर्धारित करने लगते हैं कि क्लाइंट को पता है कि कैसे काम करना है और अगर कुछ गलत हो जाता है, तो समस्या के स्रोत के बारे में कंसोल में एक संदेश को तुरंत देखने के बजाय यह एक सुखद बात है कि एक असंगत बग को पहले से ही उठा लिया जाए जहां यह व्यू लेयर में बाहर हो गया है। (और यह तुरंत देखा जाए तो अच्छा है) इसके अलावा अब पहले से ही समाधान ( 1 , 2 ) हैं जो सर्वर से क्लाइंट तक प्रकारों को स्थानांतरित करने की अनुमति देते हैं। मैंने अभी तक ऐसा करने की कोशिश नहीं की है, लेकिन यह बहुत संभव है कि यह भविष्य है।
• रिवर्स स्थिति तब होती है जब सर्वर अपेक्षित मापदंडों को पूरा नहीं करने पर अनुरोध को संसाधित करने से रोकने के लिए भेजे गए मापदंडों की तुरंत जाँच करता है। मुझे लगता है कि ऐसा करने के लिए कोई विवरण की आवश्यकता नहीं है कि ऐसा करना क्यों महत्वपूर्ण है।
• डेटाबेस में इसे संग्रहीत करने से पहले डेटा का सत्यापन भी शानदार नहीं होगा। उदाहरण के लिए, आप देख सकते हैं कि यह मेरी एक बाइक में कैसे व्यवस्थित है: MaraquiaORM # मान्यता ।

मुझे लगता है कि उदाहरण काफी ठोस हैं और अब ऐसा कोई एहसास नहीं है कि आप सरल नियमित रूप से कर सकते हैं, क्योंकि यह केवल उपयोगकर्ता इनपुट के बारे में नहीं है, बल्कि जटिल के सत्यापन के बारे में है, जो आमतौर पर डेटा के कई स्तरों पर निहित है। यहां पहले से ही एक विशेष पुस्तकालय की आवश्यकता है। और निश्चित रूप से कर रहे हैं! यह सिर्फ इतना होता है कि पिछले 10 वर्षों में, हर बार जब मैं एक नई परियोजना शुरू करता हूं, तो मैं इसमें एक और ऐसे पुस्तकालय का उपयोग करने की कोशिश करता हूं, जो इसे मेरी आवश्यकताओं के अनुरूप समायोजित करता है। और हर बार कुछ गलत हो जाता है, जो कभी-कभी सक्रिय विकास के बीच में परीक्षण विषय के प्रतिस्थापन की ओर जाता है। मैं उन सभी विकल्पों के बारे में बात नहीं करूंगा, जिनका मैंने अध्ययन किया था, मैं केवल वर्तमान परियोजना में परीक्षण किए गए लोगों के बारे में कहूंगा।

प्रकार की जांच

Github

छोटा और काफी सुविधाजनक पुस्तकालय। सर्किट को एक स्ट्रिंग के रूप में वर्णित किया गया है। मल्टी-लाइन स्ट्रिंग्स का उपयोग करके, आप काफी जटिल संरचनाओं का वर्णन कर सकते हैं:

 `{ ID: String, creator: { fname: String | Null, mname: String | Null, lname: String | Null, email: [String] } | Undefined, sender: Maybe { name: String, email: String }, type: Number, subject: String, ... }` 

काफी गंभीर कमियां हैं:

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

जॉय

Github
ब्राउज़र संस्करण: जॉय-ब्राउज़र

संभवतः इस विषय पर सबसे प्रसिद्ध पुस्तकालय सुविधाओं का एक गुच्छा और एक अंतहीन एपीआई के साथ है। पहले तो मैंने इसे सर्वर पर इस्तेमाल किया और इसने खुद को पूरी तरह से दिखाया। कुछ बिंदु पर, मैंने इसे क्लाइंट पर type-check से बदलने का फैसला किया। उस समय, मैंने लगभग बंडल के आकार को नियंत्रित नहीं किया था, बस इसके साथ कोई समस्या नहीं थी। लेकिन साल भर में यह तेजी से बढ़ा है और मोबाइल इंटरनेट पर पहले एप्लिकेशन डाउनलोड बिल्कुल भी सहज नहीं था। घटकों के एक आलसी लोडिंग को व्यवस्थित करने का निर्णय लिया गया। वेबपैक-बंडल-एनालाइजर रिपोर्ट में बंडल में दिग्गजों का एक समूह दिखाई दिया और वे सभी आसानी से वेबपैक द्वारा बनाई गई विखंडू में चले गए। Joi को छोड़कर सभी। कई घटक सर्वर के साथ संवाद करते हैं और सभी सर्वर प्रतिक्रियाओं को मान्य किया जाता है, अर्थात, Joi को किसी प्रकार के चंक में डालने से कोई मतलब नहीं है, यह बस मुख्य एक के बाद हमेशा सही लोड करेगा। कुछ बिंदु पर, मुख्य बंडल इस तरह दिखता था: tyts । बेशक, एक स्थायी इच्छा इसके बारे में कुछ करने के लिए उठी। मैं एक ही सुविधाजनक पुस्तकालय चाहता था, लेकिन बहुत कम।

हाँ

Github

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

• डिफ़ॉल्ट लाइब्रेरी सभी undefined । लगातार लेखन .required() बहुत सुखद नहीं है, और मुझे यह अच्छा लगता है जब शुरू में सब कुछ असंभव है और जहां इसकी अनुमति है। Joi का एक विकल्प है presence: 'required' इस व्यवहार को कॉन्फ़िगर presence: 'required' लिए presence: 'required' । मैंने नारकीय संख्या 666 के साथ एक अनुरोध बनाया, लेकिन अभी तक लेखक चुप हैं।
• किसी वस्तु के मूल्यों की जांच करने का कोई तरीका नहीं है, जिससे सभी कुंजियों की अनुमति मिलती है। Joi लिए ऑब्जेक्ट का उपयोग करता है। किसी भी स्ट्रिंग को स्वीकार करने वाले पहले तर्क के साथ। शायद यहाँ अभी भी किसी तरह बाहर निकलना संभव होगा, और लेखक पहले माइनस को सही कर सकते हैं, लेकिन आकार को देखते हुए, मैं खुद कुछ इंतजार या संपादित नहीं करना चाहता था।

ow

Github

अगला आवेदक आखिरकार छोटा हो गया, साथ ही उसने उसे लगातार नहीं लिखा () जहाँ आप इसके बिना कर सकते हैं। उदाहरण के लिए, आप एक सत्यापनकर्ता लिख ​​सकते हैं जो एक स्ट्रिंग या undefined अनुमति देता है:

 let optionalStringValidator = ow.optional.string; ow(optionalStringValidator, '1'); // Ok ow(optionalStringValidator, undefined); // Ok 

बहुत बढ़िया! null बारे में क्या? सभी दस्तावेजों को पलटते हुए, मुझे निम्नलिखित विधि मिली:

 ow.any(ow.optional.string, ow.null); 

अरे डरपोक! जब मैंने परियोजना में सत्यापन के हिस्से को फिर से लिखने की कोशिश की, तो मैंने इसे टाइप करते समय अपनी उंगलियां तोड़ दीं। मैंने ow.nullable को जोड़ने पर ow.nullable मुद्दा ow.nullable , जिसे यहां भेजा गया था। संक्षेप में, वे कहते हैं कि null की आवश्यकता नहीं है। वहाँ दी गई दलीलें भी काफी हद तक उनके बारे में पहली पंक्ति में दी गई हैं:

मनुष्यों के लिए फ़ंक्शन तर्क सत्यापन

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

इधर-उधर, मैं पहले ही हार मान कर पूरी तरह से थक चुका था और अपनी लाइब्रेरी को ब्लैकजैक और वर्जिन के साथ लिखने का फैसला किया। हां, हां, मैं अगली बाइक के साथ आपके पास वापस आ गया हूं :)। मिलना

OmYumYum

कुछ उदाहरण:

 import om from 'omyumyum'; const isOptionalNumber = om.number.or.undefined; isOptionalNumber('1'); // => false isOptionalNumber(1); // => true isOptionalNumber(undefined); // => true 

.or रूप में संभव विकल्पों को बढ़ाकर आप जितनी बार चाहें उपयोग कर सकते हैं:

 om.number.or.string.or.null.or.undefined; 

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

 om(om.number, '1'); //  TypeError 

या करी के साथ:

 const isNumberOrThrow = om(om.number); isNumberOrThrow('1') //  TypeError 

परिणामी फ़ंक्शन काफी सामान्य नहीं है, क्योंकि इसमें अतिरिक्त तरीके हैं। .or पहले .or ही दिखाया गया है, तरीकों का हिस्सा चयनित प्रकार ( एपीआई देखें) पर निर्भर करेगा, उदाहरण के लिए, एक स्ट्रिंग को एक नियमित अभिव्यक्ति के साथ बढ़ाया जा सकता है:

 const isNonEmptyString = om.string.pattern(/\S/); // == `om.string.nonEmpty` isNonEmptyString(' '); // => false isNonEmptyString('1'); // => true 

और ऑब्जेक्ट के लिए, आप इसका आकार निर्दिष्ट कर सकते हैं:

 const isUserData = om.object.shape({ name: om.string, age: om.number.or.vacuum // `.or.vacuum` == `.or.null.or.undefined` }); isUserData({}); // => false isUserData({ age: 20 }) // => false isUserData({ name: '' }); // => true isUserData({ name: '', age: null }); // => true isUserData({ name: '', age: 20 }); // => true 

समस्या की जगह के लिए वादा किया गया कीपैड:

 om(om.array.of(om.object.shape({ name: om.string })), [{ name: '' }, { name: null }]); //  TypeError('Type mismatch at "[1].name"') 

यदि अंतर्निहित विशेषताएं पर्याप्त नहीं हैं, तो आप हमेशा उपयोग कर सकते हैं। .custom(validator: (value: any) => boolean) :

 const isEmailOrPhone = om.custom(require('is-email')).or.custom(require('is-phone')); isEmailOrPhone('test@test.test'); // => true 

स्टॉक में भी अपेक्षित है .and और प्रकारों के संयोजन और सुधार के लिए उपयोग किया जाता है:

 const isNonZeroString = om.string.and.custom(str => str.length > 0); // == `om.string.nonZero` isNonZeroString(''); // => false isNonZeroString('1'); // => true 

.custom() पर पूर्ववर्तीता को लागू किया जाता है .and लेकिन, .custom() लाइब्रेरी द्वारा बनाए गए ठीक उसी रूप के सत्यापनकर्ता को स्वीकार करता है, इसे दरकिनार किया जा सकता है:

 //      `age`,   `birthday` om.object.shape({ name: om.string }).and.custom( om.object.shape({ age: om.number }) .or.object.shape({ birthday: om.date })] ); 

आप पहले से बनाए गए सत्यापनकर्ताओं में सुधार जारी रख सकते हैं। पुराने वाले कभी खराब नहीं होते। आइए पहले बनाए गए isUserData को बेहतर बनाने का प्रयास करें:

 const isImprovedUserData = isUserData.and.object.shape({ friends: om.array.of(isUserData).or.vacuum }); isImprovedUserData({ name: '', age: 20, friends: [{ name: '', age: 18 }] }); // => true 

खैर, रुके .not ।

 const isNotVacuum = om.not.null.and.not.undefined; // == `om.not.vacuum` isNotVacuum(1); // => true isNotVacuum(null); // => false isNotVacuum(undefined); // => false 

अन्य उपलब्ध तरीकों को पुस्तकालय एपीआई में पाया जा सकता है ।

पुस्तकालय के लाभ:

• .Or, .not , .not और कोष्ठक की एक न्यूनतम के साथ लैकोनिक सिंटैक्स। स्वत: पूर्ण टाइप के साथ संयोजन में, सेट एक खुशी में बदल जाता है।
• Ow की तुलना में बहुत कम वजन (लगभग 10 गुना कम (मिनिफाई + गज़िप)), और Joi की तुलना में Joi पुस्तकालय एक पहाड़ के बगल में एक पंख की तरह है।
• अच्छा नाम :)

पुस्तकालय के विपक्ष:

• कुछ प्रकार और उनके संशोधक। और यह संभावना नहीं है कि बहुत अधिक होगा। लेख की शुरुआत में दिए गए सभी तीन उपयोग परिदृश्य (जंक्शनों और कोड आधारों के बारे में कुछ) सादे पाठ डेटा के हस्तांतरण को मानते हैं, ज्यादातर मामलों में यह JSON है। अर्थात्, मेरी राय में, इस तरह के पुस्तकालय को JSON में संभव प्रकारों का समर्थन करना चाहिए, साथ ही undefined और कुछ आमतौर पर उपयोग किए जाने वाले प्रकारों का भी समर्थन करना चाहिए। एक ही Ow किसी कारण से, टाइप किए गए सरणियों और अन्य बकवास के लिए समर्थन के साथ crammed है। मुझे लगता है कि यह शानदार है।
• Joi जैसे डेटा को परिवर्तित नहीं कर सकते। मुझे लगता है कि Joi उस पर बहुत बुरा है। कम से कम मेरे पास इसकी पर्याप्त क्षमताएं नहीं हैं, और यदि आवश्यक हो, तो मैं पूरी तरह से विभिन्न उपकरणों के साथ रूपांतरण करता हूं। शायद यह omyumyum लिए एक और विकास की दिशा है।

वह सब है! अगर आपको लेख पसंद आया, तो इसे लाइक करें, चैनल को सब्सक्राइब करें और शुभकामनाएँ))।