नमस्ते, यह यांडेक्स से कात्या है। फिर से। मैंने अपनी कहानी जारी रखी कि कैसे मैंने बनाना बंद कर दिया और जीना शुरू कर दिया। पहले भाग में, मैंने बताया कि मैं यहाँ कैसे आया और हमारे फ्रंट-एंड डेवलपर्स क्या करते हैं। आज - सामने स्टैक के बारे में, कहां से रिएक्ट है और बीईएम कहां गया।

Spoiler: BEM ツ \ _ (_) _ / ¯ कहीं भी नहीं गया है। चलो चलते हैं!



ध्यान दें: फ्रंटेंड की उच्च एकाग्रता। बहुत से पाठ, चित्र और कोड, जैसा कि वादा किया गया था।

भाग 2. प्रौद्योगिकी के बारे में

सुदूर 2016. प्रतिक्रिया में लिखने की कोशिश कर रहा है, यह बहुत सहनशीलता से पता चलता है। मुझे अभी भी संदेह नहीं है कि एक वर्ष में मैं पूरी सेवाओं को रिएक्ट में स्थानांतरित कर दूंगा। 2017 Yandex.Money पर शुरू होता है, मेरे पास मस्तिष्क का एक बीईएम है, और मुझे अभी भी संदेह नहीं है।

Node.js पर बैकेंड, मेरी पहली बार

परियोजना से परिचित होने के लिए, एक नया डेवलपर एक परीक्षण कार्य प्राप्त करता है। मैं भाग्यशाली था: मेरे पास बैकलॉग से यह कार्य था। और पहले ही दिन मैं Node.js. में भाग गया

Yandex.Money में फ्रंट-एंड न केवल क्लाइंट पक्ष के लिए, बल्कि सर्वर लेयर के लिए Node.ss एप्लिकेशन के रूप में भी जिम्मेदार है। एप्लिकेशन का कार्य दृश्य-उन्मुख रूप में तैयारी के साथ-साथ सर्वर रेंडरिंग और रूटिंग के लिए जावा बैकएंड से डेटा ऑर्केस्ट्रेट करना है। आपको यह कुछ साल पहले बताया गया होगा, मुझे कुछ भी समझ में नहीं आया होगा, और सब कुछ काफी सरल है: जब ब्राउज़र से सर्वर के लिए एक अनुरोध आता है, तो Node.js बैकएंड के लिए HTTP अनुरोधों को उत्पन्न करता है, आवश्यक डेटा और टेम्पलेट्स वेब पेज प्राप्त करता है। हम एक्सप्रेस को सर्वर फ्रेमवर्क के रूप में उपयोग करते हैं, और एक विरासत लिंक के बिना आंतरिक अनुप्रयोगों को विकसित करने के लिए , हमने Koa2 का उपयोग करने का निर्णय लिया। डेवलपर्स को रूपरेखा के डिजाइन से प्यार था, और हमने एक्सप्रेस को डाउनग्रेड नहीं करने का फैसला किया, इसलिए Koa2 स्टैक पर रहा। लेकिन हम बाहरी उपयोगकर्ताओं के लिए Koa2 कोड को रोल आउट नहीं करते हैं: ढांचे के पास पर्याप्त समर्थन नहीं है, लेकिन खुली कमजोरियां हैं।

हमने अपने सीमांत में पहले से ही Node.js की जगह के बारे में लिखा था , लेकिन तब से कुछ बदल गया है। Node.js 8 एलटीएस बन गया है और पहले से ही हमारे उत्पादन सर्वर पर चल रहा है। हम Nginx सर्वर को भी छोड़ना चाहते हैं, जिसे हम प्रत्येक होस्ट पर स्टेटिक्स वितरित करने के लिए बढ़ाते हैं - उन्हें अलग-अलग सर्वरों द्वारा Nginx और किसी दिन CDN से बदल दिया जाएगा।

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

हमने एक प्रयोग भी किया - हमने एक प्रक्रिया प्रबंधक को एक अनुप्रयोग में पेश किया, जिसने Node.js. पर सेवाओं के प्रशासन को सरल बनाया। उन्होंने क्लस्टरिंग में मदद की, और हमें एक पुरानी बैश स्क्रिप्ट से भी बचाया जो अनुप्रयोगों को चलाती थी।

और पूरा ढेर पर्याप्त नहीं है

हमारे सामने हर जगह जावास्क्रिप्ट है। और सर्वर पर, और क्लाइंट पर, और आंतरिक उपकरणों के हुड के नीचे। हम अन्य भाषाओं को जानते हैं, लेकिन जावास्क्रिप्ट एक महान काम करता है।

लेकिन हमारे कार्यों के ढांचे में BEM सब कुछ के साथ सामना नहीं करता है।


इसलिए, हमने सेवाओं को रिएक्ट में स्थानांतरित करना शुरू कर दिया। उनमें से कुछ पहले से ही अलग-अलग ढेर पर बने दो अनुप्रयोगों में रहते हैं:

- यांडेक्स बीईएम के लिए विशिष्ट एक मंच;
- रिएक्ट के युवा और फैशनेबल पारिस्थितिकी तंत्र।

यांडेक्स टेक्नोलॉजीज

यह आपको यह बताने का समय है कि मुझे बीईएम से प्यार क्यों हुआ।

पुनर्निर्धारण स्तर

स्तर, स्तर, स्तर ... BEM! लाभ!
ओवरराइडिंग स्तर BEM कार्यप्रणाली की मुख्य विशेषताओं में से एक है। यह समझने के लिए कि वे कैसे काम करते हैं, चित्र देखें:


छवि ओवरलेइंग परतों द्वारा बनाई गई है। प्रत्येक परत अंतिम तस्वीर को बदल देती है, लेकिन अन्य परतों को नहीं बदलती है। परत को आसानी से बाहर निकाला या जोड़ा जा सकता है, और तस्वीर बदल जाएगी।
ओवरराइड का स्तर कोड के साथ समान है:


घटक का व्यवहार कोड असेंबली के दौरान बनता है। अतिरिक्त व्यवहार जोड़ने के लिए, बस वांछित स्तर को विधानसभा से कनेक्ट करें। विभिन्न स्तरों से मॉड्यूल का कोड जैसे कि एक दूसरे के ऊपर स्तरित होता है। इस मामले में, स्रोत कोड नहीं बदलता है, लेकिन हमें अलग-अलग स्तरों को मिलाकर अलग-अलग व्यवहार मिलता है।


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

जब मैं बीईएम से परिचित हो गया, तो मैं विशेष रूप से यूआई पुस्तकालयों से प्रसन्न था जिसमें तैयार घटक झूठ बोलते हैं। हम नए पुस्तकालयों के ढांचे के भीतर इन घटकों का विस्तार कर रहे हैं और परियोजनाओं के बीच साझा कर रहे हैं। यह जीवन को आसान बनाता है: मैं शायद ही कभी बनाता हूं, एक ही प्रकार का जेएस नहीं लिखता है और जल्दी से तैयार ब्लॉकों से इंटरफेस इकट्ठा करता है।



अब हम BEM प्लेटफ़ॉर्म के उपकरणों पर करीब से नज़र डालेंगे, ताकि यह समझ सकें कि BEM पर्याप्त रूप से अच्छा नहीं करता है और इसने हमारे कार्यों के अनुरूप क्यों नहीं किया।

कार्यलय-XJST

मैं अपने पसंदीदा bem-xjst टेम्पलेट इंजन के साथ शुरुआत करूँगा। Yandex.Money से पहले, मैंने जेड का उपयोग किया, और बेम-एक्सजस्ट ने जेड के minuses को पूरी तरह से चित्रित किया, जो मैंने तब नहीं देखा था। Bem-xjst टेम्प्लेट्स घोषणात्मक [1] हैं, उनके पास नरक [2] नहीं है, और वे पूरी तरह से घटक दृष्टिकोण [3] की आवश्यकताओं को पूरा करते हैं। यह सब स्पष्ट रूप से उदाहरण में देखा गया है:



सैंडबॉक्स में, आप टेम्पलेट का परिणाम देख सकते हैं और इसके साथ खेल सकते हैं।


Bem-xjst isomorphic है। हम सर्वर पर HTML पृष्ठों को प्रस्तुत करते हैं और इसे गतिशील रूप से क्लाइंट पर बदलते हैं। रनटाइम में टेंपलेटिंग के लिए, बीएम-एक्सजस्ट एक एपीआई प्रदान करता है जिसका उपयोग हम क्लाइंट-साइड जावास्क्रिप्ट कोड लिखते समय करते हैं।

मैं-कार्यलय

बेम-एक्सजस्ट के साथ हम आई-बेम के साथ दृश्य, और तर्क का वर्णन करते हैं। I-bem DOM के ऊपर एक अमूर्तता है जो घटकों के साथ काम करने के लिए एक उच्च-स्तरीय एपीआई प्रदान करता है। सीधे शब्दों में कहें, यह लिखने देता है:



बजाय:



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

I-bem आपको राज्यों के एक सेट के रूप में घटक के तर्क का वर्णन करने की अनुमति देता है [1]। यह घोषणात्मक जावास्क्रिप्ट है। I-bem अपने स्वयं के ईवेंट एमिटर को लागू करता है: जब राज्य बदलते हैं, तो घटक स्वचालित रूप से ऐसी घटनाओं को उत्पन्न करते हैं जो एक अन्य घटक [2] की सदस्यता ले सकते हैं।

यह BEM क्लाइंट-साइड जावास्क्रिप्ट कोड की तरह दिखता है:




I-bem के साथ, हम आसानी से घटकों के व्यवहार को फिर से परिभाषित कर सकते हैं, उनकी बातचीत के लिए एक अच्छी तरह से बनाई गई एपीआई बना सकते हैं और गतिशील रूप से उन्हें रनटाइम में बदल सकते हैं। तो क्या गायब है?
हम BEM को प्रेमपूर्णता, आसान स्केलेबिलिटी और उच्च-स्तरीय अमूर्तता के लिए प्यार करते हैं, लेकिन अब इसकी सीमाओं के साथ तैयार नहीं हैं। नीचे हम क्लाइंट रेंडरिंग, डेटा स्टोरेज और BEM प्लेटफॉर्म की अन्य सीमाओं की समस्या पर विचार करेंगे। समय के साथ, इन समस्याओं को BEM योगदानकर्ताओं द्वारा हल किया जा सकता है, लेकिन हम प्रतीक्षा करने के लिए तैयार नहीं हैं।

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

नई प्रतिक्रिया मेपल स्टैक

रिएक्ट हमारे जीवन में एक आभासी डोम, हॉट रीलोड, जेएस में सीएसएस और एक बड़ा समुदाय है जिसमें हम एक हिस्सा बन गए हैं।

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

पुस्तकालयों

स्वतंत्र BEM ब्लॉकों में इंटरफ़ेस एंटिटीज को विभाजित करना रिएक्ट घटक दृष्टिकोण के साथ बहुत अनुकूल है। Yandex डेवलपर्स ने bem-react-core लिखा और बेस घटक UI लाइब्रेरी को React में स्थानांतरित किया। हमने इसके ऊपर एक एडाप्टर लाइब्रेरी लिखी है जो इन घटकों की बारीकियों को ध्यान में रखती है और उन्हें HOC के रूप में आपूर्ति करती है:



ऐसे पुस्तकालय अनुप्रयोग में नहीं, बल्कि घटक के मुख्य पुस्तकालय से जुड़े होते हैं:



आवेदन केवल मुख्य पुस्तकालय पर निर्भर करता है और इससे सभी घटक मिलते हैं:



यह अनुप्रयोग निर्भरता की संख्या को कम करता है, और पुस्तकालयों को विभिन्न संस्करणों के तहत दो बार बंडल में नहीं मिलता है।

प्रौद्योगिकी के

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

सामने का छोर बार में आता है, और बारटेंडर उसे बताता है

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

मेनू में:

1. बर्फ के साथ कॉन्फ़िगर करें: बार मिक्स करता है और आपके yml चर को हिलाता है और ansible के लिए एक कॉन्फ़िगरेशन टेम्पलेट तैयार करता है।
   
2. कॉन्फ़िगरेशन की सुगंध के साथ जूस: बार एक मॉड्यूलर रिक्त के आधार पर एक नया एप्लिकेशन बनाएगा - रस।
   
3. बुनियादी पुस्तकालय सेटिंग्स का सेट। जल्द ही आ रहा है
   

रसदार ऐप बनाना अब आसान है - फ्रंटेंड-बार मेक जूस। रस बनाओ, युद्ध नहीं! जब Bar एक नया अनुप्रयोग दिखाता है, तो वह Juice से विन्यास का एक सेट निष्पादित करता है: package.json, .babelrc, मुख्य मिडलवेयर और रूट कोड, रूट कंपोनेंट कोड उत्पन्न होता है। फ्रंटेंड बार नए माइक्रोसॉर्क्स के आवंटन की सुविधा प्रदान करेगा और कोड लिखने के लिए समान नियमों का पालन करने में मदद करेगा।

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



स्पॉयलर: प्याज चुनें।

क्या हुआ और क्या यह बेहतर हुआ? आइए समझते हैं

गतिशील इंटरफेस

यह था

मैंने ऊपर लिखा है कि रन-वे में टेम्प्लेट करने के लिए बीएम-एक्सजस्ट एक एपीआई प्रदान करता है। I-bem, बदले में, DOM ट्री के साथ काम कर सकता है। हम उन्हें मित्र बनाएंगे और हम HTML को गतिशील रूप से उत्पन्न और संशोधित करने में सक्षम होंगे। आइए घटना के आधार पर बटन बदलने का प्रयास करें:




इस उदाहरण में, BEM का कमजोर पक्ष दिखाई देता है: i-bem, bem-xjst के साथ दोस्ती नहीं करना चाहता है और टेम्पलेट्स के बारे में कुछ भी जानना नहीं चाहता है। यह ब्लॉक में एक वर्ग जोड़ता है, लेकिन टेम्पलेट [1] को लागू नहीं करता है। हम मैन्युअल रूप से घटक को फिर से प्रस्तुत करते हैं [2]:

• बीईएम पेड़ के एक नए टुकड़े का वर्णन करें [3];
• फिर एक नया टेम्प्लेट लागू करें [4];
• और वर्तमान DOM नोड [5] पर एक अन्य घटक को इनिशियलाइज़ करें।

इसके अलावा, i-bem BEM पेड़ों का अंतर पैदा नहीं करता है, इसलिए, पूरे घटक का प्रतिपादन किया जाता है, न कि उन हिस्सों का, जो बदल गए हैं। एक साधारण उदाहरण पर विचार करें: मांग पर एक मोडल विंडो की सामग्री को फिर से प्रस्तुत करना। इसमें तीन तत्व शामिल हैं:



सरलता के लिए, हम मानते हैं कि केवल एक तत्व बदल सकता है।



मैं [1] और आराम करना चाहता हूं। लेकिन आई-बेम को समझ नहीं आएगा कि क्या बदल गया है, पूरे घटक को फिर से प्रस्तुत करना और आराम करना भी है। इस उदाहरण में, कोई गंभीर परिणाम नहीं होंगे, लेकिन क्या होगा अगर पूरे रूपों को इस तरह से गलत तरीके से पेश किया जाए? यह प्रदर्शन को खराब करता है और अप्रिय साइड इफेक्ट्स का कारण बनता है: कहीं इनपुट फ़्लिकर, कहीं मालिकाना टूलटिप कहीं लटका हुआ है। इस वजह से, हम एक बिंदु रेंडर [2] बनाने के लिए घटकों के भागों को उदास और मैन्युअल रूप से नियंत्रित करते हैं। यह विकास को जटिल बनाता है, और फिर से हम दुखी होते हैं।

बन गया है

रिएक्ट आया और सब कुछ बर्बाद कर दिया। वह खुद घटकों की स्थिति की निगरानी करता है, हम अब मैनुअल रेंडरिंग का प्रबंधन नहीं करते हैं और डोम के साथ बातचीत करने के बारे में नहीं सोचते हैं। प्रतिक्रिया में एक वर्चुअल DOM कार्यान्वयन होता है। React.createElement को कॉल करना इसके गुणों और वंशजों के साथ DOM नोड का एक js-object बनाता है - इस घटक का वर्चुअल DOM, जो React के अंदर संग्रहीत होता है। जब एक घटक बदलता है, तो रिएक्ट नए वर्चुअल डोम की गणना करता है और फिर सहेजे गए और नए का अंतर, और केवल उसी डोम के हिस्से को अपडेट करता है जो बदल गया है। सब कुछ उड़ जाता है, और हम केवल जटिल तर्क का उपयोग कर सकते हैं shouldComponentUpdate। यह एक सफलता है!

डेटा भंडारण

यह था

BEM में, हम सर्वर पर सभी डेटा तैयार करते हैं और इसे पेज घटकों में स्थानांतरित करते हैं:



घटक अलग-थलग हैं और एक दूसरे के साथ डेटा साझा नहीं करेंगे, जिसका अर्थ है कि समान डेटा को अलग-अलग घटकों में फेंकना होगा [1]। हम उन्हें क्लाइंट पर प्राप्त नहीं कर पाएंगे, इसलिए प्रत्येक घटक अग्रिम में डेटा के एक सेट को स्वीकार करता है जो इसके संचालन के सभी संभावित परिदृश्यों के लिए आवश्यक है। इसका मतलब है कि हम उस घटक को डेटा के साथ लोड करते हैं जिसकी उसे आवश्यकता नहीं है [2]।

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

बन गया है

Redux + प्रतिक्रिया = <3
Redux संपूर्ण एप्लिकेशन के डेटा को एक स्थान पर संग्रहीत करता है [1]:



घटक खुद तय करता है कि उसे कब और किस डेटा की जरूरत है:



हमें केवल घटक के परिदृश्यों का वर्णन करना है [3] और इंगित करें कि इसके निष्पादन के लिए डेटा कहां मिलेगा: [४]



और रिएक्ट करेगा बाकी [5]:



यह दृष्टिकोण आपको एकल जिम्मेदारी के सिद्धांत का पालन करने की अनुमति देता है और पृष्ठ कोड में इसे फैलाने के बजाय, घटक में घटक के तर्क को अतिक्रमण करता है। यह एक सफलता है!

आपको हर चीज के लिए भुगतान करना होगा

सफलता के लिए, हमने रिएक्ट पर विरासत की भारी राशि का भुगतान किया। यह देखने के लिए दर्दनाक है कि कैसे कुछ महीने पहले लिखा आपका कोड, आसानी से पदावनत हो जाता है।

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

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

अप्रत्याशित बन्स

नए स्टैक ने हमें कई कार्यों पर नए सिरे से विचार करने की अनुमति दी और उन्हें हल करने के सरल तरीके प्रदान किए।

जेएस में सीएसएस

यह था

जीवन से एक साधारण मामले पर विचार करें: किसी घटना के द्वारा एक आइकन को रंगीन और चेतन करें, कुछ इस तरह से:



कोड कुछ भी नहीं है:



सही है, BEM के नियमों के अनुसार, आपको इसे पहले से ही तीन निर्देशिकाओं में वितरित करना होगा:



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



लेकिन क्या होगा अगर एनीमेशन की अवधि कुछ पर निर्भर करती है और गतिशील रूप से सेट की जाती है? फिर हम jQuery में CSS एनीमेशन को फिर से लिखेंगे और थोड़ा दुखी होंगे।

बन गया है

स्टाइल-घटकों , मैं तुमसे प्यार करता हूँ! जेएस में सीएसएस - एक प्यार!मेरे आंतरिक टाइप्टर आनन्द:



प्रतिरूपकता संरक्षित है, सीएसएस एनीमेशन काम करता है और कक्षाओं के साथ कोई मैनुअल काम नहीं करता है। नए स्टैक के लिए एक अच्छा बोनस।

टाइपिंग

यह था

हम jsDoc के टन लिखते थे। आइए देखें कि क्या यह उपयोगी है:



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

बन गया है

टंकण बचाव में आया। प्रकार पर "टायक", और मेरी आंखों के सामने विधि के सभी इंस और बहिष्कार। समझने के लिए बहुत आलसी? Precommit चेकर प्रवाह शुरू हो जाएगा , और आपको अभी भी यह पता लगाना है।

मुझे पहली नजर में प्रवाह नापसंद था। दिनांक, प्रबंधक पिंग पर हैं, और आपके पास "संपत्ति प्राप्त नहीं कर सकते हैं", और यहाँ "संपत्ति गायब है"। लेकिन हाल ही में मुझे बताया गया था कि प्रकारों को O_o द्वारा डिज़ाइन किया जा सकता है। कुछ इस तरह:



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

तो और BEM नहीं?

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

BEM में, हमारा ई-मेल न्यूज़लेटर टेम्पलेट इंजन कार्यान्वित किया जाता है। हम सर्वर पर पत्र तैयार करते हैं, और ऊपर वर्णित बीईएम प्लेटफॉर्म की सीमाएं इस एप्लिकेशन को प्रभावित नहीं करती हैं। इसे विकसित करने के लिए BEM का उपयोग करना एक उचित सुरुचिपूर्ण समाधान है।

इसके अलावा, हमारे डिजाइनर बीईएम का उपयोग करते हुए प्रोटोटाइप करते हैं और कभी-कभी लेआउट के बजाय हमें पूर्व-इकट्ठे घटकों को लाते हैं। और भले ही हम BEM पर लिखना बंद कर दें, फिर भी वह हमें खोज लेगा :)

मैंने पहला भाग पढ़ा। कोडर्स के बारे में क्या?

मैंने बीईएम से रिएक्ट के अनुप्रयोगों में से एक के अनुवाद में भाग लिया और एक महत्वपूर्ण बात समझी।

Yandex.Money में शामिल होने से पहले, मैं एक साधारण टाइपसेटर था और एक साल से अधिक समय तक, मील ऑफ़ टन HTML और JSX पर बिताया। मैंने फ्रंट-एंड समुदाय और इसकी बदलती दुनिया को गंभीरता से नहीं लिया। मुझे समझ में नहीं आया कि पहले एंगुलर का अध्ययन करने के लिए कल के बारे में भूलने के लिए और दूसरे का अध्ययन करने के लिए क्यों। मुझे समझ नहीं आया कि क्यों बदलकर jQuery.Ajax to Fetch, फिर Axch के साथ Fetch को बदलना।

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

सभी को प्रतिक्रिया दें!