"आपका पुस्तकालय, आपके बच्चे की तरह, आपके लिए अप्रत्याशित दिशा में जा सकता है": MobX के निर्माता के साथ साक्षात्कार

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

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

यूजीन: क्या आप पहले उन लोगों के लिए अपने बारे में थोड़ा बता सकते हैं जो आपको नहीं जानते हैं?

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

यूजीन: आप वास्तव में मेंडिक्स में क्या करते हैं, क्या आप तकनीकी सलाहकार हैं?

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

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

यूजीन: ओएसएस इंजीलवाद का उल्लेख आपके ट्विटर विवरण में किया गया है। यह क्या है और यह आपके लिए महत्वपूर्ण क्यों है?

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

और दूसरा: मेरा मानना ​​है कि हमारे "निम्न-स्तरीय" घटनाक्रम कंपनी को परिभाषित नहीं करते हैं, इसलिए उन्हें साझा न करें। मेरा मतलब है, किसी कंपनी को किसी उत्पाद द्वारा कम या ज्यादा प्रतिस्पर्धी बनाया जाता है जो कि उसकी प्रौद्योगिकियों के आधार पर बनाया जाता है - और न कि इन प्रौद्योगिकियों द्वारा। और सभी लोग सहयोग से लाभान्वित होते हैं, इससे विकास को गति देने में मदद मिलती है।

यूजीन: कभी-कभी वे कहते हैं कि "गैर-नकद" खुला स्रोत वास्तव में एक बहुत महंगा आनंद है। लिनक्स जैसी परियोजनाओं के लिए ओरेकल और माइक्रोसॉफ्ट जैसे दिग्गजों से एक टन धन की आवश्यकता होती है। क्या ऐसा है? क्या बड़े विक्रेताओं और पैसे के बिना एक खुला स्रोत समुदाय मौजूद हो सकता है?

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

यूजीन: उदाहरण के लिए, यदि फेसबुक आपके पास आता है और कहता है "चलो MobX खरीदें या इसे प्रायोजित करें ताकि विकास हमारे ब्रांड के तहत हो जाए?"

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

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

यूजीन: यदि कोई बड़ी कंपनी पुस्तकालय को प्रायोजित करती है, तो क्या यह नहीं कह सकता है कि "चूंकि हम इतना भुगतान करते हैं, इसलिए कृपया, इसमें हमारे साथ ऐसा करें"?

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

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

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

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

- खैर, जब मैंने MobX पर काम करना शुरू किया, तो यह केवल मेरे खाली समय में ही था, जब इस प्रोजेक्ट ने लोकप्रियता हासिल की तो काम करने वाला भी जुड़ गया। लेकिन मेरे पास कुछ टिप्स हैं। मैंने देखा कि कई नियम हैं जिन्होंने मेरी मदद की है।

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

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

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

इन सभी युक्तियों से मदद मिलती है जब आपकी लाइब्रेरी लोकप्रियता हासिल करना शुरू करती है।

यूजीन: जब लोकप्रिय पुस्तकालय का निर्माता "मैं पुन: पेश कर सकता हूं, तो एक इकाई परीक्षण लिख सकता है" का जवाब देता है, क्या इससे लोगों को यह महसूस नहीं होता है कि "वह संकल्पित है और मदद नहीं करना चाहता है"?

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

यूजीन: जब पुस्तकालय लोकप्रिय हो जाता है और अधिक समय की आवश्यकता होती है, तो समुदाय के अन्य सदस्यों को अधिकार देने में योगदानकर्ता के रूप में आपकी भूमिका साझा करने के लिए कितना लायक है?

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

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

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

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

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

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

यूजीन: आठ साल पहले, जब मैं सी ++ डेवलपर था, तब ऐसा कोई खुला स्रोत समुदाय नहीं था। और अब वेब और जावास्क्रिप्ट की दुनिया में, मैं देख रहा हूं कि खुला स्रोत तेजी से और तेजी से विकसित हो रहा है। क्या यह विकास जारी रहेगा?

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

यूजीन: तो आपको लगता है कि एक ओपन सोर्स लाइब्रेरी विकसित करने से इंटरव्यू में मदद मिल सकती है?

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

दिमित्री: हमने सामान्य रूप से खुले स्रोत के बारे में बात की, चलो विशेष रूप से MobX पर चलते हैं। आपने शुरुआत में इसे कैसे और क्यों करना शुरू किया?

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

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

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

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

दिमित्री: यह है, अगर मुझे किसी तरह का दृष्टिकोण पसंद है, लेकिन मौजूदा पुस्तकालय पर्याप्त अच्छे नहीं हैं, तो आप बस ले सकते हैं और बेहतर कर सकते हैं, और यह लोकप्रिय हो सकता है?

- हाँ, बिल्कुल! इसलिए मैंने इसे शुरू में अपने आंतरिक उद्देश्यों के लिए लिखा था, और फिर रिएक्टएयरोप में चला गया। यह 2015 की बात लगती है, और फ्लक्स पैटर्न के बारे में बहुत बात हुई थी। तब फ्लक्स युद्धों ने हंगामा किया। और मुझे लगा कि लोगों ने बहुत सारी ऊर्जा एक समस्या में डाल दी है, जिसे हम पहले ही हल कर चुके हैं। « ». . , « Flux», - . .

: MobX , . , ?

— ! « MobX Lite». , MobX, 200 . , . . , . MobX. , — API, . , , API . , MobX 5 MobX 4 , Proxy .

: Proxy. - , . ?

— , , Proxy - , . . Chrome 8, , .

: . , jQuery -, , - . Redux MobX. ?

— , . , jQuery- . , JQuery , . - . jQuery React , , , . . , state definitions .
, , React UI. . , - UI .

: ? , ?

— , . , immutable values. , , immer — , immutable states JS. , state management. , , , . , , , GraphQL, , . …

: -, MobX?

— , , , . . : , to-do list . , , todo. , - , todo- , . . , .

: . . , - . , ?

— , . : , . — , , . , . Docker, . , , , . — « ». -, — , , . , , . — , , - . - -, , . , , . : -, , . .

: ( , ) , , Medium YouTube. ?

— , , — . , . — . , , , … . . , . . , . , , . , , , , - . , . , (, , ) — . , , . .

: . — ?

— . , MobX. , . MobX.

HolyJS 2018 Moscow , 24-25 . state management. .