2018 के मध्य में, Sports.ru ने उपयोगकर्ता पदों के लिए एक नए WYSIWYG पाठ संपादक पर जाने के बारे में सोचा । जून 2019 से, संपादक बीटा मोड में है। इस समय के दौरान, हमने पूरी सेवा की वास्तुकला के डिजाइन और प्रोसेमिरोर लाइब्रेरी पर आधारित ब्राउज़र में स्वयं संपादक के कार्यान्वयन से जुड़ी कई समस्याओं को हल किया और अपने अनुभव को साझा करने का निर्णय लिया।

विषय - सूची

1. परिचय
1.1। आपको WYSIWYG
1.2 की आवश्यकता क्यों थी । डेवलपर्स द्वारा सामना किए गए कार्य का विवरण
2. टूल का चयन कैसे करें
3. क्या हुआ
3.1। सेवा वास्तुकला
3.2। क्या चुनौतियां हैं
4. बीटा टेस्ट परिणाम

1। परिचय

1.1। आपको WYSIWYG की आवश्यकता क्यों थी

Sports.ru प्रति माह 20 मिलियन उपयोगकर्ताओं के दर्शकों के साथ खेल के बारे में मीडिया है। क्लासिक मीडिया से हमारे मुख्य अंतर समुदाय और यूजीसी हैं । उपयोगकर्ता सामग्री - रेटिंग, टिप्पणियां, चैट, पोस्ट - न केवल संपादकीय मूल्य को पूरक करते हैं, बल्कि उपयोगकर्ताओं को एक दूसरे के साथ बातचीत करने के लिए एक मंच भी बनाते हैं। हर महीने, हमारे उपयोगकर्ता लगभग 10 हजार पोस्ट लिखते हैं। उनमें से सर्वश्रेष्ठ संपादकीय के साथ साइट के मुख्य पृष्ठ पर प्रस्तुत किए जाते हैं, मोबाइल एप्लिकेशन, सोशल नेटवर्क पर भेजे जाते हैं। उपयोगकर्ता सामग्री का सभी Sports.ru पृष्ठों पर लगभग 40% हिस्सा है।

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

अंजीर। 1. TinyMCE पर आधारित पुराने संपादक का इंटरफ़ेस

नियमित रूप से निम्नलिखित शिकायतों के बारे में प्राप्त ब्लॉगों के लेखकों से:

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

टीम की अपनी शिकायतें भी थीं:

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

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

1.2। डेवलपर्स का सामना कर रहे कार्य का विवरण

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

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

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

WYSIWYG, .. what you see is what you get (. « , », ), , . , ;
( , , , , ; , ) .

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

हमारे पास बहुत सी पाठ सामग्री है, और एक नया पोस्ट संपादक बनाने पर काम शुरू करने से पहले, हमने इस बारे में सोचा कि इस सामग्री को कैसे संग्रहीत किया जाना चाहिए। TinyMCE ने हमें कोई विकल्प नहीं दिया और सामग्री केवल HTML में संग्रहीत की जानी थी, जो कि ऊपर वर्णित है, टीम के अनुरूप नहीं थी। परिणामस्वरूप, हम अपनी आवश्यकताओं को पूरा करने वाले पाठ डेटा को संग्रहीत करने के लिए अपने स्वयं के प्रारूप के साथ आए, और इसे संरचित निकाय कहा जाता है।

संरचित निकाय वस्तुओं की एक सरणी है जो सामग्री की संरचना को दर्शाता है। इस मामले में, सामग्री को उन तत्वों में विभाजित किया जाता है जो स्वतंत्र ब्लॉक हैं, उदाहरण के लिए, पैराग्राफ, सूची, चित्र। एक तत्व इस बारे में जानकारी संग्रहीत करता है कि यह किस प्रकार का है और इसके क्या गुण हैं। उदाहरण के लिए, उपशीर्षक ब्लॉक पाठ में शीर्षक का वर्णन करता है, इसमें पाठ और स्तर फ़ील्ड शामिल होने चाहिए। तदनुसार, पाठ में इस शीर्षक का पाठ होता है, और स्तर में स्तर (1 से 4 तक) होता है। एक संरचित निकाय, जिसमें एक दूसरे स्तर के हेडर होते हैं, उदाहरण के लिए, इस तरह दिख सकते हैं:

const structuredBody = [
    {
        type: 'subtitle',
        value: {
            text: '    ',
            level: 2,
        },
    },
];

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

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

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

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

कुल: पदों का हिस्सा (सभी नए और पुराने जिन्हें सफलतापूर्वक नए प्रारूप में स्थानांतरित कर दिया गया था) को दो स्वरूपों में संग्रहीत किया जाएगा - HTML और संरचित निकाय - जब तक कि पढ़ने के लिए नया प्रदर्शन तर्क लागू नहीं किया जाता है, और बाकी (अधिकांश पुराने और बहुत पुराने पद) केवल HTML में ही रहेंगे।

2. कैसे एक उपकरण का चयन करने के लिए

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

शुरू करने के लिए, हमने जांच की कि WYSIWYG संपादक बनाने के लिए कौन से तैयार पुस्तकालय हैं और क्या वे हमारे लिए उपयुक्त हैं। हम स्लेट , Draft.js और ProseMirror पर बसे ।

डेटा संरचना में सामग्री संग्रहीत करने के अलावा, हमारे लिए महत्वपूर्ण क्षण भी Vue या शुद्ध JS के साथ काम करने की क्षमता थी, क्योंकि हमने पहले ही Vue + Vuex का उपयोग करके साइट को एक नए तकनीकी स्टैक में स्थानांतरित करना शुरू कर दिया था। इसके अलावा, मैं आवश्यक होने पर नए मॉड्यूल (थर्ड-पार्टी या स्व-लिखित) की मदद से तैयार लाइब्रेरी की क्षमताओं का विस्तार करना चाहूंगा।

टैब। 1. Sports.ru के लिए सबसे महत्वपूर्ण मापदंडों द्वारा समीक्षा की गई पुस्तकालयों की तुलना।

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

3. क्या हुआ

3.1। सेवा वास्तुकला

क्लाइंट पर कंटेंट एडिटर सभी से बहुत दूर है। आपको एक मौजूदा परियोजना में संपादक को जगह देने की जरूरत है, इसे वेब पेज पर कहीं प्रदर्शित करें, और बैकएंड के साथ बातचीत पर भी विचार करें, साथ ही दो संपादकों का समर्थन करने की समस्या को हल करें (आप तुरंत पुराने को छोड़ नहीं सकते हैं) और सामग्री को दो प्रारूपों में संग्रहीत करें (HTML और संरचित तन)।

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

संपादक के लिए कई सेवाओं को कई स्तरों में विभाजित किया जा सकता है:

पोस्ट बनाने और संपादित करने के लिए वेब पेज;
Vue-app, . , , Vue, -, , , , .., , , ;
WYSIWYG- ProseMirror, Vue. , , ;
SB2HTML – HTML structured body, . , structured body – , . , , , . Sports.ru HTML structured body, - HTML . HTML Node.Js, JS- .

पद को बचाने की प्रक्रिया अंजीर में दिखाई गई है। 2. संरचित निकाय प्रारूप में पोस्ट की सामग्री और इसके मेटा-डेटा बैकएंड में स्थानांतरित किए जाते हैं। बैकएंड SB2HTML सेवा को सामग्री भेजता है, प्रतिक्रिया में तैयार HTML प्राप्त करता है, यह सब डेटाबेस में डालता है और क्लाइंट को बताता है कि पोस्ट सफलतापूर्वक सहेजा गया है, या एक त्रुटि की रिपोर्ट करता है।

अंजीर। 2. WYSIWYG संपादक में बनाते या संपादित करते समय किसी पोस्ट को सहेजने की योजना

3.2। आपको किन कठिनाइयों का सामना करना पड़ा?

कई कठिनाइयां थीं, वे लगातार और अक्सर सबसे अप्रत्याशित क्षणों में पैदा हुईं।

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

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

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

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

अगली समस्या फिर से पुरानी और नई प्रौद्योगिकियों की पिछड़ी अनुकूलता की आवश्यकता से संबंधित है। हमारा WYSIWYG संपादक केवल ब्राउज़रों (डेस्कटॉप और जल्द ही, मोबाइल) में लागू किया जाता है। तदनुसार, क्लाइंट पर सामग्री को संपादित करने के लिए JSON में संरचित संरचित निकाय में दिया गया है, हालांकि, ब्राउज़रों में पोस्ट पढ़ना केवल HTML के माध्यम से किया जाता है। उसी समय, अधिकांश मोबाइल एप्लिकेशन पहले से ही संरचित निकाय से सीधे उपयोगकर्ता पोस्ट प्रदर्शित करने के लिए स्विच कर चुके हैं।

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

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

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

HTML2SB इसके विपरीत है जो SB2HTML करता है, यानी HTML से संरचित शरीर में सामग्री को परिवर्तित करता है। क्रोनोलॉजिकल रूप से, यह सेवा कुछ और की तुलना में पहले दिखाई दी, क्योंकि WYSIWYG संपादक के निर्माण से पहले, संरचित शरीर प्रारूप में पोस्ट सामग्री प्राप्त करने का एकमात्र तरीका HTML से प्रत्यक्ष पार्सिंग था। HTML2SB पोस्ट एडिटर के आस-पास बैकएंड इन्फ्रास्ट्रक्चर का हिस्सा था, लेकिन TinyMCE को छोड़ने के बाद, अब इसकी आवश्यकता नहीं थी।

4. बीटा परिणाम

अब WYSIWYG- संपादक बीटा संस्करण में सभी उपयोगकर्ताओं के लिए उपलब्ध है, और जल्द ही Sports.ru पदों का मुख्य संपादक बन जाएगा। हमें पहले ही पोस्ट बनाने और संपादित करने का एक उपकरण मिल गया है जो हमारी अधिकांश आवश्यकताओं को पूरा करता है:

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

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

स्वत: सहेजना;
विस्तारित अधिकारों (प्रशासकों, पूर्णकालिक संपादकों) वाले उपयोगकर्ताओं के लिए WYSIWYG संस्करण;
मोबाइल ब्राउज़र से पोस्ट बनाना और संपादित करना;
कई उपयोगकर्ताओं द्वारा एक दस्तावेज़ के समानांतर संपादन के बारे में संदेश;
युक्तियां और जहाज पर;
खेल टीमों, मैचों और लाइनअप के लिए सांख्यिकीय विगेट्स।

इस लेखन के समय, संपादक के बीटा संस्करण के माध्यम से 13,000 से अधिक पोस्ट पहले ही प्रकाशित किए जा चुके हैं, जो जून 2019 से फरवरी 2020 तक की अवधि के लिए Sports.ru पर उपयोगकर्ता ग्रंथों की कुल संख्या का लगभग 20% है। नए संपादक के माध्यम से बनाई और प्रकाशित की जाने वाली पोस्ट का हिस्सा लगातार बढ़ रहा है।

अंजीर। 3. नए संपादक में बनाए गए और प्रकाशित किए गए उपयोगकर्ता पदों का अनुपात

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

अंजीर। 4. WYSIWYG संपादक अपडेट की घोषणा के साथ एक पोस्ट में उपयोगकर्ता टिप्पणियां

जैसा कि Sports.ru ने अपने WYSIWYG संपादक को लिखा था