जैसा कि Yandex.Practicum में, फ्रंट-एंड डेसिंक जीता: Redux-Saga, पोस्टमैसेज और जुपिटर के साथ एक एक्रोबेटिक नंबर

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

वर्कशॉप किसने और क्या बनाया है

हमारी विकास टीम बेहद कॉम्पैक्ट है। बैकएंड पर केवल दो लोग हैं, सामने के छोर पर - चार, मुझे देखते हुए, एक पूर्ण स्टैक। समय-समय पर, Yandex.Tutorial के लोग हमें सुदृढीकरण में शामिल करते हैं। हम दो सप्ताह के स्प्रिंट के साथ स्क्रेम पर काम करते हैं।

हमारा फ़्रंट Redux / Redux-Saga के साथ React.js पर आधारित है, हम बैकएंड के साथ संवाद करने के लिए एक्सप्रेस का उपयोग करते हैं। स्टैक का बैकेंड हिस्सा पायथन (अधिक सटीक, Django) में है, डेटाबेस PostgreSQL है, और कुछ कार्यों के लिए, रेडिस। Redux का उपयोग करते हुए, हम सूचना भंडारण को संग्रहीत करते हैं, Redux और Redux-Saga द्वारा संसाधित किए गए कार्यों को भेजते हैं। सभी साइड इफेक्ट्स, जैसे कि सर्वर रिक्वेस्ट, Yandex.Metrica पर कॉल और रीडायरेक्ट, बस Redux-Saga में प्रोसेस किए जाते हैं। और सभी डेटा संशोधन Redux reducers में होते हैं।

कैसे अपने iframe में लॉग की अनदेखी न करें

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

छह महीने के पाठ्यक्रम " डेटा विश्लेषक " के लिए, हमने एक इंटरैक्टिव सिम्युलेटर बनाया, जहां हम उपयोगकर्ताओं को जुपिटर नोटबुक का उपयोग करना सिखाते हैं । यह इंटरेक्टिव कंप्यूटिंग के लिए एक शांत खोल है, जो डेटा वैज्ञानिकों द्वारा सही ढंग से प्यार किया जाता है। पर्यावरण में सभी ऑपरेशन नोटबुक के अंदर किए जाते हैं, लेकिन एक सरल तरीके से - एक नोटबुक (जैसा कि मैं इसे बाद में कॉल करूंगा)।

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

बुनियादी कठिनाइयों के कार्यान्वयन के साथ उत्पन्न नहीं हुआ। नोटबुक स्वयं एक अलग iframe में बसा था, इसे जाँचने का तर्क बैकएंड पर निर्धारित किया गया था।


छात्र नोटबुक स्वयं (दाईं ओर) केवल एक iframe है जिसका URL JupyterHub में एक विशिष्ट नोटबुक की ओर जाता है।

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

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

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

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

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

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

जब हम "चेक टास्क" बटन पर क्लिक करते हैं, तो संबंधित घटना Redux स्टोर पर भेजी जाती है: "तो और इसलिए, हमें चेक किया जाना है।" Redux-Saga कार्रवाई को देखता है और एक iframe में पोस्टमैसेज करता है। अब वह जवाब देने के लिए इफ्रेम का इंतजार कर रही है। इस बीच, हमारा छात्र बटन पर डाउनलोड संकेतक देखता है "कार्य की जांच करें" और समझता है कि सिम्युलेटर लटका नहीं है, लेकिन "सोचता है"। और केवल जब पोस्टमेज़ेज यह कहते हुए वापस आता है कि बचत पूरी हो गई है, Redux-Saga काम करना जारी रखता है और बैकएंड पर एक अनुरोध भेजता है। सर्वर पर कार्य की जाँच की जाती है - सही समाधान या नहीं, यदि गलतियाँ की जाती हैं, तो कौन सा, आदि, और यह जानकारी बड़े करीने से Redux Store में संग्रहीत है। और वहां से, फ्रंट-एंड स्क्रिप्ट पाठ इंटरफ़ेस में खींचती है।

यहाँ आरेख है कि अंत में बाहर आया है:



(1) हम बटन दबाते हैं "कार्य की जांच करें" (चेक करें) → (2) हम कार्रवाई भेजते हैं CHECK_NOTEBOOK_REQUEST → (3) हम चेक की कार्रवाई भेजते हैं → (2) हम कार्रवाई भेजते हैं SAOTEBOOK_REQUEST → (3) हम कार्रवाई को भेजते हैं और iframe में पोस्टमैसेज सेव करते हैं। (४) संदेश प्राप्त करें → (५) नोटबुक सहेजा जाता है → (४) जुपिटर एपीआई से घटना को प्राप्त करें कि नोटबुक को सहेज लिया गया है और पोस्टमेजेज नोटबुक-सहेजे गए → (१) प्राप्त करें घटना → (२) कार्रवाई भेजें SAVE_NITEBOOK_SUCCESS → (३) हम कार्रवाई को पकड़ते हैं और नोटबुक की जांच करने के लिए एक अनुरोध भेजें → (6) → (7) जांचें कि यह नोटबुक डेटाबेस में है → (8) → (7) नोटबुक कोड के लिए जाएं → (5) कोड लौटाएं → (7) कोड की जांच करें → (9) ) → (7) हमें कट मिलता है जैसे जांच → (6) → (3) हम कार्रवाई CHECK_NOTEBOOK_SUCCESS भेज → (2) प्रतिक्रिया पक्षीय सत्यापित करने के लिए नीचे → (1) परिणाम ड्रा

आइए देखें कि यह सब कोड के संदर्भ में कैसे काम करता है।

हमारे सामने अंत में trainer_type_jupyter.jsx है - उस पृष्ठ की स्क्रिप्ट जहां हमारी नोटबुक खींची गई है।

<div className="trainer__right-column"> {notebookLinkIsLoading ? ( <iframe className="trainer__jupiter-frame" ref={this.onIframeRef} src={notebookLink} /> ) : ( <Spin size="l" mix="trainer__jupiter-spin" /> )} </div> 

"चेक जॉब" बटन पर क्लिक करने के बाद, हैंडलचेक विधि कहा जाता है।

 handleCheckTasks = () => { const {checkNotebook, lesson} = this.props; checkNotebook({id: lesson.id, iframe: this.iframeRef}); }; 

वास्तव में, हैंडलचेक कार्य पारित मापदंडों के साथ Redux कार्रवाई को लागू करने के लिए कार्य करता है।

 export const checkNotebook = getAsyncActionsFactory(CHECK_NOTEBOOK).request; 

यह Redux-Saga और अतुल्यकालिक तरीकों के लिए डिज़ाइन की गई एक सामान्य क्रिया है। यहाँ getAsyncActionsFactory तीन कार्य उत्पन्न करता है:

// बर्तन / दुकान-सहायक / async.js

 export function getAsyncActionsFactory(type) { const ASYNC_CONSTANTS = getAsyncConstants(type); return { request: payload => ({type: ASYNC_CONSTANTS.REQUEST, payload}), error: (response, request) => ({type: ASYNC_CONSTANTS.ERROR, response, request}), success: (response, request) => ({type: ASYNC_CONSTANTS.SUCCESS, response, request}), } } 

तदनुसार, getAsyncConstants फॉर्म के तीन स्थिरांक * _REQUEST, * _SUCCESS और * _ERROR उत्पन्न करता है।

अब देखते हैं कि हमारी Redux-Saga इस अर्थव्यवस्था को कैसे संभालेगी:

// trainer.saga.js

 function* watchCheckNotebook() { const watcher = createAsyncActionSagaWatcher({ type: CHECK_NOTEBOOK, apiMethod: Api.checkNotebook, preprocessRequestGenerator: function* ({id, iframe}) { yield put(trainerActions.saveNotebook({iframe})); yield take(getAsyncConstants(SAVE_NOTEBOOK).SUCCESS); return {id}; }, successHandlerGenerator: function* ({response}) { const {completed_tests: completedTests} = response; for (let id of completedTests) { yield put(trainerActions.setTaskSolved(id)); } }, errorHandlerGenerator: function* ({response: error}) { yield put(appActions.setNetworkError(error)); } }); yield watcher(); } 

जादू? कुछ भी असाधारण नहीं। जैसा कि आप देख सकते हैं, createAsyncActionSagaWatcher बस एक वॉटरमार्क बनाता है जो डेटा को एक्शन में आने से पहले प्रोसेस कर सकता है, एक विशिष्ट URL पर एक अनुरोध कर सकता है, * _REQUEST एक्शन को प्रेषण कर सकता है और सर्वर से एक सफल प्रतिक्रिया के बाद * _SCCCCESS और * _ERROR को प्रेषण कर सकता है। इसके अलावा, ज़ाहिर है, प्रत्येक विकल्प के लिए, घड़ी के अंदर हैंडलर प्रदान किए जाते हैं।

आपने शायद देखा कि डेटा प्रीप्रोसेसर में हम एक और Redux-Saga कहते हैं, जब तक यह SUCCESS के साथ खत्म नहीं हो जाता, तब तक प्रतीक्षा करें और उसके बाद ही काम करना जारी रखें। और हां, iframes को सर्वर पर भेजने की जरूरत नहीं है, इसलिए हम केवल id देते हैं।

SaveNotebook फ़ंक्शन पर करीब से नज़र डालें:

 function* saveNotebook({payload: {iframe}}) { iframe.contentWindow.postMessage(JSON.stringify({ type: 'save-notebook' }), '*'); yield; } 

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

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

 define([ 'base/js/namespace', 'base/js/events' ], function( Jupyter, events ) {...}); 

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

पाठ के फ्रंट में पैरेंट विंडो के साथ संवाद करने के लिए प्लगइन सिखाया जाना चाहिए: आखिरकार, उनके बीच की desync कार्य सत्यापन के साथ बग का कारण है। सबसे पहले, हम उन सभी संदेशों की सदस्यता लेते हैं जो हमें प्राप्त होते हैं:

 window.addEventListener('message', actionListener); 

अब हम उनका प्रसंस्करण प्रदान करेंगे:

 function actionListener({data: eventString}) { let event = ''; try { event = JSON.parse(eventString); } catch(e) { return; } switch (event.type) { case 'save-notebook': Jupyter.actions.call('jupyter-notebook:save-notebook'); Break; ... default: break; } } 

हमारे प्रारूप में फिट नहीं होने वाली सभी घटनाओं को साहसपूर्वक अनदेखा किया जाता है।

हम देखते हैं कि सेव-नोटबुक इवेंट हमारे पास आता है, और हम नोटबुक को बचाने के लिए कार्रवाई कहते हैं। यह केवल एक संदेश वापस भेजने के लिए रहता है कि नोटबुक को संरक्षित किया गया है:

 events.on('notebook_saved.Notebook', actionDispatcher); function actionDispatcher(event) { switch (event.type) { case 'select': const selectedCell = Jupyter.notebook.get_selected_cell(); dispatchEvent({ type: event.type, data: {taskId: getCellTaskId(selectedCell)} }); return; case 'notebook_saved': default: dispatchEvent({type: event.type}); } } function dispatchEvent(event) { return window.parent.postMessage( typeof event === 'string' ? event : JSON.stringify(event), '*' ); } 

दूसरे शब्दों में, बस {टाइप करें:, नोटबुक_सावेद ’} ऊपर भेजें। इसका मतलब है कि नोटबुक को संरक्षित किया गया है।

आइए अपने घटक पर वापस जाएं:

//trainer_type_jupyter.jsx

 componentDidMount() { const {getNotebookLink, lesson} = this.props; getNotebookLink({id: lesson.id}); window.addEventListener('message', this.handleWindowMessage); } 

घटक बढ़ते समय, हम सर्वर से नोटबुक के लिंक के लिए पूछते हैं और उन सभी कार्यों की सदस्यता लेते हैं जो हमारे लिए उड़ान भर सकते हैं:

 handleWindowMessage = ({data: eventString}) => { const {activeTaskId, history, match: {params}, setNotebookSaved, tasks} = this.props; let event = null; try { event = JSON.parse(eventString); } catch(e) { return; } const {type, data} = event; switch (type) { case 'app_initialized': this.selectTaskCell({taskId: activeTaskId}) return; case 'notebook_saved': setNotebookSaved(); return; case 'select': { const taskId = data && data.taskId; if (!taskId) { return } const task = tasks.find(({id}) => taskId === id); if (task && task.status === TASK_STATUSES.DISABLED) { this.selectTaskCell({taskId: null}) return; } history.push(reversePath(urls.trainerTask, {...params, taskId})); return; } default: break; } }; 

यह वह जगह है जहां सेटनोटबुक सेव्ड एक्शन प्रेषण कहा जाता है, जो Redux-Saga को काम करना जारी रखने और नोटबुक को बचाने की अनुमति देगा।

पसंद की गड़बड़

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

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

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

इसलिए हमने यह हासिल कर लिया है कि नोटबुक में सेल का चयन करना असंभव है जो प्रशिक्षण समयरेखा द्वारा सुलभ नहीं होना चाहिए। यह सच है, इसने एक अलौकिक, लेकिन बग को जन्म दिया: आप एक दुर्गम कार्य के साथ एक सेल पर क्लिक करने का प्रयास करते हैं, और यह जल्दी से "ब्लिंक" करता है: यह स्पष्ट है कि यह एक पल के लिए सक्रिय था, लेकिन तुरंत अवरुद्ध हो गया था। जबकि हमने इस खुरदरेपन को खत्म नहीं किया है, यह सबक लेने में हस्तक्षेप नहीं करता है, लेकिन पृष्ठभूमि में हम यह सोचते रहते हैं कि इससे कैसे निपटें (वैसे, क्या कोई विचार हैं?)।

समस्या को हल करने के लिए हमने अपने दृश्य को कैसे संशोधित किया, इसके बारे में थोड़ा सा। चलिए फिर से trainer_type_jupyter.jsx की ओर मुड़ते हैं - हम app_initialized और चयन पर ध्यान केंद्रित करेंगे।

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

अर्थात्:

// trainer_type_jupyter.jsx

 selectTaskCell = ({taskId}) => { const {selectCell} = this.props; if (!this.iframeRef) { return; } selectCell({iframe: this.iframeRef, taskId}); }; 

// trainer.actions.js

 export const selectCell = ({iframe, taskId}) => ({ type: SELECT_CELL, iframe, taskId }); 

// trainer.saga.js

 function* selectCell({iframe, taskId}) { iframe.contentWindow.postMessage(JSON.stringify({ type: 'select-cell', data: {taskId} }), '*'); yield; } function* watchSelectCell() { yield takeEvery(SELECT_CELL, selectCell); } 

// custom.js (ज्यूपिटर प्लगइन)

 function getCellTaskId(cell) { const notebook = Jupyter.notebook; while (cell) { const tags = cell.metadata.tags; const taskId = tags && tags[0]; if (taskId) { return taskId; } cell = notebook.get_prev_cell(cell); } return null; } function selectCell({taskId}) { const notebook = Jupyter.notebook; const selectedCell = notebook.get_selected_cell(); if (!taskId) { selectedCell.unselect(); return; } if (selectedCell && selectedCell.selected && getCellTaskId(selectedCell) === taskId) { return; } const index = notebook.get_cells() .findIndex(cell => getCellTaskId(cell) === taskId); if (index < 0) { return; } notebook.select(index); const cell = notebook.get_cell(index); cell.element[0].scrollIntoView({ behavior: 'smooth', block: 'start' }); } function actionListener({data: eventString}) { ... case 'select-cell': selectCell(event.data); break; 

अब आप सेल को स्विच कर सकते हैं और iframe से सीख सकते हैं कि सेल को स्विच किया गया है।

सेल को स्विच करते समय, हम URL बदलते हैं और किसी अन्य कार्य में आते हैं। यह केवल विपरीत करने के लिए ही रहता है - जब इंटरफ़ेस में किसी अन्य कार्य को चुनते हैं, तो सेल को स्विच करें। आसान:

 componentDidUpdate({match: {params: {prevTaskId}}) { const {match: {params: {taskId}}} = this.props; if (taskId !== prevTaskId) { this.selectTaskCell({taskId}); 

पूर्णतावादियों के लिए अलग बॉयलर

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

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

• कोड के टुकड़े जो समस्याओं को हल करते हैं, पूरे प्रोजेक्ट में बिखरे हुए हैं। इफ्रेम्स के साथ संचार Redux-Saga और घटक से दोनों से किया जाता है, जो निश्चित रूप से इष्टतम नहीं है।

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

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

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

शायद आपके साथ विचार आते हैं?