प्रतिक्रिया और BEM - आधिकारिक सहयोग। ऐतिहासिक हिस्सा

यहाँ BEM कार्यप्रणाली को प्रतिक्रिया ब्रह्मांड में एकीकृत करने की कहानी है। आपके द्वारा पढ़ी जाने वाली सामग्री यैंडेक्स डेवलपर्स के अनुभव पर आधारित है जो रूस में सबसे बड़ी और सबसे भरी हुई सेवा विकसित कर रहा है - Yandex.Search। हमने पहले कभी इस तरह से विस्तार से बात नहीं की और इस बारे में गहराई से बताया कि हमने ऐसा क्यों किया, और अन्यथा नहीं, हमें क्या प्रेरित किया और हम वास्तव में क्या चाहते थे। बाहरी लोगों को सम्मेलनों में सूखा रिलीज और समीक्षा मिली। केवल किनारे पर कोई ऐसा कुछ सुन सकता था। सह-लेखक के रूप में, मैं हर बार जब मैं पुस्तकालयों के नए संस्करणों के बारे में बात करता था, तो बाहर की जानकारी की कमी के कारण मैं नाराज था। लेकिन इस बार हम सभी विवरण साझा करेंगे।

बीईएम पद्धति के बारे में सभी ने सुना है। सीएसएस चयनकर्ताओं अंडरस्कोर के साथ। घटक दृष्टिकोण के बारे में बात की, सीएसएस सीएसएस चयनकर्ताओं के तरीके को ध्यान में रखते हुए। लेकिन लेख में CSS के बारे में एक शब्द नहीं होगा। केवल जेएस, केवल कट्टर!

यह समझने के लिए कि कार्यप्रणाली क्यों दिखाई दी और यांडेक्स ने किन समस्याओं का सामना किया, मैं सुझाव देता हूं कि आप बीईएम के इतिहास से खुद को परिचित करें ।

प्रस्तावना

बीईएम वास्तव में मजबूत कनेक्टिविटी और सीएसएस में घोंसले से मुक्ति के रूप में पैदा हुआ था। लेकिन प्रत्येक ब्लॉक, तत्व या संशोधक के लिए फाइल में style.css शीट को विभाजित करना अनिवार्य रूप से जावास्क्रिप्ट कोड के समान संरचना का कारण बना।

2011 में, ओपन सोर्स ने i-bem.js का पहला कमिट हासिल किया, जो bem-xjst टेम्पलेट इंजन के साथ मिलकर काम करता था। दोनों प्रौद्योगिकियां XSLT से आगे बढ़ीं और व्यापार तर्क और घटक प्रस्तुति को अलग करने के तत्कालीन लोकप्रिय विचार पर काम किया। बाहर की दुनिया में, ये हैंडलबार्स और अंडरस्कोर के महान समय थे।

bem-xjst एक अलग प्रकार का टेम्पलेट इंजन है। मानकीकरण के दृष्टिकोण की वास्तुकला के बारे में अपने ज्ञान को बढ़ाने के लिए, मैं सर्गेई बेरेज़्नॉय की एक रिपोर्ट की अत्यधिक अनुशंसा करता हूं। bem-xjst ऑनलाइन सैंडबॉक्स में bem-xjst टेम्पलेट इंजन bem-xjst सकते हैं ।

यांडेक्स खोज सेवाओं की बारीकियों के कारण, उपयोगकर्ता इंटरफेस डेटा का उपयोग करके बनाया गया है। खोज परिणाम पृष्ठ प्रत्येक क्वेरी के लिए अद्वितीय है।

संदर्भ द्वारा खोज क्वेरी

संदर्भ द्वारा खोज क्वेरी

संदर्भ द्वारा खोज क्वेरी

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

 src/components ├── ComponentName │ ├── _modName │ │ ├── ComponentName_modName.tsx —   │ │ └── ComponentName_modName_modVal.tsx —    │ ├── ElementName │ │ └── ComponentName-ElementName.tsx —   ComponentName │ ├── ComponentName.i18n —   │ │ ├── ru.ts —     │ │ ├── en.ts —     │ │ └── index.ts —    │ ├── ComponentName.test —   │ │ ├── ComponentName.page-object.js — Page Object │ │ ├── ComponentName.hermione.js —   │ │ └── ComponentName.test.tsx — unit- │ ├── ComponentName.tsx —    │ ├── ComponentName.scss —   │ ├── ComponentName.examples.tsx —    Storybook │ └── README.md —   

आधुनिक घटक निर्देशिका संरचना

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

नीचे फ़ाइल सिस्टम पर फ़ाइलों के लिए BEMJSON नोड्स का पत्राचार है।

 module.exports = { block: 'Select', elem: 'Item', elemMods: { type: 'navigation' } }; 

 src/components ├── Select │ ├── Item │ │ _type │ │ ├── Select-Item_type_navigation.js │ │ └── Select-Item_type_navigation.css 

YModules मॉड्यूलर सिस्टम ब्राउज़र में जावास्क्रिप्ट कोड के घटकों को अलग करने के लिए जिम्मेदार था। यह आपको तुल्यकालिक और अतुल्यकालिक रूप से ब्राउज़र को मॉड्यूल देने की अनुमति देता है। घटक YModules और i-bem.js साथ कैसे काम करते हैं, YModules एक उदाहरण यहां पाया जा सकता है । आज, अधिकांश डेवलपर्स के लिए, webpack और गतिशील आयात के असंबंधित मानक ऐसा करते हैं ।

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

नई उम्मीद

2013 में, रिएक्ट ने ओपन सोर्स को मंत्रमुग्ध कर दिया । वास्तव में, फेसबुक ने 2011 में इसका उपयोग करना शुरू कर दिया था। जेएस कॉन्फिडेंस यूएस कॉन्फ्रेंस के अपने नोट्स में जेम्स लॉन्ग कहते हैं:

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

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

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

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

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

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

संस्करण 16 तक, रिएक्ट में एक घातक दोष था। यह सर्वर पर bem-xjst की तुलना में 10 गुना धीमा था। हम इस तरह की बर्बादी बर्दाश्त नहीं कर सकते थे। यांडेक्स के लिए प्रतिक्रिया समय प्रमुख मीट्रिक में से एक है। कल्पना कीजिए कि जब आप एक मुल्तानी शराब बनाने की विधि पूछते हैं, तो आपको सामान्य से 10 गुना धीमा जवाब मिलेगा। आप बहानेबाजी से खुश नहीं होंगे, भले ही आप वेब विकास के बारे में कुछ भी जानते हों। हम स्पष्टीकरण के बारे में क्या कह सकते हैं, जैसे "लेकिन यह डेवलपर्स के लिए DOM के साथ संवाद करने के लिए अधिक सुविधाजनक हो गया"। यहां कार्यान्वयन और लाभ की कीमत का अनुपात जोड़ें - और आप खुद ही एकमात्र सही निर्णय लेंगे।

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

उलटा हो गया

हमें भरोसा था कि हम रिएक्ट की सुस्ती को हरा सकते हैं। हमारे पास पहले से ही एक त्वरित टेम्पलेट इंजन है। आप सभी की जरूरत है bem-xjst का उपयोग कर सर्वर पर HTML उत्पन्न करने के लिए, और इस मार्कअप को अपने स्वयं के रूप में स्वीकार करने के लिए "बल" प्रतिक्रिया करने के लिए क्लाइंट पर। यह विचार इतना सरल था कि कुछ भी विफल नहीं हुआ।

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

bem-xjst एक बहुत ही कम उपकरण है। ग्लोरी ओलियानचुक के मुख्य अनुरक्षक की रिपोर्ट को देखें और अपने लिए देखें । bem-xjst एक आर्किटेक्चर पर आधारित है जो आपको स्रोत ट्री के विभिन्न परिवर्तनों के लिए एक टेम्पलेट सिंटैक्स का उपयोग करने की अनुमति देता है। बहुत प्रतिक्रिया के समान है, है ना? यह सुविधा आज react-sketchapp जैसे टूल react-sketchapp ।

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

हाइपरस्क्रिप्ट फ़ंक्शन कॉल पीढ़ी के लिए एक विस्तृत परिचय

चूंकि रिएक्ट टेम्प्लेट को लेआउट और व्यावसायिक तर्क के सह-अस्तित्व की आवश्यकता होती है, इसलिए हमें i-bem.js से लॉजिक को अपने टेम्प्लेट में लाना होगा, जो इसके लिए अभिप्रेत नहीं थे। उनके लिए यह अप्राकृतिक था। वे अलग-अलग जा रहे थे। वैसे!

नीचे एक रनटाइम में अलग-अलग दुनिया की gluing की गहराई से एक उदाहरण है।

 block('select').elem('menu')( def()(function() { const React = require('react'); const Menu = require('../components/menu/menu'); const MenuItem = require('../components/menu-item/menu-item'); const _select = this.ctx._select; const selectComponent = _select._select; return React.createElement.apply(React, [ Menu, { mix: { block : this.block, elem : this.elem }, ref: menu => selectComponent._menu = menu, size: _select.mods.size, disabled: _select.mods.disabled, mode: _select.mods.mode, content: _select.options, checkedItems: _select.bindings.checkedItems, style: _select.bindings.popupMenuWidth, onKeyDown: _select.bindings.onKeyDown, theme: _select.mods.theme, }].concat(_select.options.map(option => React.createElement( MenuItem, { onClick: _select.bindings.onOptionCheck, theme: _select.mods.theme, val: option.value, }, option.content) )) ); }) ); 

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

यह सब हमारे लिए ईएनबी ने किया। हमने मानकीकरण के लिए अंतिम पेड़ केवल रनटाइम में प्राप्त किया, और चूंकि बंडल इकट्ठा करने के लिए घटकों के बीच निर्भरता को थोड़ा पहले उठना पड़ा था, इस फ़ंक्शन को अल्प-ज्ञात deps.js तकनीक द्वारा लिया गया था। इसने आपको घटकों के बीच एक निर्भरता ग्राफ बनाने की अनुमति दी, जिसके बाद कलेक्टर ग्राफ को दरकिनार करते हुए वांछित अनुक्रम में कोड को गोंद कर सकता था।

प्रतिक्रिया संस्करण 16 ने इस दिशा में काम करना बंद कर दिया। सर्वर पर टेम्प्लेट के निष्पादन की गति बराबर थी । उत्पादन सुविधाओं पर, अंतर अगोचर हो गया।

नोड: v8.4.0
बच्चे: 5K

नीचे दिए गए लिंक का उपयोग करके आप दृष्टिकोण के इतिहास को पुनर्स्थापित कर सकते हैं:

• https://ru.bem.info/forum/961/
• https://github.com/awinogradov/react-bl
• https://github.com/awinogradov/xjst-ddsl
• https://github.com/awinogradov/ddsl-react

क्या हमने कुछ और आजमाया है?

• https://github.com/veged/bem-compenders-react - प्रतिक्रिया में कार्यप्रणाली को लागू करने का पहला तरीका;
• https://github.com/Yeti-or/bem-hazard - BH टेम्पलेट इंजन पर आधारित एक समान दृष्टिकोण। BH के साथ, वैसे, आप ऑनलाइन खेल सकते हैं;
• https://github.com/dfilatov/bem-react - BEMJSON के माध्यम से घटक बनाना;
• https://github.com/rebem - प्रतिक्रिया दुनिया में BEM उपयोगिताओं।

प्रेरणा

कहानी के बीच में, यह बात उपयोगी होगी कि हमें किस बात ने प्रेरित किया। यह शुरुआत में ऐसा करने के लायक था, लेकिन - जो एक उपहार के रूप में पुराने, उस आंख को याद करता है। हमें यह सब क्यों चाहिए? बीईएम क्या ला सकता है जो रिएक्ट नहीं कर सकता है? सवाल जो लगभग हर कोई पूछता है।

सड़न

घटकों की कार्यक्षमता वर्ष-दर-वर्ष अधिक जटिल हो जाती है, और विविधताओं की संख्या बढ़ जाती है। यह if या switch निर्माणों द्वारा व्यक्त किया जाता है, परिणामस्वरूप, कोड आधार अनिवार्य रूप से बढ़ता है, जिसके परिणामस्वरूप - घटक का वजन और इस तरह के घटक का उपयोग करने वाली परियोजना बढ़ जाती है। रिएक्ट घटक के तर्क का मुख्य भाग render() विधि में निहित है। एक घटक की कार्यक्षमता को बदलने के लिए, अधिकांश विधि को फिर से लिखना आवश्यक है, जो अनिवार्य रूप से अत्यधिक विशिष्ट घटकों की संख्या में एक घातीय वृद्धि की ओर जाता है।

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

यांडेक्स के पास घटकों के साथ अपनी खुद की लाइब्रेरी भी है - लेगो। इसे ~ 200 सेवाओं में लागू किया जाता है। क्या हम चाहते हैं कि खोज में लेगो का उपयोग Yandex.Health के लिए समान हो? आपको जवाब पता है।

क्रॉस-प्लेटफॉर्म विकास

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

अलग-अलग संस्करणों के विकास के लिए अतिरिक्त संसाधनों की आवश्यकता होती है: अधिक मंच, अधिक प्रयास। विभिन्न संस्करणों में उत्पाद गुणों के समकालिक स्थिति को बनाए रखने से नई कठिनाइयों का कारण होगा।

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

क्या हम चाहते हैं कि हमारे माता-पिता / मित्र / सहकर्मी / बच्चे मोबाइल पर डेस्कटॉप संस्करणों का उपयोग कम इंटरनेट स्पीड और कम उत्पादकता के साथ करें? आपको जवाब पता है।

प्रयोगों

यदि आप बड़े दर्शकों के लिए प्रोजेक्ट विकसित कर रहे हैं, तो आपको हर बदलाव के बारे में सुनिश्चित होना चाहिए। A / B प्रयोग उस आत्मविश्वास को प्राप्त करने का एक तरीका है।

प्रयोगों के लिए कोड व्यवस्थित करने के तरीके:

• परियोजना का कांटा और उत्पादन में सेवा के उदाहरणों का निर्माण;
• कोड बेस के अंदर बिंदु स्थितियां।

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

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

विभिन्न दर्शकों के लिए विभिन्न संयोजनों में खोज ~ 100 ऑनलाइन प्रयोग। आप इसे अपने लिए देख सकते हैं। याद रखें, हो सकता है कि आपने कार्यक्षमता पर ध्यान दिया हो, और एक हफ्ते बाद यह जादुई रूप से गायब हो गया। क्या हम 500,000 लाइनों के सक्रिय कोड आधार की सैकड़ों शाखाओं को बनाए रखने की कीमत पर उत्पाद सिद्धांतों का परीक्षण करना चाहते हैं, जिन्हें दैनिक ~ 60 डेवलपर्स द्वारा बदल दिया जाता है? आपको जवाब पता है।

वैश्विक परिवर्तन

उदाहरण के लिए, आप एक लाइब्रेरी से Button से विरासत में प्राप्त एक CustomButton घटक बना सकते हैं। लेकिन विरासत में मिली CustomButton Button वाले पुस्तकालय से सभी घटकों पर लागू नहीं होगी। लाइब्रेरी में Input और Button से निर्मित एक Search घटक हो सकता है। इस मामले में, विरासत में मिला CustomButton Search घटक के अंदर दिखाई नहीं देता है। क्या हम मैन्युअल रूप से पूरे कोड आधार पर जाना चाहते हैं जहां Button उपयोग किया जाता है?

रचना के लिए लंबी सड़क

हमने रणनीति बदलने का फैसला किया। पिछले दृष्टिकोण में, उन्होंने यैंडेक्स प्रौद्योगिकी को आधार के रूप में लिया और इस आधार पर काम करने के लिए रिएक्ट प्राप्त करने का प्रयास किया। नई रणनीति ने इसके विपरीत सुझाव दिया। इस तरह से बेम-प्रतिक्रिया-कोर परियोजना के बारे में आया।

इसे रोको! आखिर क्यों हुई प्रतिक्रिया?

हमने इसे HTML में स्पष्ट प्रारंभिक रेंडरिंग से छुटकारा पाने का अवसर देखा और बाद में रनटाइम में जेएस घटक की स्थिति के मैनुअल समर्थन से - वास्तव में, BEMHMTL टेम्प्लेट और जेएस घटकों को एक प्रौद्योगिकी में विलय करना संभव हो गया।

v1.0.0

प्रारंभ में, हमने रिएक्ट के शीर्ष पर bem-xjst सभी सर्वोत्तम प्रथाओं और गुणों को लाइब्रेरी में स्थानांतरित करने की योजना बनाई। पहली चीज जो आपकी आंख को पकड़ती है वह है हस्ताक्षर, या, यदि आप चाहें, तो घटकों का वर्णन करने के लिए वाक्यविन्यास।

आपने क्या किया है, जेएसएक्स है!

पहला संस्करण विरासत के आधार पर बनाया गया था - एक पुस्तकालय जो कक्षाओं और विरासत को लागू करने में मदद करता है। जैसा कि आप में से कुछ याद करते हैं, उन दिनों जावास्क्रिप्ट में प्रोटोटाइप प्रोटोटाइप में कक्षाएं नहीं थीं, कोई super नहीं था। सामान्य तौर पर, वे अभी भी अनुपस्थित हैं, अधिक सटीक रूप से, ये वे वर्ग नहीं हैं जो पहले ध्यान में आते हैं। inherit ने सब कुछ किया जो कि ES2015 मानक में कक्षाएं अब कर सकती हैं, और जिसे काला जादू माना जाता है: श्रृंखला के पुनर्निर्माण के बजाय कई विरासत और प्रोटोटाइप विलय, जो प्रदर्शन को सकारात्मक रूप से प्रभावित करता है। आप गलत नहीं होंगे यदि आपको लगता है कि यह Node.js में विरासत की तरह समझ में आता है, लेकिन वे अलग तरह से काम करते हैं।

नीचे टेम्प्लेट्स bem-react-core@v1.0.0 के सिंटैक्स का उदाहरण bem-react-core@v1.0.0 ।

ऐप-Header.js

 import { decl } from 'bem-react-core'; export default decl({ block: 'App', elem: 'Header', attrs: { role: 'heading' }, content() { return ' '; } }); 

App-Header@desktop.js

 import { decl } from 'bem-react-core'; export default decl({ block: 'App', elem: 'Header', tag: 'h1', attrs() { return { ...this.__base(...arguments), 'aria-level': 1 }, }, content() { return ` ${this.__base(...arguments)}     h1`; } }); 

App-Header@touch.js

 import { decl } from 'bem-react-core'; export default decl({ block: 'App', elem: 'Header', tag: 'h2', content() { return ` ${this.__base(...arguments)}  `; } }); 

index.js

 import ReactDomServer from 'react-dom/server'; import AppHeader from 'b:App e:Header'; ReactDomServer.renderToStaticMarkup(<AppHeader />); 

output@desktop.html

 <h1 class="App-Header" role="heading" aria-level="1">A       h1</h2> 

output@touch.html

 <h2 class="App-Header" role="heading">   </h2> 

अधिक जटिल घटकों के लिए उपकरण टेम्पलेट यहां देखे जा सकते हैं ।

चूंकि एक क्लास एक ऑब्जेक्ट है, और जावास्क्रिप्ट में ऑब्जेक्ट्स के साथ काम करना सबसे सुविधाजनक है, वाक्यविन्यास उपयुक्त है। सिंटैक्स बाद में अपने मास्टरमाइंड bem-xjst ।

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

आयात जादू

जैसा कि आप देख सकते हैं, कोड उदाहरणों में import AppHeader from 'b:App e:Header' लाइनें हैं।

आपने मानक तोड़ा! यह असंभव है! यह सिर्फ काम नहीं करेगा!

सबसे पहले, आयात मानक भावना में शर्तों के साथ काम नहीं करता है "आयात लाइन में एक वास्तविक मॉड्यूल के लिए एक रास्ता होना चाहिए"। दूसरे, यह सिंथेटिक चीनी है जिसे बैबेल का उपयोग करके परिवर्तित किया गया था। तीसरा, अजीब import txt from 'raw-loader!./file.txt'; विराम चिह्न import txt from 'raw-loader!./file.txt'; लिए निर्माण import txt from 'raw-loader!./file.txt'; किसी कारण से वे किसी को परेशान नहीं करते थे।
तो, हमारे ब्लॉक को दो प्लेटफार्मों में प्रस्तुत किया गया है: desktop , touch ।

 import Hello from 'b:Hello'; //     : var Hello = [ require('path/to/desktop/Hello/Hello.js'), require('path/to/touch/Hello/Hello.js') ][0].applyDecls(); 

यहां, कोड क्रमिक रूप से सभी घटक परिभाषाओं को आयात करेगा Hello, और फिर एक फ़ंक्शन को कॉल करेगा applyDeclsजो वैश्विक भंडार से सभी ब्लॉक घोषणाओं को गोंद inheritकरता है और एक नया रिएक्ट घटक बनाता है जो परियोजना में एक विशिष्ट स्थान के लिए अद्वितीय है।

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

अंत में, जो अच्छा था:

• टेम्पलेट्स के संक्षिप्त, घोषणात्मक वाक्यविन्यास जो आपको परियोजना में कहीं भी घटक के विभिन्न भागों को फिर से परिभाषित करने की अनुमति देते हैं;
• विरासत में कोई प्रोटोटाइप चेन नहीं;
• उपयोग के प्रत्येक स्थान के लिए अद्वितीय प्रतिक्रिया घटक।

और यह बुरा था:

• TypeScript/Flow;
• React- ;
• - ;
• .

v2.0.0

bem-react-core@v1.0.0 , .

 import { Elem } from 'bem-react-core'; import { Button } from '../Button'; export class AppHeader extends Elem { block = 'App'; elem = 'Header'; tag() { return 'h2'; } content() { return ( <Button> </Button> ); } } 

, . , , TypeScript/Flow. , inherit «» , , .

:
— webpack Babel;
— ;
— , .

HOC , .

 import * as React from 'react'; import * as ReactDOM from 'react-dom'; import { Block, Elem, withMods } from 'bem-react-core'; interface IButtonProps { children: string; } interface IModsProps extends IButtonProps { type: 'link' | 'button'; } //   Text class Text extends Elem { block = 'Button'; elem = 'Text'; tag() { return 'span'; } } //   Button class Button<T extends IModsProps> extends Block<T> { block = 'Button'; tag() { return 'button'; } mods() { return { type: this.props.type }; } content() { return ( <Text>{this.props.children}</Text> ); } } //    Button,    type   link class ButtonLink extends Button<IModsProps> { static mod = ({ type }: any) => type === 'link'; tag() { return 'a'; } mods() { return { type: this.props.type }; } attrs() { return { href: 'www.yandex.ru' }; } } //   Button  ButtonLink const ButtonView = withMods(Button, ButtonLink); ReactDOM.render( <React.Fragment> <ButtonView type='button'>Click me</ButtonView> <ButtonView type='link'>Click me</ButtonView> </React.Fragment>, document.getElementById('root') ); 

, .

withMods , (), . , , withMods , . . , , , ( ) . . , , — , .

, :

• . , . , TS. , . ES5 TS super , . , TS , .
• . TS ES6 Babel ES5. , npm- . , Babel.

:

• , . , . : DOM-. HOC, . withMods .
• (, , ) . SFC .
• CSS-. CSS- JS- . , , .

v2.

, . . , , 1 2. .

— . CSS- HOC, — dependency injection .

React:

• CSS-.
• (, );

. . React.ComponentType -. HOC compose .

.

dependency injection, React.ContextAPI . , , . , . DI — HOC, . . , , .

, , . , , 4 , 1.5Kb .

. अंत तक पढ़ने वालों को धन्यवाद। , React . .