React: DEV मोड को प्रोडक्शन में शिप न करने के लिए उपयोगकर्ताओं को प्रोत्साहित करने का अन्वेषण करें

संदर्भ के लिए: https://github.com/facebook/react/pull/8782

संदर्भ के लिए हम पहले ही चेतावनी दे चुके हैं यदि हमें पता चलता है कि आपने प्रतिक्रिया के एक DEV संस्करण को छोटा कर दिया है: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

जहां तक ​​​​हम उपयोगकर्ताओं को सूचित करने के लिए समान ह्युरिस्टिक्स पा सकते हैं, और शायद अधिक आक्रामक रूप से एक डीओएम संवाद पॉप अप कर सकते हैं, हमें करना चाहिए।

मैं यह भी स्पष्ट करना चाहता हूं कि हम जो चेतावनियां प्रदान करते हैं वे प्रदर्शन में काफी सुधार कर सकते हैं यदि लोग इस पर ध्यान दें। यह धागा कुछ तर्क बताता है कि इस तथ्य के बाद इसे तैनात करना मुश्किल क्यों है यदि यह डिफ़ॉल्ट नहीं है।

अगर देव मोड में renderToString को कॉल किया जाता है तो मैं एक कंसोल के सुझाव के साथ झंकार करना चाहूंगा। जाहिर है, ज्यादातर स्थितियों में renderToString को नोड में कहा जाता है, जहां हम DOM डायलॉग को अलर्ट या पॉप अप नहीं कर सकते हैं।

दुर्भाग्य से, मैं वास्तव में यह पता लगाने में सक्षम होना चाहता हूं कि न केवल NODE_ENV को production पर सेट किया गया है, बल्कि यह भी कि process.env.NODE_ENV को संकलित किया गया है या नहीं। क्या किसी को ऐसा करने का तरीका पता है?

थ्रेड @sebmarkbage के लिए धन्यवाद और मैं इस तथ्य के बाद तैनाती की कठिनाइयों को स्वीकार करता हूं। मैं वर्तमान चेतावनियों की भी सराहना करता हूं। ऐसा प्रतीत होता है कि कुछ डेवलपर अपनी परिनियोजित साइटों के कंसोल आउटपुट की उतनी बार जांच नहीं कर सकते, जितनी बार वे कर सकते थे। हालांकि यह एक अच्छा पहला कदम है।

जहां तक ​​​​हम उपयोगकर्ताओं को सूचित करने के लिए समान ह्युरिस्टिक्स पा सकते हैं, और शायद अधिक आक्रामक रूप से एक डीओएम संवाद पॉप अप कर सकते हैं, हमें करना चाहिए।

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

विकल्प यह है कि हम मूल पोस्ट में उल्लिखित बिल्ड-टूल/ईएनवी स्तर पर इसे ठीक करने का एक तरीका ढूंढते हैं। यह आवश्यक होने पर किसी भी डोम-इंजेक्शन से बच जाएगा।

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

@thelarkinn प्रस्ताव कर रहा था कि हमने इस तरह से मैसेजिंग का पता लगाने की बेहतर सुविधा के लिए आवश्यक ENV कॉन्फिग को मानकीकृत करने की कोशिश की

यह इसे संबोधित करने के लिए आदर्श स्थान की तरह लगता है। यह एक बिल्ड इश्यू है और यदि संभव हो तो बिल्ड टूल्स द्वारा संबोधित किया जाना चाहिए।

उपाख्यान: कंसोल में चेतावनियां अतीत में अनदेखी (या अनदेखा) हो गई हैं। मेरे पास यहां कोई कठिन संख्या नहीं है, लेकिन मुझे लगता है कि कंसोल-आधारित चेतावनियां पर्याप्त नहीं हैं। मैं @addyosmani से सहमत हूं कि एक डोम-आधारित चेतावनी एक लंबा सफर तय करेगी।

@surma शायद उन्हें बेहतर दृश्यता के लिए console.warn या console.error का उपयोग करना चाहिए

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

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

हम इस चेतावनी के लिए ऐसी त्रुटि को ट्रिगर करने में सक्षम हो सकते हैं।

मैं ईमानदारी से नहीं सोचता कि console.{error,warn} से अधिक console.log कुछ भी बदल सकता है। जैसा कि मैंने कहा, वह कहानी किस्सा है।

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

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

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

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

कंसोल संदेश के साथ समस्या यह है कि कभी-कभी लोग बहुत सी चीजें लॉग करते हैं, या अन्य चेतावनियां वे अनदेखा करते हैं, और स्क्रॉल के बाद पहला कंसोल संदेश देखना आसान नहीं है ...

अनिवार्य env के साथ, अनिवार्य रूप से बॉयलरप्लेट आदि env var सेट करेंगे ताकि आप इसका उपयोग शुरू कर सकें मुझे डर है: /

मैं ईमानदारी से नहीं सोचता कि कंसोल। {त्रुटि, चेतावनी} कंसोल.लॉग पर कुछ भी बदल गया होगा।

क्या आपको लगता है कि यह डेवलपर्स के साथ एक समस्या है जो सिर्फ कंसोल की जांच नहीं कर रहा है, या कंसोल को चेतावनियों से अधिभारित किया जा रहा है? क्या इसे (आंशिक रूप से) डेवलपर शिक्षा के संबंध में अधिक सामान्य दृष्टिकोण से संबोधित किया जा सकता है?

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

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

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

मैं डेवलपर के चेहरे पर आने के लिए हूं, लेकिन इसे सही जगह पर करना महत्वपूर्ण है। मेरे लिए, यह निर्माण कदम है, उत्पादन नहीं।

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

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

कंसोल संदेश के साथ समस्या यह है कि कभी-कभी लोग बहुत सी चीजें लॉग करते हैं, या अन्य चेतावनियां वे अनदेखा करते हैं, और स्क्रॉल के बाद पहला कंसोल संदेश देखना आसान नहीं है ...

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

समझ में आता है, मैं तर्क समझता हूँ।

शायद कंसोल स्वरूपण का उपयोग करके चीज़ को पॉप आउट कर दें, कम से कम कुछ होगा।

समस्या यह है कि लगभग कोई भी उत्पादन में कंसोल को नहीं देखता है। आप वहां किसी भी फॉन्ट का इस्तेमाल कर सकते हैं और लोग इसे नोटिस नहीं करेंगे।

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

समस्या यह है कि लगभग कोई भी उत्पादन में कंसोल को नहीं देखता है। आप वहां किसी भी फॉन्ट का इस्तेमाल कर सकते हैं और लोग इसे नोटिस नहीं करेंगे।

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

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

@gaearon जैसे बदलाव के लिए खुले रहने के लिए धन्यवाद। भावी रिलीज़ में डिफ़ॉल्ट रूप से किसी संदेश के लिए प्रयास करने पर सहमति प्राप्त करने के लिए क्या करना होगा? मैं

मैं सहमत हूं कि कंसोल चेतावनियां समाधान नहीं हैं और एक पृष्ठ-दृश्यमान चेतावनी बहुत बेहतर है।

पृष्ठ-दृश्यमान चेतावनी यह कर सकती है:

• देव को सचेत करें कि साइट देव मोड में है
• लाभों पर दस्तावेज़ों से लिंक करें, और इसके बिना कैसे शिप करें
• संदेश को अक्षम करने के लिए एक लिंक ... मुझे 2 घंटे पता नहीं है?

संदेश को अक्षम करना महत्वपूर्ण है, क्योंकि हो सकता है कि यह पृष्ठ पर कुछ हस्तक्षेप कर रहा हो/कवर कर रहा हो। चूंकि यह सेटिंग लोकलस्टोरेज में स्टोर की जाएगी, चेतावनी अभी भी लाइव सर्वर पर दिखाई देगी क्योंकि यह एक अलग मूल है।

हाँ, यह बहुत भयानक है यदि वास्तविक उपयोगकर्ता इस संदेश को लाइव साइटों पर देखते हैं, लेकिन ऐसा लगता है कि जिस तरह की समस्या देवों को ठीक करने के लिए प्रोत्साहित किया जाएगा, जबकि कुछ देव मोड के प्रदर्शन के मुद्दों के साथ रहने के लिए खुश हैं।

अगर पहली बार मैंने उस चेतावनी को देखा (डीओएम एक में डालें), उत्पादन में था, तो मैं काफी परेशान हो जाऊंगा। चेतावनियां समय से पहले होने की जरूरत है।

@rtorr मेरा सुझाव यह है कि यह तब होता है जब साइट देव मोड में होती है, इसलिए इसे समय से पहले देखा जाना चाहिए जब तक कि मुझे कुछ याद न हो?

@jakearchibald भ्रम के लिए खेद है, मेरा जवाब आपके लिए निर्देशित नहीं था। मैं केवल उस सूत्र को इंगित करना चाहता हूं कि यदि हम 'डोम में डालें' समाधान का उपयोग करते हैं, तो हमें बहुत सावधान रहना चाहिए और सुनिश्चित करना चाहिए कि उपयोगकर्ता किसी चीज़ को धक्का देने से पहले जानते हैं (कुछ कैसे, मुझे यहां कोई अच्छा विचार नहीं है) .

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

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

एक चीज जिसने मुझे अभी मारा है अगर ब्राउज़र में किसी प्रकार का ध्वज होना संभव होगा जिसे आपको devtools को सक्रिय करने के लिए सक्षम करना होगा (शायद उनमें एक बड़ा ओवरले "क्या आप एक डेवलपर हैं? [हां/नहीं]" ) कि पेज पता लगा सकता है और केवल डेवलपर्स के लिए चेतावनी दिखा सकता है। सही शब्दों में कहें तो यह सेल्फ-एक्सएक्सएस हमलों में भी मदद कर सकता है।

एक डोम आधारित चेतावनी जिसे मुझे लगातार अक्षम करना है, ठीक नहीं है, इसे हमेशा के लिए अक्षम करना संभव होना चाहिए

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

मुझे यह भी नहीं लगता कि उत्पादन में एक अनपेक्षित डोम नोड ठीक है।

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

@rtorr

मुझे यह भी नहीं लगता कि उत्पादन में एक अनपेक्षित डोम नोड ठीक है।

क्यों? (मैं यह नहीं कह रहा कि आप गलत हैं, बस आपके कारण जानना चाहेंगे)

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

मुझे खुशी है कि यहां रचनात्मक चर्चा हो रही है। यहां दो समाधान हैं जिन्हें मैं समस्या को हल करते हुए देख सकता हूं। वेबपैक NODE_ENV को निर्दिष्ट करने के लिए बाध्य कर सकता है, जो प्रतिक्रिया तब अधिक आसानी से लोगों को DEV को PROD पर भेजने से बचने के लिए उपयोग कर सकता है, लेकिन यह वेबपैक के लिए एक ब्रेकिंग परिवर्तन होगा। मैं अब शॉन से बात कर रहा हूं कि वेबपैक 3 के लिए ऐसा कुछ कितना व्यवहार्य हो सकता है। रिएक्ट + वेबपैक स्टैक को शुरुआती और पूर्ण अनुकूल रखना कुछ ऐसा है जो मुझे पता है कि दोनों शिविरों की परवाह है।

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

यदि हम अधिक प्रतिक्रिया साइटों को प्राप्त करना चाहते हैं तो एफबी ने जिस तेजी से अनुभव किया है, उस पर काम करने के लिए कुछ देना पड़ सकता है। अगर किसी के पास बेहतर विचार हैं तो कृपया उन्हें सुझाव दें।

@jakearchibald

क्यों? (मैं यह नहीं कह रहा कि आप गलत हैं, बस आपके कारण जानना चाहेंगे)

ऊपर मेरी टिप्पणी पर वापस, जब तक कि हम डेवलपर्स को समय से पहले (जो हल करने के लिए वास्तविक समस्या प्रतीत होती है) को बताने में सक्षम नहीं हैं, मुझे लगता है कि डेवलपर्स को उनके उत्पादन पृष्ठ पर चेतावनी प्रदर्शित करके किसी के उत्पाद का अवमूल्यन करना चरम है। कई मामलों में यह संभावित रूप से देव मोड के प्रदर्शन से अधिक उत्पाद को नुकसान पहुंचा सकता है।

कोई फर्क नहीं पड़ता कि हम क्या करते हैं, कोई उत्पादन में जो कुछ भी डिफ़ॉल्ट है उसे शिप करने जा रहा है, क्यों न उत्पादन को डिफ़ॉल्ट बनाया जाए? देव मोड को उस बिंदु तक क्यों न सुधारें जहां यह इतना बड़ा प्रभाव न हो?

@rtorr https://twitter.com/sebmarkbage/status/820054247496503296

@jakearchibald हाँ, मैं देख रहा हूँ कि दोनों पक्षों में समस्याएँ हैं। मुझे इस धागे में लोगों का विश्वास है कि वे कुछ अच्छा लेकर आएंगे, भले ही आप यही प्रस्ताव दे रहे हों। आप सभी महान FYI हैं। शायद चरम उत्तर है।

यदि उपयोगकर्ता प्रतिक्रिया देव उपकरण चला रहा है तो क्या आप डोम नोड चेतावनी नहीं डाल सकते हैं ताकि सामान्य उपयोगकर्ता इसका अनुभव न करें?

@jakearchibald

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

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

@ डैन-गैंबल मुझे विश्वास है कि प्रतिक्रिया देव उपकरण का उपयोग नहीं करने वाले देव इस चेतावनी के लिए सबसे जरूरी लक्ष्य हैं।

@Pajn संभावित रूप से, मुझे नहीं लगता कि सिर्फ इसलिए कि आप क्रोम एक्सटेंशन डाउनलोड करते हैं, यह स्वचालित रूप से आपको उत्पाद/देव स्विच के बारे में जागरूक करता है

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

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

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

वो भी हर 2 घंटे में? नहीं धन्यवाद। इस तरह की लगातार घबराहट निश्चित रूप से उपयोगकर्ताओं को रिएक्ट में विकसित होने से हतोत्साहित करने वाली है और मुझे ईमानदारी से लगता है कि यह लोगों को अन्य रूपरेखाओं को अपनाने के लिए प्रेरित करेगा। हो सकता है कि क्रोम देव यही चाहते हों?

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

प्रतिक्रिया के बारे में मुझे जो चीज सबसे ज्यादा पसंद है, वह यह है कि यह तब तक कुछ नहीं करता जब तक आप ReactDOM.render(...) पर कॉल नहीं करते हैं और जब आप ऐसा करते हैं, तो यह केवल उस डोम में सामान डालता है जहां आपने इसे बताया था। इसलिए यह इतना अच्छा, अलग, कार्यात्मक पुस्तकालय है।

क्या हमें यह भी पता लगाने की आवश्यकता है कि क्या लोग एक असिंचित बंडल शिपिंग कर रहे हैं? क्या होगा यदि वे कैशिंग नहीं कर रहे हैं जब उन्हें करना चाहिए? क्या होगा जब उन्होंने nginx को बेहतर तरीके से कॉन्फ़िगर नहीं किया है? या shouldComponentUpdate का उपयोग न करें जब उन्हें करना चाहिए? या अनावश्यक रूप से सब कुछ प्रदान कर रहे हैं जब उन्हें आवश्यकता नहीं है?

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

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

NODE_ENV सेटिंग को मजबूर करने वाले वेबपैक के संबंध में (शायद इसके लिए उनके रेपो में पहले से ही कोई समस्या है), क्या इससे पुस्तकालयों का उपयोग करना कठिन नहीं होगा जो एनवी सेटिंग्स पर भरोसा नहीं करते हैं?

या यह विचार है कि यह NODE_ENV के उपयोग का पता लगाएगा और इसे तभी लागू करेगा जब कोड इसका उपयोग करेगा?

आइए "2 घंटे" की बात पर बहुत अधिक न उलझें। यह किसी भी समय की अवधि हो सकती है जब तक यह काम करता है।

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

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

निश्चित रूप से, यह खराब कैशिंग हेडर आदि का पता नहीं लगाएगा, यह केवल "देव मोड" का पता लगाने के बारे में है। इसके अलावा "फिसलन ढलान" तर्क सहायक नहीं हैं।

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

यह केवल बेंचमार्क के बारे में नहीं है, यह वास्तविक वेबसाइटों के बारे में है, वास्तविक उपयोगकर्ताओं के लिए धीमी गति से चल रहा है, क्योंकि एक स्विच स्विच नहीं किया गया था।

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

हालांकि यह मुख्य बात है जो मैं कहना चाहता था: कुछ दिनों में मैं 5-10 अलग-अलग स्थानों पर रिएक्ट देव मोड का उपयोग करूंगा, जैसे कि jsbin, ट्यूटोरियल, और यहां तक ​​​​कि एक छोटी परीक्षण साइट को एक साथ फेंकना और इसे फ़ाइल के साथ खोलना: // प्रोटोकॉल। एक मजबूर इन-ब्राउज़र चेतावनी इस प्रकार के लचीले विकास के लिए शत्रुतापूर्ण है, जो कि वेब पर बहुत अच्छा है। मैं इन चेतावनियों को हर जगह देख रहा हूँ क्योंकि मैं वेब पर सभी डोमेन में प्रतिक्रिया सीख रहा हूँ।

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

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

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

आप इसे धोखा देने के लिए localStorage पर भरोसा नहीं कर सकते। इस बात की कोई गारंटी नहीं है कि localStorage (या कोई अन्य स्थानीय स्थायी डेटा) किसी भी अंतराल पर साफ़ नहीं किया जाएगा।

संपादित करें : साथ ही, प्रत्येक {INTERVAL} में केवल एक बार त्रुटि प्रदर्शित करके अब आपने इसे पुन: पेश करना और डीबग करना अधिक कठिन बना दिया है क्योंकि यह निश्चित रूप से पुनरुत्पादित नहीं है।

ऐसे 2 मामले हैं जिन्हें हल करने की आवश्यकता है:

• झूठे बेंचमार्क, प्रदर्शन परीक्षण रोकें: एक बड़े बड़े कंसोल संदेश के साथ आसानी से हल किया गया।
• DEV को उत्पादन स्थलों पर भेजने से रोकें: लोग उत्पादों में devtools नहीं खोलते हैं।

डोम को छूने के खिलाफ तर्क ठोस हैं।

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

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

मैं https://github.com/facebook/react/pull/8782 के बारे में झिझक रहा था क्योंकि आम तौर पर लोग चेतावनियों को पसंद नहीं करते जिससे वे छुटकारा नहीं पा सकते (देखें https://github.com/facebook/react/issues/ 3877), लेकिन विकल्पों को देखते हुए यह एक स्वीकार्य समाधान हो सकता है।

जिज्ञासु। क्या लोकलस्टोरेज का उपयोग उस साइट पर ईयू कुकी कानून लागू करेगा जो अन्यथा इसके द्वारा कवर नहीं किया गया है?

यदि विकास के दौरान सूचनात्मक चेतावनी एक अच्छा विचार है, तो अन्य पुस्तकालय ऐसा क्यों नहीं कर रहे हैं? खैर, इस तरह की समस्याओं का एक कारण है। अगर अन्य ऐसा करना चाहते हैं तो क्या उन्हें भी इसी तरह के UI को पॉप अप करना चाहिए? क्या आपको उन सभी को बंद करना है?

मुझे ऐसा लगता है कि इसे संभालने के लिए कुछ और केंद्रीय होना आदर्श होगा।

शायद क्रोम में विकास मोड हो सकता है? पुस्तकालय मेजबान को बता सकते हैं कि वे विकास मोड में हैं और फिर क्रोम एक बैज जोड़ सकता है या यह इंगित करने के लिए पॉप अप कर सकता है।

मुझे लगता है कि देव मोड में प्रतिक्रिया का उपयोग कर पृष्ठ खोलते समय एक अधिसूचना या कुछ स्पष्ट प्रदर्शित करने के लिए प्रतिक्रिया devtools एक्सटेंशन का लाभ उठाया जा सकता है?

@sebmarkbage

यदि विकास के दौरान सूचनात्मक चेतावनी एक अच्छा विचार है, तो अन्य पुस्तकालय ऐसा क्यों नहीं कर रहे हैं?

मुझे लगता है कि किसी को पहले होने की जरूरत है। कोणीय में एक समान समस्या है, http://code.gov जैसी सामग्री देव मोड में लॉन्च हो रही है। यदि रिएक्ट इस सामान को पकड़ना शुरू कर देता है जहां अन्य ढांचे नहीं हैं, तो मैं उनके लिए समान परिवर्तन करने के लिए दबाव डालूंगा।

मैं उन पर इसी तरह के बदलाव करने के लिए दबाव डालूंगा।

@jakearchibald क्या आप सुझाव दे रहे हैं कि प्रत्येक ढांचे को अपनी चेतावनी देनी चाहिए? मुझे नहीं लगता कि उत्पादन में अपनी विकास चेतावनियां प्रदान करने वाले ढांचे/पुस्तकालयों के लिए मानक स्थापित करना एक अच्छा विचार है। क्या हमें मंच पर मानकीकरण करने की कोशिश नहीं करनी चाहिए? जैसा कि @sebmarkbage . ने बताया है

शायद क्रोम में विकास मोड हो सकता है? पुस्तकालय मेजबान को बता सकते हैं कि वे विकास मोड में हैं और फिर क्रोम एक बैज जोड़ सकता है या यह इंगित करने के लिए पॉप अप कर सकता है।

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

क्या ब्राउज़र विक्रेताओं द्वारा ऐसी किसी चीज़ को लागू करने की प्रतीक्षा नहीं की जा रही है जिसमें समय लगने वाला है?

@jide हाँ, लेकिन इस समस्या को जल्दी से सही तरीके से संबोधित करना अधिक महत्वपूर्ण है। साथ ही, मानकीकरण प्रयासों (यदि आवश्यक हो) पर विचार करने से पहले इसे एक ब्राउज़र में लागू किया जा सकता है।

@ डरपोक

क्या आप सुझाव दे रहे हैं कि प्रत्येक ढांचे को अपनी चेतावनी देनी चाहिए?

यह देखते हुए कि प्रत्येक ढांचा अपना स्वयं का देव मोड प्रदान करता है (और वह मोड ढांचे के बीच बहुत भिन्न हो सकता है), यह पूरी तरह से उचित लगता है कि ढांचे को इसी तरह के अनूठे तरीके से चेतावनी को लागू करना चाहिए।

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

@gaearon Chrome DevTools की ओर, हम एक लाइव "उल्लंघन API" पर विचार कर रहे हैं जिसका उपयोग वेब प्लेटफ़ॉर्म और फ्रेमवर्क लेखक महत्वपूर्ण चेतावनियों को संकेत देने के लिए कर सकते हैं। इन्हें आगामी ऑडिट पैनल रिफ्रेश की तरह कहीं प्रस्तुत किया जाएगा। यह आपके पूछने के समान लगता है और इसका उपयोग DEV मोड डिटेक्शन पर चेतावनी को ट्रिगर करने के लिए किया जा सकता है।

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

Fwiw, मेरा अनुमान है कि यह API कुछ और महीनों के लिए तैयार नहीं होगा। जब यह होगा, तो यह शुरुआत में केवल कैनरी में उपलब्ध होगा और फिर 6-7 सप्ताह बाद यह स्थिर हो सकता है।

एक डोम चेतावनी न केवल सरल, बल्कि अधिक प्रभावी लगती है।

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

यह देखते हुए कि प्रत्येक ढांचा अपना स्वयं का देव मोड प्रदान करता है (और वह मोड ढांचे के बीच बहुत भिन्न हो सकता है), यह पूरी तरह से उचित लगता है कि ढांचे को इसी तरह के अनूठे तरीके से चेतावनी को लागू करना चाहिए।

@jakearchibald आप महसूस करते हैं कि उस मानक का अर्थ है कि कई ढांचे (या सूट में आने वाले पुस्तकालयों) का उपयोग करने वाले पृष्ठों के परिणामस्वरूप उपयोगकर्ताओं को समाप्त करने के लिए गैर-निर्धारिती रूप से प्रदान की गई गुप्त चेतावनियों की मनमानी मात्रा में परिणाम हो सकता है?

पृष्ठ पर devtools को उजागर करने से बचने के लिए ब्राउज़र कुछ हद तक चले गए हैं।

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

एक डोम चेतावनी न केवल सरल, बल्कि अधिक प्रभावी लगती है।

कोई भी समाधान की सादगी या प्रभावशीलता के खिलाफ बहस नहीं कर रहा है। यह काम करेगा , लेकिन उपयोगकर्ता अनुभव से समझौता करने की कीमत पर। गति ही एकमात्र ऐसी चीज नहीं है जो उपयोगकर्ताओं को नकारात्मक रूप से प्रभावित कर सकती है।

Fwiw, मेरा अनुमान है कि यह API कुछ और महीनों के लिए तैयार नहीं होगा। जब यह होगा, तो यह शुरुआत में केवल कैनरी में उपलब्ध होगा और फिर 6-7 सप्ताह बाद यह स्थिर हो सकता है।

@addyosmani अगर यह एक बेहतर समाधान है, तो मैं नहीं देखता कि यह एक मुद्दा कैसे होगा। रिएक्ट में कोई भी बदलाव एक प्रमुख रिलीज में होगा, जो मुझे लगता है कि टीबीडी है जहां तक ​​रिलीज का समय वैसे भी जाता है।

तय किया गया समाधान संभावित रूप से भविष्य के सभी विकास को प्रभावित करेगा। उस संदर्भ में हफ्तों बनाम महीनों का मामला स्वीकार्य आईएमओ है।

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

@awery : यदि कोई "सुरक्षा-केंद्रित" साइट कभी भी DevMode में लॉन्च होती है, तो उन्हें तब तक भरोसा नहीं करना चाहिए जब तक कि वे समस्या को ठीक नहीं कर देते। “DevMode” में सुरक्षा से संबंधित सभी प्रकार के शॉर्टकट शामिल हो सकते हैं जैसे अक्षम CORS चेक या एक्सपोज़्ड टेम्प्लेट सोर्स कोड आदि। यदि कोई साइट सुरक्षा-केंद्रित है, तो ऐसा नहीं होना चाहिए।

(मुझे एहसास है कि प्रतिक्रिया में "देवमोड" का एक बहुत ही विशिष्ट अर्थ है, लेकिन मैं यहां एक गैर-डेवलपर के परिप्रेक्ष्य को मानने की कोशिश कर रहा हूं)

@ डरपोक

आप महसूस करते हैं कि मानक का अर्थ है कि एकाधिक ढांचे का उपयोग करने वाले पृष्ठों के परिणामस्वरूप उपयोगकर्ताओं को समाप्त करने के लिए गैर-निर्धारिती रूप से प्रदान की गई गुप्त चेतावनियों की मनमानी मात्रा में परिणाम हो सकता है?

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

गति ही एकमात्र ऐसी चीज नहीं है जो उपयोगकर्ताओं को नकारात्मक रूप से प्रभावित कर सकती है।

मैं किसी को अन्यथा दावा करते नहीं देखता? मैं इस तरह की प्रतिक्रिया से बहुत दुखी हूं

ऐसा लगता है कि आप चाहते हैं कि यह किसी का ध्यान न जाए और ठीक न हो जाए

@jakearchibald यह एक अजीब निष्कर्ष है, मुझे नहीं लगता कि मैं अपना खाली समय यहां आपके साथ बात करने में बिताऊंगा अगर मैं इसे ठीक नहीं करना चाहता हूं? सिर्फ इसलिए कि मैं आपके समाधान से सहमत नहीं हूं इसका मतलब यह नहीं है कि मैंने इसे अनसुलझा छोड़ने के लिए इस्तीफा दे दिया है। यह वास्तव में अनुचित है।

मैं चाहूंगा कि गैर-डेवलपर्स (डेवलपर्स पर लक्षित दृश्यमान संदेश) के लिए यह इतना बुरा है कि डेवलपर इसे तुरंत ठीक कर देता है, एक बेहतर उपयोगकर्ता अनुभव बनाता है।

मुझे लगता है कि यह मौलिक रूप से अस्वीकार्य है: आप पहले उपयोगकर्ताओं को स्पष्ट रूप से दंडित कर रहे हैं।

यदि कोई "सुरक्षा-केंद्रित" साइट कभी भी DevMode में लॉन्च होती है, तो उन पर तब तक भरोसा नहीं किया जाना चाहिए जब तक कि वे समस्या को ठीक नहीं कर देते।

@सुरमा देव मोड स्वाभाविक रूप से असुरक्षित नहीं है, लेकिन यह मानने के लिए कि यह आपके लिए ठीक है कि आप इसे उपयोगकर्ताओं के साथ संवाद करने के लिए लाइन पर कदम रख रहे हैं।

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

डीओएम में इंजेक्शन कई कारणों से समस्याग्रस्त है। रिएक्ट के लिए यह थोड़ा अधिक संभव है क्योंकि हम एक DOM लाइब्रेरी हैं और हमारे पास DOM एंट्री पॉइंट हैं। पुस्तकालयों के लिए यह कठिन है जो डीओएम विशिष्ट नहीं हैं और एक कार्यकर्ता में चल सकते हैं।

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

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

अगर हमारे पास यह पता लगाने का कोई तरीका है कि आप विकास मोड में नहीं हैं तो हम उस त्रुटि मोड को ट्रिगर कर सकते हैं। हमें वास्तव में स्थायी रूप से विकास मोड में आने के लिए एक ठोस तरीके की आवश्यकता है।

इसी तरह समस्याग्रस्त ssl कॉन्फ़िगरेशन को हाइलाइट किया जाता है।

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

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

DEV मोड को ऑप्ट-इन करने के बारे में क्या?
हम "अच्छे यूएक्स" पक्ष पर गलती करते हैं, क्योंकि खराब डीएक्स नोटिस करना आसान है (और इस तरह के मुद्दों के लिए आईएमएचओ को "जीतना चाहिए" क्योंकि वे नहीं चुन सकते हैं, जबकि देव कर सकते हैं)।
मुझे यकीन है कि कुछ ढांचे पहले से ही ऐसा करते हैं (जैसे रिले अगर मुझे सही याद आती है)।

इसे कैसे लागू किया जाए, इस पर प्रस्ताव:

• विकास मोड तभी सक्षम करें जब NODE_ENV स्पष्ट रूप से development . पर सेट हो
• विकास मोड सक्षम करें यदि वैश्विक __DEV__ === true है
• उपयोगकर्तालैंड में सक्षम होने के लिए डीबग टूल मॉड्यूल निर्यात करें

पहला सबसे अच्छा लगता है क्योंकि अन्य दो को बिना गार्ड के हार्ड-कोड किया जा सकता है (जैसे if(NODE_ENV === 'development') स्टेटमेंट) और इस तरह वैसे भी उत्पादन के लिए भेज दिया जाता है।

@mattecapu के बारे में मेरी दूसरी टिप्पणी देखें। https://twitter.com/sebmarkbage/status/820047144677584896

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

यहां टिप्पणी करने के लिए बहुत कुछ है, और मेरे पास विचार हैं, लेकिन मैं विशेष रूप से केवल एक देव चेतावनी को अक्षम करने के प्रश्न पर वजन करना चाहता हूं।

मैं उस बटन का बहुत बड़ा प्रशंसक नहीं हूं जो एक विशेष ब्राउज़र में निर्धारित समय के लिए DOM चेतावनी को अक्षम करता है। जैसा कि @jlongster बताते हैं, अगर यह अक्सर होता है तो यह देवों के लिए दर्द होता है। लेकिन मेरे लिए सबसे महत्वपूर्ण बात यह है कि यह व्यवहार में ब्राउज़र-विशिष्ट परिवर्तनशीलता का परिचय देता है, जो आसानी से "लेकिन यह मेरी मशीन पर ठीक काम करता है" बग की अपरिवर्तनीयता का कारण बन सकता है।

मैं रेंडर करने के लिए भेजा गया एक पैरामीटर पसंद करूंगा जो ["localhost", "127.0.0.1"] के डिफ़ॉल्ट मान के साथ देव बॉक्स माने जाने वाले डोमेन को सूचीबद्ध करता है। यह कुछ इस तरह दिखेगा:

React.render(<App/>, 
  myDiv,
  () => { console.log('finished render!'), 
  { devDomains: ["localhost", "devbox.mycorp.com"] }
);

यदि वर्तमान डोमेन सूची में है, तो देव चेतावनी कभी दिखाई नहीं देती है। अन्यथा, यह करता है। इस व्यवस्था के तहत:

• localhost या 127.0.0.1 का उपयोग करके अपनी स्थानीय मशीन पर देव बिल्ड का उपयोग करना : कभी भी कोई डेवलपर चेतावनी नहीं, और किसी डेवलपर कार्रवाई की आवश्यकता नहीं है।
• किसी अन्य होस्ट नाम का उपयोग करके एक देव मशीन पर देव बिल्ड का उपयोग करना : जब तक आप render को दी गई सूची में डोमेन नाम नहीं जोड़ते, तब तक आपको DOM चेतावनी मिलती है। इसके बाद, आपको कभी भी डीओएम चेतावनी नहीं मिलती है।
• प्रोड मशीन पर देव बिल्ड का उपयोग करना : जब तक आप रिएक्ट को प्रोड वर्जन पर स्विच नहीं करते, तब तक आपको DOM चेतावनी मिलती है।

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

@aickin उस दृष्टिकोण के साथ समस्या यह है कि इसके लिए उपयोगकर्ताओं को कॉन्फ़िगरेशन के बारे में पता होना चाहिए और बदले में, समस्या हल हो रही है। मुद्दा यह है कि लोगों को पहले स्थान पर देव/उत्पाद भेद के बारे में पता नहीं है।

संपादित करें : कोई बात नहीं, मैं देखता हूं, विकास में अभी भी एक डोम चेतावनी है।

सर्वर साइड वातावरण एक "विशेष" त्रुटि पृष्ठ दिखा कर इसे ठीक करता है जिसमें डिबग विवरण शामिल होता है और आपको उत्पादन में इसकी सेवा नहीं करने के लिए भी कहता है।

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

फिर, पहली बार जब उपयोगकर्ता के पास उत्पादन में बग होता है, तो उन्हें एक विशेष वर्बोज़ त्रुटि संदेश दिखाई देगा। यह DEV बिल्ड के बारे में शिक्षित करने का एक अवसर हो सकता है।

लेकिन मुझे लगता है कि पृष्ठ के नीचे एक बैनर की तरह है जो कहता है कि "यह साइट देवमोड में है" इसका एक अच्छा समाधान होगा जो उपयोगकर्ता के अनुभव पर बड़ा प्रभाव नहीं डालता है। मैं समझना चाहता हूं कि बहुत से लोग इसके विपरीत क्यों सोचते हैं।

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

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

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

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

मुझे लगता है कि @ropilz ने अपने "_..हम किसी भी सेवा को हम देवों को सूचित करना चाहते हैं .._" टिप्पणी के साथ पहले धागे में छुआ था, लेकिन यह किसी का ध्यान नहीं गया (या स्वीकार नहीं किया गया)।

जैसा कि मैं इसे समझता हूं, यहां हल की जा रही मूलभूत समस्या है

• किसी भी तरह से _डेवलपर्स_ को सतर्क करने के लिए जब उत्पादन _अंत-उपयोगकर्ता_ देव मोड में चल रही साइट का अनुभव करते हैं
• हम उत्पादन में console.log संदेशों (या उस मामले के लिए यहां तक ​​​​कि डोम चेतावनियां) देखने वाले देवों पर भरोसा नहीं कर सकते हैं, _unless_ वे देव सक्रिय रूप से उत्पादन साइट का उपयोग कर रहे हैं (या हम अंतिम उपयोगकर्ताओं पर भरोसा कर रहे हैं, क्यूए/ इन चेतावनियों को वापस डेवलपर को रिपोर्ट करने के लिए सहायता दल आदि)
• ऐसे (वैध) UX तर्क _विरुद्ध_ हैं जो अंतिम उपयोगकर्ताओं को एक DOM दृश्यमान चेतावनी दिखा रहे हैं जो डेवलपर ऑडियंस के लिए अभिप्रेत है।

क्या होगा यदि सीएसपी के report-uri के समान कुछ था, ढांचे के लिए देव मोड चेतावनियां भेजने के लिए, साइट पर इन-सीटू चेतावनी दिखाने के बजाय जहां वे अंतिम उपयोगकर्ताओं के लिए दृश्यमान होंगे?

स्पष्ट रूप से कई बातों पर विचार किया जाना है, जैसे:

1. ऐसी रिपोर्टिंग आदर्श रूप से डिफ़ॉल्ट रूप से चालू होगी, लेकिन डिफ़ॉल्ट report-uri क्या होगा? (क्या हम उम्मीद करेंगे कि प्रत्येक फ्रेमवर्क https://report-uri.io के समान अपनी स्वयं की मुफ्त सेवा की मेजबानी करेगा? (यह _may_ बड़े, कंपनी-प्रायोजित फ्रेमवर्क जैसे रिएक्ट और एंगुलर के लिए संभव है, लेकिन निश्चित रूप से छोटे ओपन-सोर्स फ्रेमवर्क के लिए अव्यावहारिक है। जैसे Preact, Vue आदि)
2. एक बार चेतावनी की सूचना मिलने के बाद, साइट के स्वामी/डेवलपर को कैसे सूचित किया जाता है? (शायद गैर-देवताओं के लिए एक परियोजना में शामिल होने का एक अच्छा तरीका है, स्वेच्छा से इन रिपोर्टों की निगरानी करने और अनुरक्षक को ट्रैक करने/सूचित करने में मदद करने के लिए?)

मैं पूरी तरह से मानता हूं कि यह सुझाव केवल एक विचार-बुलबुला है, और मैंने इस पर विचार नहीं किया है कि यह कितना व्यावहारिक होगा या यह वास्तव में कैसे काम करेगा; लेकिन मैं इसे उठाना चाहता था क्योंकि मुझे लगता है कि सीएसपी/एचपीकेपी रिपोर्टिंग के लिए 'उत्पादन मुद्दों पर रिपोर्टिंग' की चुनौती पहले ही आंशिक रूप से हल हो चुकी है, और शायद हम यहां कुछ इसी तरह का पता लगा सकते हैं?

एक कदम पीछे हटना और यह महसूस करना महत्वपूर्ण है कि प्रतिक्रिया एक ढांचा है। आपको नहीं करना चाहिए :

• डेवलपर्स के लिए अनुस्मारक के रूप में कुछ दृश्यमान रूप से प्रस्तुत करने के लिए डीओएम को संशोधित करें। ऐसा कोई तरीका नहीं है जो बॉक्स से बाहर काम करता है जब तक कि आप कुछ ऐसा नहीं समझते और विकसित करते हैं जो डेवलपर्स को बाधित किए बिना सभी वातावरणों में काम कर सकता है और अपने उपयोगकर्ता के विश्वास को खोने के लिए उत्पादन में पॉप अप होना चाहिए (यदि मेरा अनुभव कोई संकेत है तो यह होगा बहुत बार और कई इसे बंद करने के लिए त्वरित सुधार को लागू करने में सक्षम नहीं होंगे)।

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

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

यह डेवलपर्स को बेबीसिट करने के लिए रिएक्ट का काम नहीं है। मैं या तो प्रस्ताव करता हूं:

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

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

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

ऐसे कई पुस्तकालय हैं जो डेवलपर्स उपयोग करते हैं जिनके पास शायद अपना स्वयं का देव मोड है। मुझे लगता है कि process.env.NODE_ENV को production पर सेट करना ब्राउज़र के मॉड्यूल को बंडल करने में पहले से ही एक सामान्य मानक रहा है। इसके लिए हमें जागरूकता बढ़ाने की जरूरत है।

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

शुरुआती आमतौर पर उन्नत मार्गदर्शिकाएँ नहीं पढ़ते हैं, लेकिन यदि शीर्षक पर्याप्त स्पष्ट है और महत्वपूर्ण लगता है तो वे त्वरित प्रारंभ में कुछ लिंक खोलेंगे। मुझे पता है कि मैंने ऐसा इसलिए किया क्योंकि जब मैं रिएक्ट सीखना शुरू करता हूं तो मैं यही करता हूं। मैंने आरंभ करना मार्गदर्शिका नहीं पढ़ी, लेकिन मैंने त्वरित प्रारंभ अनुभाग में कुछ पृष्ठ पढ़े हैं।

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

http://code.gov कंसोल चेतावनियों के बावजूद लॉन्च किया गया। यह ठीक उसी तरह की चीज है जिसे हमें रोकने का लक्ष्य रखना चाहिए। (वह साइट कोणीय है, लेकिन वही प्रतिक्रिया पर लागू होती है)

अगर कोई उन तक पहुंचना चाहता है (या पीआर भेजना चाहता है): https://github.com/presidential-innovation-fellows/code-gov-web/issues/221

Angular 2 is running in the development mode. Call enableProdMode() to enable the production mode.

मैंने पहले कभी कोणीय 2 का उपयोग नहीं किया है (जो मुझे इस मामले में शुरुआती बनाता है)। चेतावनी देखने के बाद मेरी प्रारंभिक प्रतिक्रिया यह है कि मैं बस enableProdMode() पर कॉल करने का प्रयास करता हूं। यह काम नहीं करता। मुझे लगता है कि कोणीय मामले के लिए कंसोल संदेश में सुधार किया जा सकता है। उन्हें जादू पर भरोसा करने के बजाय डॉक्स की ओर इशारा करना चाहिए।

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

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

इसे टूलींग स्तर पर संबोधित किया जाना चाहिए, इसलिए संभवतः वेबपैक और बैबेल डेवलपर्स को NODE_ENV सेट करने के लाभों के बारे में सूचित कर सकते हैं।

@pveyes सहमत, मैंने कोणीय टीम को एक ही बिंदु बनाया है।

@matthewp इस https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 के बारे में बहुत पुराना मुद्दा है और कोणीय टीम सीधे पहुंच गई है और उन्हें ठीक कर दिया है - ऐसा लगता है इसे लागू करने की इच्छा कम है। सवाल यह है कि क्या DOM चेतावनी ने इसे और अधिक जरूरी बना दिया होगा, या इसे शुरू करने के लिए देव मोड में लॉन्च करने से रोका होगा?

सवाल यह है कि क्या DOM चेतावनी ने इसे और अधिक जरूरी बना दिया होगा, या इसे शुरू करने के लिए देव मोड में लॉन्च करने से रोका होगा?

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

तो आप जंक कोड के एक समूह के साथ समाप्त हो जाते हैं जो इस चीज़ को अक्षम कर देता है जो साइट के यूएक्स के साथ खराब हो जाता है। यह उस मूल इंजीनियर की तरह नहीं है जिसने इसे विकास के दौरान अक्षम कर दिया था या तो उसे याद रखना होगा; हो सकता है कि वे उत्पादन में जाने से पहले ही आगे बढ़ गए हों।

मुझे यकीन नहीं है कि परिनियोजन प्रक्रिया code.gov पर कैसे काम करती है, लेकिन अगर यह कुछ ऐसा है जो मैंने एक सरकारी ठेकेदार के रूप में अनुभव किया है, तो उत्पादन में एक आकस्मिक विकास मोड परिनियोजन या तो होगा:

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

2. यह उपयोगकर्ताओं द्वारा देखा जाएगा, इसे ठीक किया जाएगा, लेकिन चूंकि यह संभवतः फ़ंक्शन को प्रभावित नहीं कर रहा है, अगली तैनाती विंडो तक अपडेट नहीं होगा। तो सभी यूजर्स को इसे हफ्तों या महीनों तक देखने को मिलता है।

मुझे ऐसा अनुभव हुआ। बिंदु यह है कि, भले ही तैनाती के तुरंत बाद एक डोम घुसपैठ देखा जाता है, आप नहीं जानते कि उनकी आधारभूत संरचना/प्रक्रिया कैसी है और यह कुछ ऐसा नहीं हो सकता है जिसे वे तुरंत ठीक कर सकें (भले ही वे सक्षम हों)।

#7360 (पीला बॉक्स) विलय होने पर चेतावनी संदेश अधिक ध्यान देने योग्य होंगे। हम पीले बॉक्स में एक संदेश भी जोड़ सकते हैं (इसे "प्रतिक्रिया विकास मोड चेतावनी" कहते हैं?)

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

यह स्थापना पृष्ठ पर सही है:

https://facebook.github.io/react/docs/installation.html#Development -and-production-versions

और प्रदर्शन के अनुकूलन पर:

https://facebook.github.io/react/docs/optimizing-performance.html#use -the-production-build

मुझे नहीं लगता कि यह कहना उचित होगा कि डॉक्स इसके बारे में आगे नहीं हैं।

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

यह वहीं है, पहले पृष्ठ पर (स्थापना):

https://facebook.github.io/react/docs/installation.html#Development -and-production-versions

तुम सही कह रही हो। माफ करना मेरा बुरा। मुझे लगता है कि प्रोडक्शन बिल्ड अलग-अलग सेक्शन में है इसलिए मैंने वहां नहीं देखा और इसके बजाय साइडबार में प्रासंगिक शीर्षक की खोज की (और ऑप्टिमाइज़िंग परफॉर्मेंस पेज पाया)। मुझे बेहतर पता होना चाहिए था।

मैं वास्तव में प्रतिक्रिया के लिए शुरुआत नहीं कर रहा हूं, इसलिए जब मैं अपनी धारणा को सत्यापित करने के लिए दस्तावेज़ खोलता हूं - कि प्रतिक्रिया दस्तावेज़ उत्पाद बनाम देव के बारे में अग्रिम नहीं है - मैंने स्थापना दस्तावेज़ नहीं खोले

चिंता न करें। यदि यह पर्याप्त रूप से दिखाई नहीं दे रहा है तो मैं बेहतर प्लेसमेंट के लिए सुझावों के लिए तैयार हूं। उदाहरण के लिए हम इसके लिए एक समर्पित पेज बना सकते हैं ( Deploying to Production )।

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

इसका पता लगाने और सूचित करने का एकमात्र वास्तविक तरीका है।

@KrisSiegel फ़ेविकॉन को कैश किया जाना एक अच्छा बिंदु है। मुझे आश्चर्य है कि क्या हमें इसे एक या दो सेकंड के बाद स्विच करना चाहिए और फिर इसे हर कुछ सेकंड में संक्षिप्त रूप से फ़्लिप करना चाहिए। इस तरह कैशिंग और बुकमार्क करने की समस्या के ओवरराइड किए गए आइकन के समय समय पर होने की संभावना बहुत कम है।

मैंने सोचा था कि फ़ेविकॉन के लिए जे एस जोड़तोड़ कैश नहीं मिलता है, लेकिन शायद मैं गलत हूँ।

मेरा तर्क है कि इसके लिए हुक रखने का सही स्थान क्रोम या फ़ायरफ़ॉक्स नहीं है, बल्कि वेबपैक, ब्राउजराइज़ या रोलअप है।

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

@taion मैं सहमत हूँ। मुझे लगता है कि यह निश्चित रूप से बिल्ड टूल में है, डीओएम में नहीं।

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

यदि टर्मिनल में npm run build चलाया जाता है, और env उत्पादन के लिए सेट नहीं है, तो आपको डिफ़ॉल्ट आउटपुट के साथ टर्मिनल में एक लाल चेतावनी मिलनी चाहिए: env is not set to production, some scripts may be in development mode

वर्तमान में मुझे वेबपैक से ऐसी कोई चेतावनी नहीं मिलती है।

संपादित करें: जोड़ा स्पष्टीकरण

या बस वास्तव में आपके लिए NODE_ENV सेट करें।

अगर कंसोल चेतावनियां काम नहीं कर रही हैं, तो मुझे यकीन नहीं है कि चेतावनियां बनाएंगी।

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

@jakearchibald मुझे यकीन है कि इसे अभी भी कुछ लोगों द्वारा अनदेखा कर दिया जाएगा, लेकिन कम से कम चेतावनी उन्हें तब दिखाई जाएगी जब वे इसे बनाते हैं, नहीं देखा जा रहा है क्योंकि चेतावनी ब्राउज़र कंसोल में छिपी हुई है जिसे वे कभी भी उत्पादन में नहीं खोल सकते हैं . सबसे महत्वपूर्ण बात यह है कि यह कम अनुभव वाले लोगों को इस बारे में एक सुराग देता है कि कोड उत्पादन तैयार करने के लिए उन्हें क्या करना चाहिए।

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

रिएक्ट के लिए प्रोडक्शन बंडल के रूप में जो इरादा है उसका निर्माण करना, लेकिन प्रोडक्शन मोड को सक्षम किए बिना बस यही है - एक बिल्ड एरर।

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

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

@taion किसी ऐसे व्यक्ति के रूप में जो केवल बिल्ड-ओनली समाधान का समर्थन करता है, क्या आपको लगता है कि यह कवर करने के लिए एक महत्वपूर्ण उपयोग का मामला है?

दूसरे लोग क्या सोचते हैं?

मुझे लगता है कि दस्तावेज़ीकरण बहुत स्पष्ट है कि आपको उत्पादन के लिए .min.js बंडलों का उपयोग करना चाहिए। हो सकता है कि यह एक बोल्ड, एक बड़ा फ़ॉन्ट आकार, ऐसा कुछ उपयोग कर सके। लेकिन अगर कोई अपनी वेबसाइट के लिए अनमिनिफाइड रिएक्ट बंडल का उपयोग कर रहा है, तो उन्हें वैसे भी अन्य समस्याएं हैं।

मुझे लगता है कि दस्तावेज़ीकरण बहुत स्पष्ट है कि आपको उत्पादन के लिए .min.js बंडलों का उपयोग करना चाहिए।

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

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

मुझे लगता है कि सीडीएन + देव कॉन्फ़िगरेशन अधिक स्पष्ट रूप से गलत है, इसमें उपयोगकर्ता को रिएक्ट के एक असीमित निर्माण का उपयोग करने की आवश्यकता होती है। इस तरह से असफल होना कठिन है क्योंकि _सिर्फ मिनीफाइड बिल्ड का उपयोग करने के लिए आवश्यक ज्ञान का बोझ कम है।

कॉन्फ़िगरेशन जहां आप _थिंक_ चीजें उत्पादन-तैयार हैं क्योंकि आपने वेबपैक या ब्राउजर में मिनीफिकेशन चलाया है लेकिन वास्तव में आप नहीं हैं क्योंकि आपने NODE_ENV सेट नहीं किया है - आप इसे सीडीएन बंडलों के माध्यम से प्राप्त नहीं कर सकते हैं।

मुझे लगता है कि React टैब पर Chrome Developer Tools यह बताने के लिए पर्याप्त है कि क्या हम DEV Mode में हैं।

मुझे लगता है कि यह ध्यान देने योग्य है कि एक डीओएम तत्व को देव मोड में पृष्ठ में इंजेक्ट करने वाले ढांचे के लिए कुछ उदाहरण है:

http://symfony.com/blog/new-in-symfony-2-8-redesigned-web-debug-toolbar

हालाँकि जहाँ तक मैं बता सकता हूँ मुझे नहीं लगता कि यह डिफ़ॉल्ट रूप से चालू है।

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

समस्या को फिर से बताने का प्रयास करने के लिए:

• रिएक्ट साइटों की एक गैर-शून्य संख्या इसे विकास मोड अक्षम किए बिना उत्पादन के लिए बनाती है
• हम इस संख्या को कम करना चाहेंगे
• हम प्रतिक्रिया डेवलपर्स को परेशान नहीं करना चाहते हैं
• हम नए लोगों को रिएक्ट करने से नहीं रोकना चाहते हैं
• हम नहीं चाहते कि रिएक्ट में निर्मित साइटों के अंतिम उपयोगकर्ता सिप्टिक डेवलपर चेतावनियां देखें
• हम विदेशी डोम तत्वों की उपस्थिति के कारण साइटों को तोड़ना नहीं चाहते हैं

इन्हें देखते हुए, मुझे लगता है कि देव मोड में प्रतिक्रिया के लिए एक अच्छा पहला कदम यह घोषणा करना होगा कि यह console.warn या console.info के माध्यम से देव मोड में है, यह सुनिश्चित करने के निर्देश के साथ कि यह उत्पादन के लिए अक्षम है तैनाती।

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

इन्हें देखते हुए, मुझे लगता है कि देव मोड में प्रतिक्रिया के लिए एक अच्छा पहला कदम यह घोषणा करना होगा कि यह कंसोल.वार्न या कंसोल.इन्फो के माध्यम से देव मोड में है, यह सुनिश्चित करने के निर्देश के साथ कि यह उत्पादन परिनियोजन के लिए अक्षम है।

विकास मोड में होना गलत नहीं है, हालांकि जब आप... विकास कर रहे होते हैं। हम किन अन्य अनुमानों का उपयोग कर सकते हैं?

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

विकास मोड में होना गलत नहीं है, हालांकि जब आप... विकास कर रहे होते हैं। हम किन अन्य अनुमानों का उपयोग कर सकते हैं?

मुझे लगता है कि यह वर्तमान प्रतिक्रिया DevTools नोटिस के समान होना चाहिए

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

जैसा कि आप कहते हैं, लगभग किसी को भी वास्तविक उत्पादन में कंसोल चेतावनी नहीं दिखाई देगी - और उस समय तक यह थोड़ा देर हो चुकी है।

एक अटके हुए रिकॉर्ड की तरह लगने के लिए खेद है, लेकिन कंसोल चेतावनियां काम नहीं करती हैं। जैसे https://code.gov।

एक अटके हुए रिकॉर्ड की तरह लगने के लिए खेद है, लेकिन कंसोल चेतावनियां काम नहीं करती हैं। जैसे https://code.gov।

एक एकल प्रति-उदाहरण से पता चलता है कि यह अचूक नहीं है - लेकिन मुझे नहीं लगता कि कोई दृष्टिकोण होगा।

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

@jakearchibald

हां, लेकिन अगर code.gov के बिल्ड टूल को यहां हुक के साथ सेट किया गया था, तो उस _उस समस्या को रोका जा सकता है जिसे आप देख रहे हैं, कम से कम रिएक्ट के संदर्भ में जो इसके लिए बिल्ड-टाइम हुक का उपयोग करता है। आखिर वे वेबपैक का इस्तेमाल कर रहे हैं।

मैं यह नहीं कह रहा हूं कि वेबपैक को बिल्ड चेतावनी का उत्सर्जन करना चाहिए। मैं कह रहा हूं कि सही फिक्स यह है कि या तो वेबपैक आपके लिए process.NODE_ENV सेट करता है, या यदि आप उचित उत्पादन कॉन्फ़िगरेशन के बिना उत्पादन निर्माण करने का प्रयास करते हैं तो वेबपैक डिफ़ॉल्ट रूप से निर्माण में विफल रहता है।

DevTools "उल्लंघन" के बारे में @addyosmani के एक पुराने बिंदु पर तुरंत प्रतिक्रिया देना चाहता था। हम क्रोम DevTools में कुछ त्रुटियों के मजबूत संकेत दिखा रहे हैं, लेकिन यह काम अभी भी बहुत जल्दी है, और मैं @jakearchibald से सहमत हूं कि एक चेतावनी दिखा रहा है (भले ही यह console.warn से अधिक डरावना हो) नहीं है एक अच्छा पर्याप्त समाधान।

रिएक्ट टू प्रोडक्शन मोड को डिफॉल्ट करने और डेवलपमेंट मोड को चालू करने के बारे में क्या और केवल अगर NODE_ENV == 'development' या होस्टनाम localhost / 127.0.0.1 है? अधिकांश डेवलपर्स को आउट-ऑफ-द-बॉक्स सही व्यवहार मिलेगा और यदि आपको वास्तव में आवश्यकता हो तो विकास मोड को मैन्युअल रूप से लागू करने का एक तरीका हमेशा होगा।

आदर्श से कम अभी भी उस शाखा को मारने के लिए आदर्श से कम लगता है जो काफी जटिल सशर्त हो सकता है (क्योंकि आपको नोड पर असफल होने की आवश्यकता नहीं होगी) हर समय।

वेबपैक 2 में BTW, -p ("उत्पादन" मोड, जो डिफ़ॉल्ट सेटिंग्स के साथ न्यूनतमीकरण को भी सक्षम बनाता है) उपयोगकर्ताओं के लिए NODE_ENV सेट करता है: https://webpack.js.org/guides/production-build /#नोड -पर्यावरण-चर।

यह मेरे लिए काफी समझदार लगता है, और वेबपैक का उपयोग करने वाले लगभग सभी के लिए इस समस्या को रोकना चाहिए। रन टाइम में इनमें से किसी को भी संभालने की जिद क्यों?

वेबपैक 2 में BTW, -p ("उत्पादन" मोड, जो डिफ़ॉल्ट सेटिंग्स के साथ न्यूनतमीकरण को भी सक्षम बनाता है) उपयोगकर्ताओं के लिए NODE_ENV सेट करता है: https://webpack.js.org/guides/production-build/#node -environment-variable।

हां। हम इससे वाकिफ हैं। वेबपैक कोर से @TheLarkInn निश्चित रूप से पुष्टि कर सकता है, लेकिन मेरी समझ यह है कि वेबपैक समुदाय एटीएम में -p का व्यापक रूप से उपयोग नहीं किया जाता है। यहां अंतर्निहित मुद्दा यह भी है कि यदि कोई समाधान ऑप्ट-इन है, तो कंसोल.लॉग चेतावनियों के साथ वर्तमान स्थिति के समान, हमें रिएक्ट उपयोगकर्ताओं के लिए वास्तविक परिवर्तन देखने की संभावना नहीं है। हम लोगों को 'तेज़' चीज़ की शिपिंग में बेहतर बदलाव देना चाहते हैं।

यह ध्यान देने योग्य है कि वेबपैक में आसानी से DEV और PROD वातावरण का पता लगाने में सक्षम होने की कमी (-p अपर्याप्त होने के कारण) ने हमें https://github.com/webpack/webpack/issues/3216 में कुछ दर्द दिया।

मैं कह रहा हूं कि सही फिक्स यह है कि या तो वेबपैक आपके लिए प्रक्रिया सेट करता है। NODE_ENV, या वह वेबपैक डिफ़ॉल्ट रूप से निर्माण में विफल रहता है यदि आप उचित उत्पादन कॉन्फ़िगरेशन के बिना उत्पादन निर्माण करने का प्रयास करते हैं।

मैं इसे आगे बढ़ाने के लिए तैयार हूं, लेकिन जो मैं बता सकता हूं उससे वेबपैक के लिए यह एक ब्रेकिंग बदलाव होगा। मैं व्यक्तिगत रूप से एक रनटाइम समाधान की तरह महसूस करता हूं जिसमें एक स्पष्ट ओवरले संदेश शामिल है _only_ कुछ बुद्धिमान हेरिस्टिक्स (लोकलहोस्ट, देवटूल ओपन इत्यादि) का उपयोग करके प्रदर्शित किया गया है जो हमें पर्याप्त रूप से कवर करेगा।

उस ने कहा, जैसा कि हम वेबपैक प्रक्रिया पर वापस चक्कर लगाते रहते हैं। NODE_ENV आइटम, मुझे उत्सुकता होगी अगर @sokra या @TheLarkInn की इस पर कोई राय हो।

मेरी समझ वहां आपकी समझ से अलग है - मेरा मानना ​​है कि -p एक वास्तविक तरीका है जिससे वेबपैक के अधिकांश गैर-विशेषज्ञ उपयोगकर्ता उत्पादन का निर्माण करते हैं।

यहां तक ​​कि प्रमुख पैकेज भी उत्पादन निर्माण के लिए -p का उपयोग करते हैं:
https://github.com/ReactTraining/react-router/blob/5e69b23a369b7dbcb9afc6cdca9bf2dcf07ad432/package.json#L23
https://github.com/react-bootstrap/react-bootstrap/blob/61be58cfdda5e428d8fb11d55bf743661bb3f0b1/tools/dist/build.js#L10

वेबपैक में Uglify प्लगइन को सीधे कॉन्फ़िगर करना काफी असामान्य है, इसलिए -p के बिना, लोग अन-मिनिफाइड बिल्ड का उपयोग कर रहे होंगे, इस स्थिति में उन्हें बड़ी समस्याएं होती हैं।

मैं व्यक्तिगत रूप से एक रनटाइम समाधान की तरह महसूस करता हूं जिसमें एक स्पष्ट ओवरले संदेश शामिल होता है जो केवल कुछ बुद्धिमान हेरिस्टिक्स (लोकलहोस्ट, देवटूल ओपन इत्यादि) का उपयोग करके प्रदर्शित होता है जो हमें पर्याप्त रूप से कवर करेगा।

मुझे ऐसा लगता है कि इसे कई बार शूट किया गया है ("यह डोम में चीजों को इंजेक्ट करने के लिए एक ढांचे के लिए अस्वीकार्य है") वास्तव में _only_ परिदृश्य की सराहना किए बिना जिसमें यह होगा।

मैं पूरी तरह से आप सभी के साथ हूं कि विकास के दौरान लगातार डीओएम में एक स्थायी संदेश और अप्रत्याशित चीजों का सामना करना अस्वीकार्य है। हालांकि, हम यहां जो सुझाव दे रहे हैं, वह एक संदेश है जो प्रदर्शित होता है अगर और _only_ अगर देवमोड उत्पादन के लिए तैनात हो जाता है (ह्यूरिस्टिक्स दर्ज करें!) ऐसा होने से रोकने के लिए टूलिंग, सीआई और ब्राउज़र एक्सटेंशन में मनमाने ढंग से चेक और कंसोल संदेशों का निर्माण किया जा सकता है।

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

केवल तभी प्रदर्शित होता है जब DevMode को उत्पादन में तैनात किया जाता है (हेयुरिस्टिक्स दर्ज करें!)

तो एक डेवलपर इस संदेश को कभी नहीं देखेगा, उत्पादन में (शायद गलती से) देव मोड को तैनात करेगा और अचानक वे अपने सभी उपयोगकर्ताओं को देखने के लिए इस नए एचटीएमएल को अपने आवेदन पर प्रदर्शित कर रहे हैं?

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

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

इस समाधान के साथ समस्या यह है कि यह बहुत अधिक आदर्शवादी है और जब आप एक ढांचा विकसित कर रहे हैं तो आपको इस वास्तविकता पर ध्यान देना चाहिए कि अन्य कंपनियों के पास सबसे बड़ी तैनाती नीतियां या यहां तक ​​​​कि सर्वोत्तम क्यूए (यदि कोई हो) भी नहीं हो सकता है।

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

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

आइए दो परिदृश्य लें जिनमें मैंने व्यक्तिगत रूप से अनुभव किया है।

सबसे पहले , सरकार में काम करते हुए, शाखा और विभाग के आधार पर, आपके पास हर 3-6 महीने में एक ही तैनाती होने की संभावना है। ये परिनियोजन जितना संभव हो उतना सामान रोल अप करते हैं और यदि संपूर्ण परिनियोजन का कोई भी भाग विफल हो जाता है, तो सब कुछ वापस लुढ़क सकता है। इसलिए हम OWF नामक इस सॉफ़्टवेयर का उपयोग कर रहे थे, जो यदि आप अपरिचित हैं, तो iSocial की तरह है जिसमें यह iframes का उपयोग करके एक ही वेब एप्लिकेशन में कई वेब एप्लिकेशन प्रदर्शित करता है (सकल, मुझे पता है, लेकिन यहां मेरे साथ रहें)। हमारे कई अनुप्रयोगों के परिनियोजन में एक मैन्युअल कॉन्फ़िगरेशन चरण था जो विफल हो गया जिसके कारण 404 और 500 त्रुटियां कुछ आईफ्रेम में प्रदर्शित होने के बजाय इच्छित एप्लिकेशन में प्रदर्शित हुईं।

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

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

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

@ क्रिस सीगल

यदि आप पहले से ही देव मोड को नहीं समझते हैं और आप संदेश के साथ प्रतिक्रिया के इस सैद्धांतिक नए संस्करण का उपयोग करके तैनात करते हैं तो आपको एक आश्चर्य होगा और उस समय वेब एप्लिकेशन पर आपके उपयोगकर्ताओं को भी इसे देखने को मिलेगा।

मैं उत्सुक था यदि दृष्टिकोण पर आपके विचार कोई भिन्न थे यदि संदेश केवल DevTools के खुले होने पर प्रदर्शित किया गया था (अर्थात कुछ ऐसा जो उत्पादन उपयोगकर्ताओं द्वारा देखे जाने की कम संभावना होगी जो डेवलपर्स नहीं हैं)। प्रभावी रूप से वर्तमान कंसोल.लॉग रणनीति का विस्तार रिएक्ट पहले से ही आज कार्यरत है।

मैं उत्सुक था यदि दृष्टिकोण पर आपके विचार कोई भिन्न थे यदि संदेश केवल DevTools के खुले होने पर प्रदर्शित किया गया था (अर्थात कुछ ऐसा जो उत्पादन उपयोगकर्ताओं द्वारा देखे जाने की कम संभावना होगी जो डेवलपर्स नहीं हैं)। प्रभावी रूप से वर्तमान कंसोल.लॉग रणनीति का विस्तार रिएक्ट पहले से ही आज कार्यरत है।

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

अंततः हालांकि मुझे लगता है कि कोई इसमें भाग लेगा, स्टैक ओवरफ्लो पर पूछें कि चेतावनी को कैसे अक्षम किया जाए, कोई व्यक्ति कोड पोस्ट करेगा जो उन्हें दिखाएगा कि यह कैसे करना है, फिर लोग इसे आसानी से अक्षम कर देंगे यदि वे इसमें भाग लेते हैं। बिल्ड टूल असंख्य हैं और कई लोग जिनसे मैंने अतीत में बात की है, उन्हें भ्रमित या कठिन पाया (बेबेल 6 की रिलीज़ एक "मज़ेदार" समय था)। आप बहुत से ऐसे लोगों से मिलने जा रहे हैं जो कभी भी उनका सही ढंग से उपयोग नहीं करते हैं।

कम से कम यह मेरा अनुभव है ¯\_(ツ)_/¯

वाह, अंत में धागे की तह तक पकड़ा गया। ठीक। मैं इस पर थोड़ा विचार कर रहा हूं।

वेबपैक NODE_ENV को निर्दिष्ट करने के लिए बाध्य कर सकता है, जो प्रतिक्रिया तब अधिक आसानी से लोगों को DEV को PROD पर भेजने से बचने के लिए उपयोग कर सकता है, लेकिन यह वेबपैक के लिए एक ब्रेकिंग परिवर्तन होगा। मैं अब शॉन से बात कर रहा हूं कि वेबपैक 3 के लिए ऐसा कुछ कितना व्यवहार्य हो सकता है। रिएक्ट + वेबपैक स्टैक को शुरुआती और पूर्ण अनुकूल रखना कुछ ऐसा है जो मुझे पता है कि दोनों शिविरों की परवाह है।

यह अब तक मेरा पसंदीदा लगा है लेकिन मैं अभी तक 100% नहीं बिका हूं।

1. तो लागू कर सकता है कि जब भी कोई वेबपैक चलाता है तो एक ईएनवी पास हो जाता है। एक उपयोगी त्रुटि संदेश बताता है कि आपको वेबपैक चलाने के लिए एक env चर प्रदान करना होगा।

हालाँकि यह उपयोगकर्ताओं के लिए एक महत्वपूर्ण उछाल बिंदु प्रदान करता है। हर कोई एक उत्पाद या देव env के लिए नहीं लिख रहा है या यह भी नहीं जानता कि एक env क्या है। मैं इस पर प्रतिक्रिया प्राप्त करने के लिए वेबपैक/वेबपैक पर एक मुद्दा उठाऊंगा, क्योंकि मेरी भावना यह है कि हर कोई यह नहीं चाहेगा और मैं सहमत हूं या नहीं, हमें पुशबैक पर विचार करना होगा।

1. <something in-between 1 and 3 I haven't figured out yet>

2. webpacky समाधान एक स्टैंडअलोन प्लगइन बनाना होगा जो संकलक जीवनचक्र में हुक कर सकता है, जांचें कि क्या कोड छीन लिया जा रहा है, या यदि कोई ENV प्रदान नहीं किया गया है, और एक अनुकूल चेतावनी या अपनी पसंद की त्रुटि का उत्सर्जन करें।

हालांकि मैं कल्पना कर सकता हूं कि प्रतिक्रिया "लेकिन उपयोगकर्ताओं को यह कभी नहीं पता होगा कि यह कैसे करना है।" इस प्रकार सीआरए, इस प्रकार यह मुद्दा अभी।

हम एक नया रिज़ॉल्वर पैटर्न बना सकते हैं जो रिएक्ट (या किसी भी fw जिसे इसकी आवश्यकता है) package.json की जांच नीचे की तरह कुछ के लिए करेगा:

"webpack": {
  "plugin": "ReactEnviornmentPlugin"
}

यह स्वचालित रूप से एक उपयोगकर्ता कंपाइलर कॉन्फ़िगरेशन पर लागू होगा बिना उन्हें जानने या देखभाल करने की आवश्यकता के।

फिर से वास्तव में दिमागी तूफान।

@TheLarkInn मुझे लगता है कि वेबपैक 2 में -p का वर्तमान व्यवहार पर्याप्त है, नहीं? एकमात्र विफलता मामला यह है कि यदि कोई व्यक्ति UglifyJsPlugin स्वयं सेट करता है और DefinePlugin करना भूल जाता है, लेकिन ऐसा लगता है कि यह बहुत कम संभावना वाला मामला है।

@taion हाँ/नहीं

-p केवल आपके कोड पर उत्पादन "उपचार" लागू करता है, हालांकि हम इस बारे में कोई अनुमान नहीं लगाते हैं और/न ही हमें इस बारे में कोई जानकारी नहीं है कि NODE_ENV किस पर सेट है। यही कारण है कि लोगों को DefinePlugin() का उपयोग करने की आवश्यकता होती है।

लेकिन मुझे लगता है कि यह _guess_ या _imply_ के निकटतम "_reasonable_" क्षेत्र है कि उपयोगकर्ता अपने कोड को उत्पादन ENV में चला रहा है। यही एक ऐसा क्षेत्र होगा जिसमें हम यह सुनिश्चित करना चाहेंगे कि समुदाय और टीम ठीक है।

@TheLarkInn मेरा मानना ​​है कि यह v2 में बदल गया है: https://webpack.js.org/guides/production-build/#node -environment-variable

आह क्षमा करें यह सही है मैं गलत हूँ। हालांकि इसका उपयोग अक्सर नहीं किया जाता है क्योंकि लोग जो कुछ भी अनुकूलित करते हैं उस पर अधिक बढ़िया नियंत्रण चाहते हैं। (जैसे @addyosmani का उल्लेख किया गया है)

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

हम एक नया रिज़ॉल्वर पैटर्न बना सकते हैं जो रिएक्ट (या किसी भी fw जिसे इसकी आवश्यकता है) package.json की जांच नीचे की तरह कुछ के लिए करेगा:

"वेबपैक": {
"प्लगइन": "ReactEnviornmentPlugin"
}
यह स्वचालित रूप से एक उपयोगकर्ता कंपाइलर कॉन्फ़िगरेशन पर लागू होगा बिना उन्हें जानने या देखभाल करने की आवश्यकता के।

@TheLarkInn अगर मैं इसे सही ढंग से पढ़ रहा हूं, तो रिज़ॉल्वर पैटर्न को ट्रिगर करने के लिए ऐप के package.json को मैन्युअल रूप से ReactEnvironmentPlugin निर्दिष्ट करने की आवश्यकता होगी, है ना? या मैं प्रस्ताव को गलत समझ रहा हूँ? :)

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

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

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

हमने इसके बारे में कुछ और बात की है और मुझे लगता है कि एक उचित समाधान है।

हमने लंबे समय से विकास में प्रतिक्रिया चेतावनियों के लिए "चेतावनी बॉक्स" को सक्षम करने पर विचार किया है। आप यहां एक डेमो देख सकते हैं (पीआर: https://github.com/facebook/react/pull/7360)। यह केवल तब दिखाई देता है जब आपके पास चेतावनियां होती हैं लेकिन वे विकास के दौरान बहुत आम हैं (और हमेशा तय की जानी चाहिए), इसलिए संभवत: कोई भी व्यक्ति जिसने ऐप विकसित करने में पांच मिनट से अधिक समय बिताया है, वह संवाद देखेगा और जागरूक होगा कि यह मौजूद है।

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

(वैसे, हम लंबे समय से फेसबुक पर विकास में एक समान चेतावनी बॉक्स का उपयोग कर रहे हैं, इसलिए यह इस बात से मेल खाता है कि हम किस तरह से रिएक्ट का उपयोग करना चाहते हैं।)

मैं उस प्रस्ताव को देखकर वाकई खुश हूं, @gaearon! यह वह सब कुछ है जिसका मैंने सपना देखा था;)

एक पक्ष के रूप में: हो सकता है कि बॉक्स में सीधे एक लिंक रखने पर विचार करना उचित हो, ताकि डेवलपर्स को इससे छुटकारा पाने के लिए Google की आवश्यकता न हो।

हाँ, अच्छा बिंदु। हम कुछ जोड़ेंगे।

@gaearon मुझे वह समाधान अत्यधिक अप्रिय लगता है; मैं कभी नहीं चाहता कि चेतावनियां विकास के दौरान भी डीओएम पर आक्रमण करें। यह सामान्य डेवलपर के लिए शून्य उद्देश्य प्रदान करता है और संभवतः इसे पूरी तरह से अक्षम कर दिया जाएगा। डेवलपर टूल किसी कारण से चेतावनियां प्रदर्शित करते हैं, उन्हें आविष्कार करने की आवश्यकता नहीं है।

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

जबकि मैं अधिकांश चेतावनियों के बारे में इस बात से सहमत हूं, प्रतिक्रिया चेतावनियां विशेष रूप से आपके कोड में बग को इंगित करती हैं। वे सिर्फ सुझाव नहीं हैं।

संवाद को खारिज करना आसान है और व्यक्तिगत चेतावनियों को याद दिलाना आसान है (यदि आप कुछ समय के लिए उनकी परवाह नहीं करते हैं) लेकिन उन्हें ठीक करने की आवश्यकता है।

तुलना के लिए, फेसबुक कोडबेस में डायलॉग इस तरह दिखता है:

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

यदि आपके पास स्टाइल ट्वीक के बारे में सुझाव हैं तो कृपया बेझिझक https://github.com/facebook/react/pull/7360 पर टिप्पणी करें।

डैन ने जो कहा, उसे जोड़ते हुए, मैं अपने हाल ही में जोड़े गए त्रुटि लॉगर प्रवाह में शामिल होने के लिए #7360 के शीर्ष पर निर्माण कर रहा हूं। मैं वर्तमान में टोस्ट अधिसूचनाओं की कुछ शैलियों की कोशिश कर रहा हूं जो थोड़ा कम घुसपैठ कर रहे हैं। मैं प्रतिक्रिया के लिए जल्द ही कुछ स्क्रीनशॉट और/या एक Plnkr पोस्ट करूंगा।

क्या इन चेतावनियों में "मिनीफाइड देव कोड" चेतावनी शामिल होगी? यदि ऐसा है तो यह बहुत सारी चीजों को बड़े करीने से हल कर देगा।

मैं नहीं देखता कि इसका उपयोग उस उद्देश्य के लिए क्यों नहीं किया जा सका।

@gaearon

जबकि मैं अधिकांश चेतावनियों के बारे में इस बात से सहमत हूं, प्रतिक्रिया चेतावनियां विशेष रूप से आपके कोड में बग को इंगित करती हैं। वे सिर्फ सुझाव नहीं हैं।

वे त्रुटियां या अपवाद आईएमओ होना चाहिए। वे क्यों नहीं हैं? अपवाद चीजों को ठीक करने के लिए बाध्य करते हैं लेकिन खारिज करने योग्य चेतावनी नहीं है।

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

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

ऐसा लगता है कि प्रतिक्रिया बहुत अधिक आईएमओ करने की कोशिश कर रही है।

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

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

मुझे वास्तव में #7360, @gaearon पसंद है। नए चेतावनी बॉक्स में परिनियोजन के लिए PROD पर स्विच करने की आवश्यकता पर प्रकाश डालने के लिए समर्थन सुनना खुशी की बात है। यह अच्छा और दृश्य है।

डैन ने जो कहा, उसे जोड़ते हुए, मैं अपने हाल ही में जोड़े गए त्रुटि लॉगर प्रवाह में शामिल होने के लिए #7360 के शीर्ष पर निर्माण कर रहा हूं। मैं वर्तमान में टोस्ट अधिसूचनाओं की कुछ शैलियों की कोशिश कर रहा हूं जो थोड़ा कम घुसपैठ कर रहे हैं। मैं प्रतिक्रिया के लिए जल्द ही कुछ स्क्रीनशॉट और/या एक Plnkr पोस्ट करूंगा।

@bvaughn आपके अधिक पुनरावृत्तियों को देखने के लिए उत्सुक :)

उन लोगों के लिए जो चेतावनी बॉक्स दृष्टिकोण बहुत घुसपैठ कर सकते हैं, अन्य पुस्तकालय (उदाहरण के लिए VueJS) बग-फिक्सिंग या धीमे-पथ को प्रोत्साहित करने के लिए आपके देव/पुनरावृत्ति वर्कफ़्लो के दौरान पहले से ही डोम ओवरले प्रदर्शित करते हैं:

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

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

वे त्रुटियां या अपवाद आईएमओ होना चाहिए। वे क्यों नहीं हैं? अपवाद चीजों को ठीक करने के लिए बाध्य करते हैं लेकिन खारिज करने योग्य चेतावनी नहीं है।

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

उन लोगों के लिए जो चेतावनी बॉक्स दृष्टिकोण बहुत घुसपैठ कर सकते हैं, अन्य पुस्तकालय (उदाहरण के लिए VueJS) बग-फिक्सिंग या धीमे-पथ को प्रोत्साहित करने के लिए आपके देव/पुनरावृत्ति वर्कफ़्लो के दौरान पहले से ही डोम ओवरले प्रदर्शित करते हैं:

स्क्रीन शॉट 2017-01-24 सुबह 10 57 11 बजे

क्या आप सुनिश्चित हैं कि यह Vue से ही है? ऐसा लगता है कि वेबपैक बिल्ड त्रुटियाँ वेबपैक-हॉट-मिडलवेयर से त्रुटि ओवरले के साथ प्रदर्शित होती हैं। यदि ऐसा है, तो यह सूक्ष्म रूप से भिन्न है क्योंकि यह एक सामान्य-उद्देश्य वाले फ्रंटएंड फ्रेमवर्क के बजाय ओवरले को जोड़ने वाला देव-टाइम बिल्ड टूलिंग है।

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

मुझे ओवरले के साथ 15.2.0 जैसे अपडेट से डर लगता है। मामूली टक्कर और अचानक आपके पास डीओएम नोड्स को पारित होने वाले प्रोप के बारे में सचमुच 100 चेतावनियां हैं। त्रुटियां हो सकती हैं, लेकिन मुझे नहीं लगता कि मूल्यह्रास चेतावनियां इतनी घुसपैठ वाली जगह में हैं

त्रुटियां हो सकती हैं, लेकिन मुझे नहीं लगता कि मूल्यह्रास चेतावनियां इतनी घुसपैठ वाली जगह में हैं

मुझे नहीं पता कि यह पहले बहुत स्पष्ट रूप से संप्रेषित किया गया था, लेकिन पीले-बॉक्स चेतावनियों (#7360) के बारे में विचार _all_ चेतावनियां (बहिष्करण या अन्य) दिखाने के लिए नहीं था। इसके बजाय, कुछ चेतावनियां जिन्हें टीम _विशेष रूप से महत्वपूर्ण_ समझी जाती है, को इस तरह से हाइलाइट किया जाएगा। बाकी संभवतः कंसोल में रहेंगे।

टॉम और मेरे बीच एक या दो सप्ताह पहले इस सुविधा के बारे में बातचीत से कम से कम यह मेरा टेक-अवे है।

15.2 में प्रोप चेतावनी भी एक गलती आईएमओ थी और हमारे सामान्य एमओ का संकेत नहीं थी हम इससे बचने के लिए छोटे संस्करणों द्वारा चेतावनी के स्तर को नियंत्रित करने का एक तरीका चाहते हैं।

हमारी टीम द्वारा प्रोडक्शन बिल्ड का उपयोग नहीं करने का मुख्य कारण यह है कि हम JS यूनिट टेस्ट नहीं चला सकते, क्योंकि टेस्ट बर्तन शामिल नहीं हैं।

सबसे पहले, हमारे साथ इस मुद्दे पर चर्चा करने के लिए रिएक्ट टीम ( @sebmarkbage , @gaearon , @tomocchino और अन्य) को धन्यवाद का एक और दौर और इस तिमाही में ब्लिंकऑन और अन्य सिंक पर प्रदर्शन और मोबाइल के बारे में हमसे बात करने के लिए इतना खुला होना।

स्थिति जांच

प्रति @awery में https://github.com/facebook/react/pull/7360 , इस विशेष समस्या के येलो बॉक्स समाधान को तब तक रोक दिया गया है जब तक कि रिएक्ट का हाई-प्रियो V16 काम पूरा नहीं हो जाता, लेकिन अभी भी होना चाहिए। https://github.com/facebook/fbjs/pull/165 को फाइबर में उतरने और लागू करने की आवश्यकता है। हुक को उजागर करने के लिए एक अच्छा सार्वजनिक एपीआई भी तैयार किया जाना चाहिए। उँगलियाँ रख रहा होगा

यह समस्या अभी भी प्रचलित प्रतीत होती है

मेरे डेस्क पर आए कुछ प्रोडक्शन ऐप्स अभी भी प्रोडक्शन के लिए DEV मोड शिपिंग कर रहे हैं। हम यहां उनके निर्माण में When deploying React apps to production डिबग स्ट्रिंग देख सकते हैं:

https://cdnjs.cloudflare.com/ajax/libs/react/15.3.1/react.js (tombraider.com)
https://shared.reliclink.com/dlls/vendor-f3e016f6037eb107ffc0.live-shared.min.js (dawnofwar.com)
https://d1xx3pvec9nqb7.cloudfront.net/media/js/thread.af65c1a02d15.js (thread.com)
http://www.sothebys.com/etc/designs/redesigns/sothebys/redesignlibs.min.js (sothebys.com)

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

सुई को इधर-उधर करने के लिए हम और क्या कर सकते हैं?

बेहतर वकालत? मुझे उत्पादन के लिए DEV मोड शिपिंग नहीं करने वाले लोगों की वकालत जारी रखने के लिए प्रतिबद्ध होने में खुशी हो रही है, लेकिन यह देखना चाहते हैं कि क्या हम आधिकारिक समाधान पोस्ट V16 को लैंड कर सकते हैं :)

अल्पावधि में, ऐसा लगता है कि नई परियोजनाओं को इस समस्या से बचने में मदद करने के लिए create-react-app एक अच्छी जगह पर है।

स्थापना दस्तावेज़ों में सुधार

अन्य सभी के लिए, क्या https://facebook.github.io/react/docs/installation.html के लिए समर्थन होगा जिसमें Installing React शीर्षक के अंतर्गत एक स्पष्ट, दृश्यमान कॉलआउट शामिल है जो लोगों को DEV मोड के प्रति सचेत रहने की याद दिलाता है। उत्पादन?

एक उपयोगकर्ता के रूप में, मुझे नहीं लगता कि https://facebook.github.io/react/docs/installation.html#Development -and-production-versions पहली नज़र में पढ़ने के लिए मेरे लिए कोई बड़ा प्रोत्साहन है।

विचार?

हमारी टीम द्वारा प्रोडक्शन बिल्ड का उपयोग नहीं करने का मुख्य कारण यह है कि हम JS यूनिट टेस्ट नहीं चला सकते, क्योंकि टेस्ट बर्तन शामिल नहीं हैं।

मैं इस बारे में उलझन में हूं। क्या आप उत्पादन वेबसाइट पर परीक्षण चला रहे हैं? यदि नहीं, तो आपको प्रोडक्शन वेबसाइट पर प्रोडक्शन बिल्ड और डेवलपमेंट बिल्ड इन डेवलपमेंट का उपयोग करने से क्या रोकता है?

अन्य सभी के लिए, क्या https://facebook.github.io/react/docs/installation.html के लिए समर्थन होगा, जिसमें इंस्टालिंग रिएक्ट शीर्षक के तहत एक स्पष्ट, दृश्यमान कॉलआउट शामिल है, जो लोगों को उत्पादन में DEV मोड के प्रति सचेत रहने की याद दिलाता है?

ज़रूर। पीआर भेजना चाहते हैं?

ज़रूर। पीआर भेजना चाहते हैं?

से ज्यादा खुशी की बात है।

हो सकता है कि बेंचमार्क के बारे में एक शब्द भी उन लोगों को शिक्षित करने में मदद करने के लिए अच्छा होगा जो देव मोड में प्रतिक्रिया के साथ perfs की तुलना करते हैं?

मुझे लगता है कि देव मोड में प्रतिक्रिया का उपयोग कर पृष्ठ खोलते समय एक अधिसूचना या कुछ स्पष्ट प्रदर्शित करने के लिए प्रतिक्रिया devtools एक्सटेंशन का लाभ उठाया जा सकता है?

मुझे यह विचार पसंद है! मैंने devtools के लिए प्रस्तावित चिह्नों का एक सेट एक साथ रखा (देखें facebook/react-devtools/pull/652)।

हमें यह तय करने की ज़रूरत है कि देव बनाम उत्पाद प्रतिक्रिया का पता कैसे लगाया जाए जो पीछे की ओर और भविष्य में सुरक्षित हो, लेकिन मैंने इसे सोमवार की बैठक के एजेंडे में जोड़ा है।

हमने इस समस्या के समाधान के लिए कुछ उचित कदम उठाए हैं:

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

• React DevTools में नोटिस हमारी वेबसाइट से लिंक करता है जहां हमने सभी प्रमुख बंडलर के लिए प्रोडक्शन बिल्ड बनाने के निर्देश प्रकाशित किए हैं। हमने इसे इंस्टॉलेशन पेज पर और भी प्रमुख बना दिया है।

• क्रिएट रिएक्ट ऐप ने लोकप्रियता हासिल करना जारी रखा। यह अलग-अलग आदेशों के साथ इस भेद को जल्दी सिखाता है। यह टर्मिनल में विकास मोड के बारे में एक स्थायी सूचना भी प्रदर्शित करता है।

• रिएक्ट 16 बीटा 1 (और आगे रिलीज़) फ़ाइल नाम के रूप में react.development.js और react.production.min.js के साथ जहाज को यह स्पष्ट करने के लिए कि गैर-मिनीफाइड बिल्ड का उत्पादन में उपयोग नहीं किया जाना चाहिए।

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