📌 😖 💀 रेम्बलर समूह का अनुभव: हमने फ्रंट-एंड रिएक्ट घटकों के गठन और व्यवहार को पूरी तरह से कैसे नियंत्रित किया 🍟 👴🏽 🎩

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

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

एक सक्रिय रूप से विकसित वेब उत्पाद में बैकएंड एपीआई के विकास की योजना बनाते समय किस तरह का डेटा विनिमय प्रारूप हम चुन सकते हैं जिसमें संबंधित क्षेत्रों और जटिल व्यावसायिक तर्क के साथ गतिशील रूप शामिल हैं?

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

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

कीड़े की उच्च संभावना;
अक्सर 100% प्रलेखन और परीक्षण कवरेज नहीं;
सॉफ्टवेयर एपीआई की निकटता के कारण निम्न "प्रतिरूपकता"। आमतौर पर, इस तरह के समाधान एक मोनोलिथ के तहत लिखे जाते हैं और घटकों के रूप में परियोजनाओं के बीच साझा नहीं करते हैं, क्योंकि इसके लिए एक विशेष वास्तु निर्माण की आवश्यकता होती है (विकास की लागत पढ़ें);
नए डेवलपर्स के प्रवेश का उच्च स्तर। एक साइकिल की सभी शीतलता को समझने में लंबा समय लग सकता है;

इसलिए, नियम से सामान्य और स्थिर पुस्तकालयों (जैसे npm से बाएं-पैड) का उपयोग करना अच्छा है - सबसे अच्छा कोड वह है जिसे आपने कभी नहीं लिखा है, लेकिन व्यावसायिक समस्या को हल किया है। रामबलर ग्रुप की विज्ञापन तकनीकों में वेब एप्लिकेशन बैकएंड का विकास सिम्फनी में किया जाता है। हम ढांचे के सभी उपयोग किए गए घटकों पर ध्यान केंद्रित नहीं करेंगे, नीचे हम मुख्य भाग के बारे में बात करेंगे, जिसके आधार पर कार्य कार्यान्वित किया जाता है - सिम्फनी रूप । फ्रंट रिएक्ट और संबंधित लाइब्रेरी का उपयोग करता है जो WEB बारीकियों के लिए JSON स्कीमा का विस्तार करता है - प्रतिक्रिया JSON स्कीमा फॉर्म ।

काम की सामान्य योजना:

इस दृष्टिकोण के कई फायदे हैं:

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

आइए घटकों और उनकी बातचीत की योजना को और अधिक विस्तार से देखें।

प्रारंभ में, JSON स्कीमा आपको क्लाइंट पर की जाने वाली आदिम जांचों का वर्णन करने की अनुमति देती है, जैसे कि योजना के विभिन्न भागों को बांधना या टाइप करना:

const schema = { "title": "A registration form", "description": "A simple form example.", "type": "object", "required": [ "firstName", "lastName" ], "properties": { "firstName": { "type": "string", "title": "First name" }, "lastName": { "type": "string", "title": "Last name" }, "password": { "type": "string", "title": "Password", "minLength": 3 }, "telephone": { "type": "string", "title": "Telephone", "minLength": 10 } } }

फ्रंट-एंड योजनाओं के साथ काम करने के लिए, लोकप्रिय रिएक्शन JSON स्कीमा फॉर्म लाइब्रेरी है जो वेब विकास के लिए JSON स्कीमा के लिए आवश्यक ऐड-ऑन प्रदान करती है:

uiSchema - JSON स्कीमा स्वयं पास करने के लिए मापदंडों के प्रकार को निर्धारित करती है, लेकिन यह वेब एप्लिकेशन बनाने के लिए पर्याप्त नहीं है। उदाहरण के लिए, स्ट्रिंग के एक क्षेत्र को <input ... /> या <textarea ... /> के रूप में दर्शाया जा सकता है, ये महत्वपूर्ण बारीकियां हैं, इस बात को ध्यान में रखते हुए जिसे आपको क्लाइंट के लिए सही ढंग से चित्र बनाने की आवश्यकता है। UiSchema इन बारीकियों को भी बताने का काम करता है, उदाहरण के लिए, ऊपर प्रस्तुत JSON स्कीमा के लिए, आप निम्न uiSchema के विज़ुअल वेब घटक को निर्दिष्ट कर सकते हैं:

 const uiSchema = { "firstName": { "ui:autofocus": true, "ui:emptyValue": "" }, "age": { "ui:widget": "updown", "ui:title": "Age of person", "ui:description": "(earthian year)" }, "bio": { "ui:widget": "textarea" }, "password": { "ui:widget": "password", "ui:help": "Hint: Make it strong!" }, "date": { "ui:widget": "alt-datetime" }, "telephone": { "ui:options": { "inputType": "tel" } } }

लाइव प्लेग्राउंड का उदाहरण यहां देखा जा सकता है ।

योजना के इस उपयोग के साथ, फ्रंट-एंड रेंडरिंग को मानक बूटस्ट्रैप घटकों द्वारा कई लाइनों में लागू किया जाएगा:

 render(( <Form schema={schema} uiSchema={uiSchema} /> ), document.getElementById("app"));

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

फॉर्मडेटा - में फॉर्म डेटा है, उदाहरण के लिए:

 { "firstName": "Chuck", "lastName": "Norris", "age": 78, "bio": "Roundhouse kicking asses since 1940", "password": "noneed" }

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

आप प्लगइन पृष्ठ पर ऊपर वर्णित अनुभागों को स्थापित करने और उपयोग करने की सभी बारीकियों के बारे में अधिक पढ़ सकते हैं।

बॉक्स से बाहर, पुस्तकालय आपको केवल इन तीन वर्गों के साथ काम करने की अनुमति देता है, लेकिन एक पूर्ण वेब अनुप्रयोग के लिए, आपको कई सुविधाएँ जोड़ने की आवश्यकता है:

त्रुटियां - उपयोगकर्ता को प्रदान करने के लिए विभिन्न बैकएंड चेक की त्रुटियों को स्थानांतरित करने में सक्षम होना भी आवश्यक है, और त्रुटियां या तो सरल सत्यापन वाले हो सकते हैं - उदाहरण के लिए, उपयोगकर्ता को पंजीकृत करते समय लॉगिन की विशिष्टता, या व्यावसायिक तर्क के आधार पर अधिक जटिल वाले - अर्थात। हमें उनकी (त्रुटियों) संख्या और प्रदर्शित सूचनाओं के ग्रंथों को अनुकूलित करने में सक्षम होना चाहिए। ऐसा करने के लिए, ऊपर वर्णित लोगों के अलावा, त्रुटियां अनुभाग डेटा सेट में जोड़ा गया था - प्रत्येक क्षेत्र के लिए, रेंडरिंग के लिए त्रुटियों की एक सूची यहां परिभाषित की गई है

क्रिया , विधि - बैकएंड के लिए उपयोगकर्ता द्वारा तैयार किए गए डेटा भेजने के लिए, दो विशेषताओं को जोड़ा गया था, जिसमें प्रसंस्करण और HTTP वितरण पद्धति का प्रदर्शन करने वाले नियंत्रक के बैकएंड का URL था।

परिणामस्वरूप, आगे और पीछे के बीच संचार के लिए, हमें निम्नलिखित अनुभागों के साथ json मिला:

 { "action": "https://...", "method": "POST", "errors":{}, "schema":{}, "formData":{}, "uiSchema":{} }

लेकिन बैकएंड पर इस डेटा को कैसे जेनरेट करें? सिस्टम के निर्माण के समय, कोई तैयार पुस्तकालय नहीं थे जो आपको सिम्फनी फॉर्म को JSON स्कीमा में बदलने की अनुमति देते थे। अब वे पहले से ही दिखाई दिए हैं, लेकिन उनकी कमियां हैं - उदाहरण के लिए, LiformBundle JSON स्कीमा की काफी स्वतंत्र रूप से व्याख्या करता है और अपने विवेक पर मानक को बदलता है, इसलिए, दुर्भाग्य से, मुझे अपना खुद का कार्यान्वयन लिखना पड़ा।

पीढ़ी के लिए एक आधार के रूप में, मानक सिम्फनी फॉर्म का उपयोग किया जाता है । यह बिल्डर का उपयोग करने और आवश्यक फ़ील्ड जोड़ने के लिए पर्याप्त है:

फार्म का उदाहरण

 $builder ->add('title', TextType::class, [ 'label' => 'label.title', 'attr' => [ 'title' => 'title.title', ], ]) ->add('description', TextareaType::class, [ 'label' => 'label.description', 'attr' => [ 'title' => 'title.description', ], ]) ->add('year', ChoiceType::class, [ 'choices' => range(1981, 1990), 'choice_label' => function ($val) { return $val; }, 'label' => 'label.year', 'attr' => [ 'title' => 'title.year', ], ]) ->add('genre', ChoiceType::class, [ 'choices' => [ 'fantasy', 'thriller', 'comedy', ], 'choice_label' => function ($val) { return 'genre.choice.'.$val; }, 'label' => 'label.genre', 'attr' => [ 'title' => 'title.genre', ], ]) ->add('available', CheckboxType::class, [ 'label' => 'label.available', 'attr' => [ 'title' => 'title.available', ], ]);

आउटपुट पर, यह फ़ॉर्म फ़ॉर्म के सर्किट में परिवर्तित हो जाता है:

JsonSchema उदाहरण

 { "action": "//localhost/create.json", "method": "POST", "schema": { "properties": { "title": { "maxLength": 255, "minLength": 1, "type": "string", "title": "label.title" }, "description": { "type": "string", "title": "label.description" }, "year": { "enum": [ "1981", "1982", "1983", "1984", "1985", "1986", "1987", "1988", "1989", "1990" ], "enumNames": [ "1981", "1982", "1983", "1984", "1985", "1986", "1987", "1988", "1989", "1990" ], "type": "string", "title": "label.year" }, "genre": { "enum": [ "fantasy", "thriller", "comedy" ], "enumNames": [ "genre.choice.fantasy", "genre.choice.thriller", "genre.choice.comedy" ], "type": "string", "title": "label.genre" }, "available": { "type": "object", "title": "label.available" } }, "required": [ "title", "description", "year", "genre", "available" ], "type": "object" }, "formData": { "title": "", "description": "", "year": "", "genre": "" }, "uiSchema": { "title": { "ui:help": "title.title", "ui:widget": "text" }, "description": { "ui:help": "title.description", "ui:widget": "textarea" }, "year": { "ui:widget": "select", "ui:help": "title.year" }, "genre": { "ui:widget": "select", "ui:help": "title.genre" }, "available": { "ui:help": "title.available", "ui:widget": "checkbox" }, "ui:widget": "mainForm" } }

सभी कोड जो JSON में फ़ॉर्म को कनवर्ट करते हैं, उन्हें बंद कर दिया जाता है और केवल रामब्लर ग्रुप में उपयोग किया जाता है, यदि समुदाय की इस विषय में रुचि है, तो हम इसे अपने गित्ूब रिपॉजिटरी में बंडल प्रारूप में रिफ्लेक्टर करेंगे ।

आइए कुछ और पहलुओं पर गौर करें जिनके बिना आधुनिक वेब एप्लिकेशन बनाना मुश्किल है:

क्षेत्र सत्यापन

यह सिम्फनी सत्यापनकर्ता का उपयोग करके सेट किया गया है, जो किसी वस्तु को मान्य करने के नियमों का वर्णन करता है, एक सत्यापनकर्ता का उदाहरण:

 <property name="title"> <constraint name="Length"> <option name="min">1</option> <option name="max">255</option> <option name="minMessage">title.min</option> <option name="maxMessage">title.max</option> </constraint> <constraint name="NotBlank"> <option name="message">title.not_blank</option> </constraint> </property>

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

आइटम समूहीकरण

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

स्पष्ट निर्णय प्रपत्र को नियंत्रण तत्वों के तार्किक समूहों में विभाजित करना है ताकि उपयोगकर्ता के लिए नेविगेट करना और कम गलतियाँ करना आसान हो:

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

नेस्टेड फॉर्म उदाहरण

 $info = $builder ->create('info',FormType::class,['inherit_data'=>true]) ->add('title', TextType::class, [ 'label' => 'label.title', 'attr' => [ 'title' => 'title.title', ], ]) ->add('description', TextareaType::class, [ 'label' => 'label.description', 'attr' => [ 'title' => 'title.description', ], ]); $builder ->add($info) ->add('year', ChoiceType::class, [ 'choices' => range(1981, 1990), 'choice_label' => function ($val) { return $val; }, 'label' => 'label.year', 'attr' => [ 'title' => 'title.year', ], ]) ->add('genre', ChoiceType::class, [ 'choices' => [ 'fantasy', 'thriller', 'comedy', ], 'choice_label' => function ($val) { return 'genre.choice.'.$val; }, 'label' => 'label.genre', 'attr' => [ 'title' => 'title.genre', ], ]) ->add('available', CheckboxType::class, [ 'label' => 'label.available', 'attr' => [ 'title' => 'title.available', ], ]);

इस फॉर्म को फॉर्म के एक सर्किट में बदला जाएगा:

नेस्टेड JsonSchema उदाहरण

 "schema": { "properties": { "info": { "properties": { "title": { "type": "string", "title": "label.title" }, "description": { "type": "string", "title": "label.description" } }, "required": [ "title", "description" ], "type": "object" }, "year": { "enum": [ "1981", "1982", "1983", "1984", "1985", "1986", "1987", "1988", "1989", "1990" ], "enumNames": [ "1981", "1982", "1983", "1984", "1985", "1986", "1987", "1988", "1989", "1990" ], "type": "string", "title": "label.year" }, "genre": { "enum": [ "fantasy", "thriller", "comedy" ], "enumNames": [ "genre.choice.fantasy", "genre.choice.thriller", "genre.choice.comedy" ], "type": "string", "title": "label.genre" }, "available": { "type": "object", "title": "label.available" } }, "required": [ "info", "year", "genre", "available" ], "type": "object" }

और इसी uiSchema

 "uiSchema": { "info": { "title": { "ui:help": "title.title", "ui:widget": "text" }, "description": { "ui:help": "title.description", "ui:widget": "textarea" }, "ui:widget": "form" }, "year": { "ui:widget": "select", "ui:help": "title.year" }, "genre": { "ui:widget": "select", "ui:help": "title.genre" }, "available": { "ui:help": "title.available", "ui:widget": "checkbox" }, "ui:widget": "group" }

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

 'fieldset' => [ 'groups' => [ [ 'type' => 'base', 'name' => 'info', 'fields' => ['title', 'description'], 'order' => ['title', 'description'] ] ], 'type' => 'base' ]

इसे निम्नलिखित योजना में परिवर्तित किया जाएगा:

 "ui:group": { "type": "base", "groups": [ { "type": "group", "name": "info", "title": "legend.info", "fields": [ "title", "description" ], "order": [ "title", "description" ] } ], "order": [ "info" ] },

स्कीमा और uiSchema का पूर्ण संस्करण

 "schema": { "properties": { "title": { "maxLength": 255, "minLength": 1, "type": "string", "title": "label.title" }, "description": { "type": "string", "title": "label.description" }, "year": { "enum": [ "1989", "1990" ], "enumNames": [ "1989", "1990" ], "type": "string", "title": "label.year" }, "genre": { "enum": [ "fantasy", "thriller", "comedy" ], "enumNames": [ "genre.choice.fantasy", "genre.choice.thriller", "genre.choice.comedy" ], "type": "string", "title": "label.genre" }, "available": { "type": "boolean", "title": "label.available" } }, "required": [ "title", "description", "year", "genre", "available" ], "type": "object" }

 "uiSchema": { "title": { "ui:help": "title.title", "ui:widget": "text" }, "description": { "ui:help": "title.description", "ui:widget": "textarea" }, "year": { "ui:widget": "select", "ui:help": "title.year" }, "genre": { "ui:widget": "select", "ui:help": "title.genre" }, "available": { "ui:help": "title.available", "ui:widget": "checkbox" }, "ui:group": { "type": "base", "groups": [ { "type": "group", "name": "info", "title": "legend.info", "fields": [ "title", "description" ], "order": [ "title", "description" ] } ], "order": [ "info" ] }, "ui:widget": "fieldset" }

चूँकि हमारे सामने उपयोग की जाने वाली रिएक्ट लाइब्रेरी में बॉक्स के बाहर इसका समर्थन नहीं होता है, इसलिए मुझे इस कार्यक्षमता को स्वयं जोड़ना होगा। एक नए तत्व "ui: समूह" के अतिरिक्त के साथ हमें वर्तमान एपीआई का उपयोग करके तत्वों और रूपों को समूहीकृत करने की प्रक्रिया को पूरी तरह से नियंत्रित करने का अवसर मिलता है।

गतिशील रूप

क्या होगा यदि एक क्षेत्र दूसरे पर निर्भर करता है, उदाहरण के लिए, उपश्रेणियों की एक ड्रॉप-डाउन सूची चयनित श्रेणी पर निर्भर करती है?

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

 { "properties": { "genre": { "enum": [ "fantasy", "thriller", "comedy" ], "enumNames": [ "genre.choice.fantasy", "genre.choice.thriller", "genre.choice.comedy" ], "type": "string", "title": "label.genre" }, "sgenre": { "enum": [ "eccentric", "romantic", "grotesque" ], "enumNames": [ { "title": "sgenre.choice.eccentric", "genre": "comedy" }, { "title": "sgenre.choice.romantic", "genre": "comedy" }, { "title": "sgenre.choice.grotesque", "genre": "comedy" } ], "type": "string", "title": "label.genre" } }, "type": "object" }

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

स्कीमाएड - योजना की एक विशेषता, इसमें दर्ज किए गए फॉर्म को फॉर्मेट में संसाधित करने और वर्तमान तर्क की योजना को अपडेट करने के लिए नियंत्रक का पता शामिल है, यदि व्यावसायिक तर्क द्वारा आवश्यक है;
रिलोड - एक विशेषता जो दृश्यपटल को बताती है कि इस क्षेत्र में बदलाव बैकेंड को फॉर्म डेटा भेजकर सर्किट को अपडेट प्रदान करता है;

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

 { "schemaId": "//localhost/schema.json", "properties": { "genre": { "enum": [ "fantasy", "thriller", "comedy" ], "enumNames": [ "genre.choice.fantasy", "genre.choice.thriller", "genre.choice.comedy" ], "type": "string", "title": "label.genre" }, "sgenre": { "enum": [], "enumNames": [], "type": "string", "title": "label.sgenre" } }, "uiSchema": { "genre": { "ui:options": { "reload": true }, "ui:widget": "select", "ui:help": "title.genre" }, "sgenre": { "ui:widget": "select", "ui:help": "title.sgenre" }, "ui:widget": "mainForm" }, "type": "object" }

"शैली" फ़ील्ड को बदलने के मामले में, फ्रंटएंड वर्तमान डेटा के साथ पूरे फॉर्म को बैकएंड पर भेजता है, जिसके जवाब में फॉर्म को प्रदान करने के लिए आवश्यक अनुभागों का एक सेट प्राप्त होता है:

 { action: “https://...”, method: "POST", schema:{} formData:{} uiSchema:{} }

और वर्तमान फॉर्म के बजाय रेंडर करें। भेजने के बाद वास्तव में क्या बदलेगा, यह पीठ द्वारा निर्धारित किया जाता है, रचना या फ़ील्ड की संख्या बदल सकती है, आदि। - किसी भी परिवर्तन कि आवेदन के व्यापार तर्क की आवश्यकता होगी।

निष्कर्ष

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

अपडेट: आप 1:15:00 से सिम्फनी मॉस्को मीटअप # 14 के बारे में हमारी रिपोर्ट देख सकते हैं।

रेम्बलर समूह का अनुभव: हमने फ्रंट-एंड रिएक्ट घटकों के गठन और व्यवहार को पूरी तरह से कैसे नियंत्रित किया

क्षेत्र सत्यापन

आइटम समूहीकरण

गतिशील रूप

निष्कर्ष

More articles: