React: استكشف تشجيع المستخدمين على عدم شحن وضع DEV للإنتاج

كمرجع: https://github.com/facebook/react/pull/8782

بالنسبة إلى السياق ، نحذر بالفعل إذا اكتشفنا أنك قمت بتصغير إصدار DEV من React: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

بقدر ما يمكننا العثور على أساليب استكشافية مماثلة لإخطار المستخدمين ، وربما حتى ظهور مربع حوار DOM بشكل أكثر قوة ، يجب علينا ذلك.

أريد أيضًا أن أوضح أن التحذيرات التي نقدمها يمكن أن تحسن الأداء بشكل كبير إذا انتبه الناس لها. يوضح هذا الخيط بعض الأسباب المنطقية لسبب صعوبة نشر هذا بعد الحقيقة إذا لم يكن هذا هو الوضع الافتراضي.

أود أيضًا التناغم مع اقتراح وحدة تحكم واحدة. تحذير إذا تم استدعاء renderToString في وضع التطوير. من الواضح ، في معظم الحالات ، يتم استدعاء renderToString في العقدة ، حيث لا يمكننا تنبيه أو ظهور مربع حوار DOM.

لسوء الحظ ، أود حقًا أن أكون قادرًا على اكتشاف ليس فقط ما إذا تم تعيين NODE_ENV على production ، ولكن أيضًا إذا تم تجميع process.env.NODE_ENV . هل يعرف أي شخص طريقة للقيام بذلك؟

شكرًا على الموضوع sebmarkbage وأقر بصعوبات النشر بعد الواقعة. كما أنني أقدر التحذيرات الحالية. يبدو أن بعض المطورين قد لا يتحققون من مخرجات وحدة التحكم لمواقعهم المنشورة بقدر الإمكان. إنها خطوة أولى جيدة.

بقدر ما يمكننا العثور على أساليب استكشافية مماثلة لإخطار المستخدمين ، وربما حتى ظهور مربع حوار DOM بشكل أكثر قوة ، يجب علينا ذلك.

سأكون ممتنًا لإدخال تحسينات على الأساليب التجريبية المستخدمة لإعلام المستخدمين. إن وجود حوار DOM أكثر صرامة سيقطع شوطًا طويلاً في المساعدة. سيضمن ذلك استمرار الموقع في العمل للمستخدمين النهائيين ولكنه يوفر تلميحًا نشطًا إلى أن هناك مطوري فواكه منخفضي الأداء يمكنهم اختياره.

البديل هو أننا نجد طريقة لإصلاح ذلك على مستوى أداة البناء / ENV كما هو مذكور في المنشور الأصلي. هذا من شأنه أن يتجنب أي ضرورة لحقن DOM.

يبدو إدخال أي رسائل في DOM أمرًا خطيرًا وقليلًا من الافتراض. وهذا يفتح إمكانية حصول المستخدمين النهائيين على تنبيهات غير متوقعة ومربكة والتي تبدو غير مقبولة IMO.

كان thelarkinn يقترح أننا حاولنا توحيد معايير ENV المطلوبة لتسهيل اكتشاف الرسائل مثل هذه بشكل أفضل

هذا يبدو وكأنه مساحة مثالية لمعالجة هذا. إنها مشكلة في البناء ويجب ، إن أمكن ، معالجتها بواسطة أدوات البناء.

قصصية: تم اختفاء التحذيرات في وحدة التحكم (أو تجاهلها) في الماضي. ليس لدي أرقام ثابتة هنا ، لكني أعتقد أن التحذيرات المستندة إلى وحدة التحكم ليست كافية. أتفق مع addyosmani على أن التحذير المستند إلى DOM سيقطع شوطًا طويلاً.

surma ربما يجب عليهم استخدام console.warn أو console.error لرؤية أفضل 😉

لا أرى كيف يكون من المقبول في أي سيناريو ضخ محتوى في تطبيق فقط عندما يكون قيد الإنتاج. أنت تفترض افتراضًا كبيرًا أنه سيتم اكتشاف الرسالة قبل دفع التطبيق إلى المستخدمين الفعليين ، حيث يمكن أن تضر الرسالة بتجربة المستخدم بشكل كبير.

بالمناسبة ، سنضيف دعمًا أكثر شمولاً لمعالجة الأخطاء في Fiber بحيث يمكنك استبدال المكونات التي بها أعطال (أخطاء تم إلقاؤها) بآلات عرض خطأ مخصصة. حتى في السيناريو الافتراضي ، من المحتمل أن نكون عدوانيين للغاية ، وما عليك سوى إزالة هذا المكون من الشجرة إذا كان به أخطاء ، لذلك سترغب حقًا في الحصول على واجهة مستخدم خطأ مخصصة لمستخدميك على أي حال.

قد نتمكن من تشغيل مثل هذا الخطأ لهذا التحذير.

أنا بصراحة لا أعتقد أن console.{error,warn} على console.log كان سيغير أي شيء. كما قلت ، هذه القصة قصصية.

كما أنني لا أقول أن إظهار مربع حوار DOM هو الحل. إنه شيء سأكون مرتاحًا له شخصيًا. إذا كان للبقاء في وضع dev تأثير سلبي ، فسيعرف المستخدمون على الأقل أن _شيء ما_ خطأ وربما يبدأ في الضغط على زر "المساعدة" أو شيء من هذا القبيل.

الخلاصة: أعتقد أن أطر العمل تحتاج إلى مواجهة المطور في مرحلة ما. أرغب في تبادل الأفكار حول هذا الأمر لمعرفة الخطوات والتنازلات التي يرغب مؤلفو إطار العمل في اتخاذها لمنع الأشخاص من النشر في وضع التطوير في المستقبل.

ماذا لو لم تعمل React على الإطلاق إلا إذا قمت بتوفير بيئة ، بغض النظر عما إذا كانت عملية تطوير أو إنتاج؟ بهذه الطريقة يكون هناك اختيار واع يتم بطريقة أو بأخرى.

حول الرسالة التي تم إدخالها في DOM ، يمكن تعطيلها باستخدام global أو شيء من هذا القبيل. لا توجد صفقة كبيرة IMO. إذا قمت بتعطيله ، فأنت تقر نوعًا ما بمعرفة ما تفعله.

تتمثل مشكلة رسالة وحدة التحكم في أنه في بعض الأحيان يقوم الأشخاص بتسجيل الكثير من الأشياء ، أو لديهم تحذيرات أخرى يتجاهلونها ، ومن السهل ألا ترى رسالة وحدة التحكم الأولى بعد التمرير ...

مع بيئة إلزامية ، ستعمل النماذج المتساقطة حتمًا وما إلى ذلك على إعداد env var حتى تتمكن من البدء في استخدامه ، أخشى: /

أنا بصراحة لا أعتقد أن وحدة التحكم هذه. {خطأ ، تحذير} على console.log كان من الممكن أن يغير أي شيء.

هل تعتقد أنها مشكلة مع المطورين الذين لا يقومون بفحص وحدة التحكم ، أو أن وحدة التحكم محملة بالتحذيرات؟ هل يمكن معالجة هذا (جزئيًا) بنهج أكثر عمومية فيما يتعلق بتعليم المطورين؟

أنا أيضًا لا أقول أن إظهار مربع حوار DOM هو الحل. إنه شيء سأكون مرتاحًا له شخصيًا. إذا كان للبقاء في وضع dev تأثير سلبي ، فسيعرف المستخدمون على الأقل أن هناك شيئًا خاطئًا وربما يبدأون في الضغط على زر "المساعدة" أو شيء من هذا القبيل.

أفهم ذلك ، لكنني أقول فقط لا أعتقد أنه حل ، ناهيك عن الحل. من الجيد أنك مرتاح لذلك ، لكنني أعتقد أنه من الأفضل أن نخطئ في جانب الحذر وافترض أن معظم الناس لا يريدون عرض أخطاء غير متوقعة لمستخدميهم.

الخلاصة: أعتقد أن أطر العمل تحتاج إلى مواجهة المطور في مرحلة ما. أرغب في طرح الأفكار حول هذا الأمر لمعرفة الخطوات والتنازلات التي يرغب مؤلفو إطار العمل في اتخاذها لمنع الأشخاص من النشر في وضع التطوير في المستقبل.

أنا 💯 للتغلب على وجه المطور ، لكن من المهم القيام بذلك في المكان المناسب. بالنسبة لي ، هذه هي خطوة البناء وليس الإنتاج.

حول الرسالة التي تم إدخالها في DOM ، يمكن تعطيلها باستخدام global أو شيء من هذا القبيل. لا توجد صفقة كبيرة IMO. إذا قمت بتعطيله ، فأنت تقر نوعًا ما بمعرفة ما تفعله.

إن تمكينه افتراضيًا يعد سيئًا تمامًا مثل عدم جعله قابلاً للتكوين: قد يؤدي السلوك الافتراضي إلى سلوك غير متوقع للمستخدم النهائي. إذا كان يجب تعطيل أي شيء بشكل افتراضي ، ولكن بعد ذلك ، فإن ذلك يتعارض مع الغرض بالكامل حيث يمكن للمطورين فقط حل المشكلة الأولية بمجرد علمهم بها.

تتمثل مشكلة رسالة وحدة التحكم في أنه في بعض الأحيان يقوم الأشخاص بتسجيل الكثير من الأشياء ، أو لديهم تحذيرات أخرى يتجاهلونها ، ومن السهل ألا ترى رسالة وحدة التحكم الأولى بعد التمرير ...

أفهم ذلك تمامًا ، يمكن أن تزدحم وحدة التحكم ومن السهل تفويت الأشياء. لكنها مزدحمة للأسباب التي أجادلها بالضبط: إنها المكان الذي يزود المطورون فيه بالتعليقات أو الأخطاء. إنه بعيد عن تجربة المستخدم ، حيث لا يتم حقن الرسائل.

من المنطقي ، وأنا أفهم المنطق.

حسنًا ، ربما يكون إخراج الشيء باستخدام تنسيق وحدة التحكم أمرًا ما على الأقل.

المشكلة تكاد لا أحد ينظر إلى وحدة التحكم في الإنتاج. يمكنك استخدام أي خط هناك ولن يلاحظه الناس.

ومع ذلك ، إذا جعلناها تُظهر رسالة بشكل افتراضي في الإنتاج كتغيير فاصل (في 16 أو 17) ، فسيكون من الصعب تفويتها. أعني ، سيحدث ذلك في المرة الأولى التي تحاول فيها نشره (للمستخدمين الجدد) ، ويجب على المستخدمين الحاليين قراءة ملاحظات الإصدار عند التحديث إلى تخصص جديد. لذلك أعتقد أنه يمكن تنفيذه طالما أننا صريحين للغاية بشأنه ومن المستحيل تفويت الرسالة.

المشكلة تكاد لا أحد ينظر إلى وحدة التحكم في الإنتاج. يمكنك استخدام أي خط هناك ولن يلاحظه الناس.

يمكنني فقط التعليق على تجربة فريق Chrome مع هذا ، لكنني أتفق معك. سيلاحظ معظم الأشخاص رسائل وحدة التحكم أثناء سير عمل التكرار ، لكن نسبة أقل بكثير تنظر في التحذيرات على مواقع الإنتاج ويتصرف عدد أقل بها.

ومع ذلك ، إذا جعلناها تُظهر رسالة بشكل افتراضي في الإنتاج كتغيير فاصل (في 16 أو 17) ، فسيكون من الصعب تفويتها. أعني ، سيحدث ذلك في المرة الأولى التي تحاول فيها نشره (للمستخدمين الجدد) ، ويجب على المستخدمين الحاليين قراءة ملاحظات الإصدار عند التحديث إلى تخصص جديد. لذلك أعتقد أنه يمكن تنفيذه طالما أننا صريحين للغاية بشأنه ومن المستحيل تفويت الرسالة.

شكرًا لانفتاحك على تغيير مثل هذاgaearon. ما الذي يتطلبه الأمر للحصول على اتفاق بشأن محاولة إرسال رسالة بشكل افتراضي في إصدار مستقبلي؟ 😄

أوافق على أن تحذيرات وحدة التحكم ليست الحل وأن التحذير المرئي للصفحة أفضل بكثير.

يمكن أن يؤدي تحذير الصفحة المرئية إلى:

• تنبيه المطور إلى أن الموقع في وضع التطوير
• رابط إلى المستندات الخاصة بالمزايا وكيفية الشحن بدونها
• رابط لتعطيل الرسالة ... لا أعرف 2 ساعة؟

يعد تعطيل الرسالة أمرًا مهمًا ، حيث قد تتداخل / تغطي شيئًا ما على الصفحة. نظرًا لأنه سيتم تخزين هذا الإعداد في التخزين المحلي ، فسيظل التحذير يظهر على الخادم المباشر لأنه أصل مختلف.

نعم ، من المروع جدًا أن يرى المستخدمون الحقيقيون هذه الرسالة على المواقع الحية ، لكن يبدو أن هذا النوع من المشكلات سيتم تشجيع مطوري البرامج على حلها ، بينما يبدو أن البعض يسعدهم التعايش مع مشكلات الأداء في وضع التطوير.

إذا كانت المرة الأولى التي رأيت فيها هذا التحذير (الملحق في DOM واحد) ، كان قيد الإنتاج ، فسأشعر بالضيق إلى حد ما. يجب أن تحدث التحذيرات في وقت مبكر.

rtorr اقتراحي هو أنه يحدث عندما يكون الموقع في وضع التطوير ، لذا يجب رؤيته مسبقًا ما لم يفوتني شيء ما؟

jakearchibald آسف على الارتباك ، لم يكن ردي موجهًا لك. أريد فقط أن أشير إلى الخيط أنه إذا أردنا استخدام حل "insert in the dom" ، فيجب أن نكون حذرين للغاية ونتأكد من أن المستخدمين يعرفون قبل أن يدفعوا شيئًا (بعض الكيفية ، ليس لدي فكرة جيدة هنا) .

أرى فقط بعض المطورين ينسون إعدادًا أو شيئًا ما والإدارة تنزعج. هل هذا الاحتمال يستحق العناء بسبب عواقب وجود وضع مطور في الإنتاج؟

إن التحذير المستند إلى DOM والذي يتعين علي تعطيله باستمرار ليس جيدًا ، ويجب أن يكون من الممكن تعطيله إلى الأبد ، وربما لا يجب أن يظهر على الإطلاق للمضيف المحلي.

شيء أصابني للتو إذا كان من الممكن أن يكون لديك نوع من العلم في المتصفح يجب عليك تمكينه لتفعيل أدوات التطوير (ربما تراكب كبير فيها مع "هل أنت مطور؟ [نعم / لا]" ) يمكن للصفحة اكتشافها وإظهار التحذير للمطورين فقط. إذا تمت صياغته بشكل صحيح ، فقد يساعد في هجمات XXS الذاتية أيضًا.

إن التحذير المستند إلى DOM والذي يتعين علي تعطيله باستمرار ليس جيدًا ، ويجب أن يكون من الممكن تعطيله إلى الأبد

لا يُسمح أيضًا بتشغيل المواقع مع وضع dev-mode. ربما الرسالة تحتاج فقط للرفض مرة واحدة في اليوم؟ ولكن كلما طالت الفترة ، زادت احتمالية أن ينتهي الأمر بها على الهواء مباشرة. إذا كان من الممكن تعطيله إلى الأبد ، فإننا نعود إلى حيث بدأنا.

لا أعتقد أيضًا أن وجود عقدة دوم غير مقصودة في الإنتاج أمر جيد.

أعتقد أنه في كلتا الحالتين ، سيكون لدينا دائمًا حالة مميزة. إذا حدثت هذه المشكلة طوال الوقت ، فربما يكون تسليم وضع dev خاطئًا. على الرغم من أنه ليس مثاليًا في عالم مثالي ، ولكن إذا وجدنا وضع prod مهمًا أننا على استعداد لتعديل تطبيق شخص ما ، فربما يجب أن يكون افتراضيًا ويجب تمكين وضع dev.

تضمين التغريدة

لا أعتقد أيضًا أن وجود عقدة دوم غير مقصودة في الإنتاج أمر جيد.

لماذا ا؟ (أنا لا أقول أنك مخطئ ، أود فقط أن أسمع أسبابك)

ربما يتم إضافة إعداد لتحديد نطاق المنتج. إذا لم يتم تعيين نطاق prod ، فسنحصل دائمًا على تحذير بشأن وضع DEV (مع طلب لتعيين عنوان URL للمجال) ، إذا تم تعيينه ، فإننا نتلقى تحذيرًا فقط عندما يتطابق عنوان URL مع مجال prod. يمكننا حتى ربط أي خدمة نريد إخطار المطورين

أنا سعيد بوجود مناقشة بناءة هنا. يوجد حلان هنا يمكنني رؤيتهما لحل المشكلة. يمكن أن يفرض Webpack تحديد NODE_ENV الذي يمكن أن تستخدمه React بعد ذلك لتفادي قيام الأشخاص بشحن DEV إلى PROD بسهولة أكبر ، ولكن هذا سيكون تغييرًا جذريًا في Webpack. أتحدث إلى شون الآن حول مدى جدوى شيء من هذا القبيل لـ Webpack 3. الحفاظ على مكدس React + Webpack مبتدئ وصديق للأداء هو شيء أعرف أن كلا المعسكرين يهتم بهما.

الثانية (فكرة حقن DOM) هي شيء يمكن أن تفعله React وكما ذكر Jake ، قم بموازنة UX من خلال السماح بعرض الرسالة مرة واحدة في اليوم أو رفضها. إنه تغيير سطر واحد لإصلاح المشكلة ثم عليك فقط إعادة النشر. أنا أتعاطف تمامًا مع عدم الرغبة في أن تفزع الإدارة.

إذا أردنا الحصول على المزيد من مواقع React التي تشحن ، فإن التجربة الأسرع التي عمل عليها FB لحث شيء ما قد يضطر إلى تقديمه. إذا كان لدى أي شخص أفكار أفضل من فضلك اقترحها.

تضمين التغريدة

لماذا ا؟ (أنا لا أقول أنك مخطئ ، أود فقط أن أسمع أسبابك)

بالعودة إلى تعليقي أعلاه ، ما لم نتمكن من إعلام المطورين في وقت مبكر (والذي يبدو أنه المشكلة الفعلية التي يجب حلها) ، أجد أنه من المتطرف تقليل قيمة منتج شخص ما من خلال عرض تحذير للمطورين على صفحة الإنتاج الخاصة بهم. في كثير من الحالات ، قد يؤدي ذلك إلى الإضرار بالمنتج أكثر من أداء وضع التطوير.

بغض النظر عما نفعله ، شخص ما سوف يشحن كل ما هو افتراضي في الإنتاج ، فلماذا لا نتخلف عن الإنتاج؟ لماذا لا يتم تحسين وضع dev إلى الحد الذي لا يكون فيه تأثيرًا كبيرًا؟

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

jakearchibald نعم ، أرى أن كلا الجانبين لديهما مشاكل. لدي ثقة في الأشخاص الموجودين في هذا الموضوع للتوصل إلى شيء جيد ، حتى لو كان هذا هو ما تقترحه. أنتم رائعون لمعلوماتكم. ربما المتطرف هو الجواب.

هل يتعذر عليك إدراج تحذير عقدة DOM إذا كان المستخدم يشغل أدوات React dev بحيث لا يواجهها المستخدمون العاديون؟

تضمين التغريدة

لا يُسمح أيضًا بتشغيل المواقع مع وضع dev-mode. ربما الرسالة تحتاج فقط للرفض مرة واحدة في اليوم؟ ولكن كلما طالت الفترة ، زادت احتمالية أن ينتهي الأمر بها على الهواء مباشرة. إذا كان من الممكن تعطيله إلى الأبد ، فإننا نعود إلى حيث بدأنا.

عندما تم إطلاق الموقع ، اتخذ شخص ما قرارًا بأنه "جاهز" ، لذا في حين أنه سيئ فهو ليس كارثة. ومع ذلك (ربما ، لا أعرف الأرقام الدقيقة) مئات الآلاف من المطورين الذين يضطرون إلى رفض تدمير الموقع (يجب التعامل مع تحذير DOM على هذا النحو لأنه ليس لديك فكرة عن كيفية تفاعله مع بقية الموقع وإذا كان الموقع صالحًا للاستخدام مع وجود تحذير مرئي) فإن التحذير خمس أو حتى مرة واحدة فقط في اليوم يعد كارثة. تمتلك معظم المطورين سلسلة إنشاء تم إعدادها بشكل صحيح (مخصص ، أو إنشاء تطبيق تفاعل أو غير ذلك) وليس لديهم أي فائدة على الإطلاق لهذا التحذير ، يجب أن يكونوا قادرين على التخلص منه.

@ dan-gamble أعتقد أن المطورين لا يستخدمون أدوات تطوير React هو الهدف الأكثر إلحاحًا لهذا التحذير بالرغم من ذلك.

Pajn Potentially ، لا أعتقد أن مجرد تنزيل امتداد Chrome يجعلك تدرك تلقائيًا مفتاح prod / dev

@ دان - مقامرة لا ، بالطبع لا. لكن هناك أشخاصًا يطورون تطبيقًا كاملاً بدونه ، وأعتقد أنهم يشيرون إلى أنهم لا يستخدمون أدوات التطوير كثيرًا ، وبالتالي يقل احتمال رؤية التحذير الحالي للتعليمات البرمجية المصغرة.

لا أضيف عادةً إلى مثل هذه المناقشة الطويلة عندما أشعر أن النقطة قد تم طرحها بالفعل ولكن هذا يجب أن أتفق معه وأريد التأكيد على هذه النقطة: رد فعل لمس DOM وتحذيرني من استخدام إصدار مطور يكون خطأ كبيرا . وبقدر ما أعرف لا توجد سابقة لذلك في أي إطار آخر.

تخيل كل الدروس ، كل الملاعب ، كل المشاريع الجانبية الصغيرة التي تستخدم وضع dev لتعليم React. كل موقع اختبار صغير أقوم برميه معًا لاستكشاف شيء ممتع في React ، أو لمحاولة عزل حالة اختبار. إذا رد فعل من خلال تحذير على كل واحد من هذه المواقع التي اضطررت إلى تعطيلها يدويًا ، فسأكون مجنونًا بشكل لا يصدق. قد يبدو الأمر وكأنه والد متعجرف ولا يشجعك على استخدام React لأنه كلما حاولت القيام بشيء جديد فإنه يضربك على معصمك.

حتى تفعل ذلك كل ساعتين ؟ لا، شكرا. سيؤدي التذمر المستمر مثل هذا بالتأكيد إلى تثبيط المستخدمين عن التطوير في React وأعتقد بصدق أنه سيدفع الناس بعيدًا لتبني أطر عمل أخرى. ربما هذا ما يريده مطورو Chrome؟

ناهيك عن حقيقة أن هذا سينزلق إلى الإنتاج بطريقة ما ، ومن الصعب بالفعل إقناع فرق معينة بتبني React وهذا مجرد ذخيرة أكبر بالنسبة لهم ضدها.

أكثر ما أحبه في React هو أنها لا تفعل أي شيء حتى تتصل بـ ReactDOM.render(...) وعندما تفعل ذلك ، فإنها تضع الأشياء فقط في DOM حيث أخبرتها بذلك. لهذا السبب هي مكتبة جيدة ومعزولة وعملية.

هل نحتاج أيضًا إلى اكتشاف ما إذا كان الأشخاص يشحنون حزمة غير مصغرة؟ ماذا لو لم يتم تخزينها مؤقتًا ومتى يجب عليهم ذلك؟ ماذا عن عدم قيامهم بتكوين nginx بالشكل الأمثل؟ أو لا تستخدم shouldComponentUpdate عندما يجب عليهم ذلك؟ أم أنهم يعرضون كل شيء دون داع عندما لا يحتاجون إلى ذلك؟

هناك عدة أسباب لسوء الأداء وإلقاء اللوم فقط على وضع مطور React هو خطأ. عندما تنشر موقعًا ، فمن المتوقع تمامًا أن تفهم كيفية نشر موقع محسن. أنا لا أقول أنه لا توجد أشياء يمكننا القيام بها ، ولكن السبب الأساسي لذلك هو أن المؤلفين المعياريين لا يبذلون العناية الواجبة ولا ينبغي علينا دفع ثمن ذلك. نحن بحاجة إلى إيجاد طريقة أخرى لاستدعاء ذلك.

قصدت المتابعة مع ما أعتقد أنه الحل الصحيح: ضع هذه الأنواع من القيود في الأدوات. تأكد من أن حزمة الويب أو أي أداة تستخدمها لإنشاء موقعك للإنتاج هي المكان الذي يجب أن نفرض فيه هذه الفحوصات وأنا معطلة لأي نوع من القيود التي نريد وضعها في عملية الإنشاء.

فيما يتعلق بفرض حزمة الويب على إعداد NODE_ENV (ربما توجد مشكلة في هذا الأمر في الريبو بالفعل) ، ألا يجعل ذلك من الصعب استخدام المكتبات التي لا تعتمد على إعدادات env؟

أم أن فكرة أنه سيكتشف استخدام NODE_ENV ويفرضه فقط إذا كان الرمز يستخدمه؟

دعونا لا نتوقف كثيرا عن موضوع "الساعتين". يمكن أن تكون أي فترة زمنية طالما أنها تعمل.

بالإضافة إلى ذلك ، تعني أحداث التخزين المحلي أنه سيتعين فقط رفضه مرة واحدة لكل مصدر. إذا كان لديك العديد من العروض التوضيحية على صفحة واحدة ، فإن رفض أحدها سيؤدي إلى استبعاد الآخرين.

إذا دخل التحذير حيز التنفيذ ، فسيكون مرتفعًا بما يكفي لضمان إصلاح سريع - إصلاح يفيد المستخدمين. إذا كنا قلقين بشأن كيفية ظهور React في الأماكن العامة ، فنحن نريد حقًا تجنب التباطؤ غير الضروري مثل هذا.

بالتأكيد ، لن يكتشف هذا رؤوس التخزين المؤقت السيئة وما إلى ذلك ، فهذا يتعلق باكتشاف "وضع التطوير" فقط. كما أن حجج "المنحدر الزلق" ليست مفيدة.

لا أعتقد أن نقل المشكلة إلى أدوات الإنشاء مفيد ، حيث ستواجه نفس المشكلة إذا استخدم المطورون أداة إنشاء مختلفة ، أو فشلوا في وضع ذلك في وضع الإنتاج. تُصدر أطر عمل وضع Dev بالفعل تحذيرات وحدة التحكم ، ومن الواضح أن هذا لا يعمل.

لا يتعلق الأمر فقط بالمعايير ، بل يتعلق بالمواقع الحقيقية ، والتي تعمل ببطء للمستخدمين الحقيقيين ، لأنه لم يتم تبديل التبديل.

@ jakearchibald شكرًا على الرد العقلاني على ردي المشحون عاطفياً. أعتقد أنه من الصحيح أن هناك العديد من الأسباب التي تجعل الموقع بطيئًا مع React. أود أن أرى طريقة يمكننا من خلالها اقتراح تحسينات في الأداء أفضل من فحص أولي لوضع مطور وتحذير داخل المتصفح. إذا كانت لدينا أدوات لتحليل تطبيق React وتقديم اقتراحات جادة للأداء ، من كل شيء مثل وضع dev إلى عدد كبير جدًا من عمليات العرض ، فسيكون ذلك أكثر فائدة. يمكن ربط أداة عامة كهذه بأي خط أنابيب ، سواء أكان webpack ، أو browserify ، وما إلى ذلك.

هذا هو الشيء الرئيسي الذي أردت قوله: في بعض الأيام سأستخدم وضع React dev عبر 5-10 أماكن مختلفة ، مثل jsbin والبرامج التعليمية وحتى إنشاء موقع اختبار صغير وفتحه بالملف: // protocol. يعد التحذير القسري في المستعرض معاديًا لهذا النوع من التطوير المرن وهو ما تتفوق فيه شبكة الويب. سأرى هذه التحذيرات في كل مكان لأنني أتعلم React عبر المجالات على الويب.

إذا دخل التحذير حيز التنفيذ ، فسيكون مرتفعًا بما يكفي لضمان إصلاح سريع - إصلاح يفيد المستخدمين. إذا كنا قلقين بشأن مظهر React في الأماكن العامة ، فنحن نريد حقًا تجنب التباطؤ غير الضروري مثل هذا.

حتى السماح بإمكانية عرض تحذير خاص بالمطور للمستخدمين النهائيين يبدو غير مقبول بالنسبة لي. يعد الموقع البطيء شيئًا واحدًا ، ولكن رسالة كهذه يمكن أن تقوض ثقة المستخدم ، خاصة بالنسبة للمواقع التي تركز على الأمان (هل ستكون سعيدًا إذا كان موقعك المصرفي يعرض أخطاء مشفرة فجأة؟) يتلقى المستخدمون هذا التحذير فجأة ، حتى ولو للحظة؟

بالإضافة إلى ذلك ، تعني أحداث التخزين المحلي أنه سيتعين فقط رفضه مرة واحدة لكل مصدر. إذا كان لديك العديد من العروض التوضيحية على صفحة واحدة ، فإن رفض أحدها سيؤدي إلى استبعاد الآخرين.

لا يمكنك الاعتماد على localStorage لإلغاء ذلك. ليس هناك ما يضمن عدم مسح localStorage (أو أي بيانات محلية ثابتة أخرى) في أي فترة زمنية.

تحرير : أيضًا ، من خلال عرض الخطأ مرة واحدة فقط كل {INTERVAL} ، فإنك تجعل الأمر الآن أكثر صعوبة في إعادة إنتاجه وتصحيحه لأنه غير قابل للتكرار بشكل حاسم.

هناك حالتان يجب حلهما:

• منع الاختبارات المعيارية الزائفة واختبارات الأداء: يتم حلها بسهولة من خلال رسالة وحدة تحكم كبيرة كبيرة.
• منع شحن DEV إلى مواقع الإنتاج: لا يفتح الأشخاص أدوات التطوير في المنتج.

الحجج ضد لمس DOM مقنعة.

إذا كان هناك تحذير كبير وبراق وواضح من وحدة التحكم ، فمن المحتمل أنه قبل الشحن إلى الإنتاج ، سيستخدم الأشخاص إصدار dev ويرون رسالة وحدة التحكم الواضحة حقًا. أو ربما تم بالفعل شحن بعض الكود للإنتاج ، ولكن بالنسبة لمشروع آخر ، سيستخدمون الإصدار التالي الذي يتفاعل مع رسالة وحدة التحكم التي يستحيل تفويتها. ربما سيتذكرون ذلك الموقع الذي قاموا بشحنه للإنتاج والتحقق مما إذا كان DEV ممكّنًا هناك.

ستكون رسالة وحدة التحكم تعليمية ، مثل أي شخص يقوم بتطوير React يعرف أن هناك شيئًا مهمًا حقًا حول DEV ، ويرونه في كل مرة يستخدمون React من أجل التطوير.

كنت مترددًا بشأن https://github.com/facebook/react/pull/8782 لأن الناس عمومًا لا يحبون التحذيرات التي لا يمكنهم التخلص منها (انظر https://github.com/facebook/react/issues/ 3877) ، ولكن النظر في البدائل قد يكون حلاً مقبولاً.

فضولي. هل يستدعي استخدام localStorage قانون ملفات تعريف الارتباط في الاتحاد الأوروبي على موقع لا يشمله بخلاف ذلك؟

إذا كانت التحذيرات الإعلامية أثناء التطوير فكرة جيدة ، فلماذا لا تقوم المكتبات الأخرى بذلك؟ حسنًا ، أحد الأسباب هو وجود مشاكل كهذه. إذا أراد الآخرون القيام بذلك ، فهل يجب عليهم أيضًا ظهور واجهات مستخدم مماثلة؟ هل يجب عليك إغلاق كل منهم؟

يبدو لي أنه سيكون من المثالي وجود شيء مركزي للتعامل مع هذا الأمر.

ربما يمكن أن يكون لدى Chrome وضع تطوير؟ يمكن للمكتبات إخبار المضيف بأنهم في وضع التطوير ومن ثم يمكن لـ Chrome إضافة شارة أو منبثقة للإشارة إلى ذلك.

يجعلني أعتقد أنه يمكن الاستفادة من ملحق devtools التفاعلي لعرض إشعار أو شيء واضح عند فتح صفحة باستخدام رد الفعل في وضع التطوير ربما؟

تضمين التغريدة

إذا كانت التحذيرات الإعلامية أثناء التطوير فكرة جيدة ، فلماذا لا تقوم المكتبات الأخرى بذلك؟

أعتقد أن شخص ما يجب أن يكون الأول. لدى Angular مشكلة مماثلة ، حيث يتم تشغيل أشياء مثل http://code.gov في وضع dev. إذا بدأت React في التقاط هذه الأشياء حيث لا توجد أطر أخرى ، سأدفعها لإجراء تغييرات مماثلة.

سأدفعهم لإجراء تغييرات مماثلة.

jakearchibald هل تقترح أن يقدم كل إطار تحذيراته الخاصة؟ لا أعتقد أن وضع معيار لأطر العمل / المكتبات التي تقدم تحذيرات التطوير الخاصة بها في الإنتاج فكرة رائعة. ألا يجب أن نحاول التوحيد على المنصة؟ كما ذكر من قبل sebmarkbage

ربما يمكن أن يكون لدى Chrome وضع تطوير؟ يمكن للمكتبات إخبار المضيف بأنهم في وضع التطوير ومن ثم يمكن لـ Chrome إضافة شارة أو منبثقة للإشارة إلى ذلك.

أعتقد أن هذه فكرة رائعة. سابقة: يحتوي Safari على وضع منفصل يجب عليك تمكينه للوصول إلى DevTools. إذا فعل Chrome الشيء نفسه ، فيمكنه أيضًا إضافة مؤشر بأمان لوضع DEV وواجهة برمجة تطبيقات لتشغيله. لن يكون هذا المؤشر مرئيًا إلا للمطورين حتى لا يعطل تجربة المستخدم.

ألا يستغرق انتظار بائعي المستعرضات لتنفيذ مثل هذا الشيء وقتًا؟

jide نعم ، ولكن من المهم معالجة هذه المشكلة بشكل صحيح أكثر من السرعة. أيضًا ، يمكن تنفيذه في متصفح واحد قبل التفكير في جهود التقييس (إذا لزم الأمر).

تضمين التغريدة

هل تقترح أن يقدم كل إطار تحذيراته الخاصة؟

بالنظر إلى أن كل إطار يوفر وضع التطوير الخاص به (وقد يكون هذا الوضع مختلفًا تمامًا بين الإطارات) ، يبدو من العدل تمامًا أن يقوم الإطار بتنفيذ التحذير بطريقة فريدة مماثلة.

لقد بذلت المتصفحات بعض الشوط لتجنب تعريض أدوات devtools للصفحة. إذا جعلنا devtools حاجزًا للدخول هنا ، فسنفتقد الكثير من المستخدمين الذين لن يفوتهم تحذير DOM. لا يبدو تحذير DOM أبسط فحسب ، بل يحتوي على تبعيات أقل للنظام الأساسي ، وسيصل إلى المزيد من المطورين. أبسط وأكثر فعالية يبدو وكأنه فوز.

gaearon من جانب Chrome DevTools ، كنا نقوم بتبادل الأفكار حول "واجهة برمجة تطبيقات للانتهاكات" يمكن لمؤلفي إطار العمل والنظام الأساسي استخدامها للإشارة إلى التحذيرات المهمة. سيتم تقديم هذه في مكان ما مثل تحديث لوحة Audits القادم. يبدو مشابهًا لسؤالك ويمكن استخدامه لإطلاق تحذير عند اكتشاف وضع DEV.

بالنسبة لهذه المشكلة بالذات ، قد تسعى وراء شيء أعلى بقليل مما كنا نخطط له في الأصل. تتطلب لوحة الانتهاكات ، على غرار رسائل سجل وحدة التحكم ، أن تعرف أن اللوحة ستوفر نظرة ثاقبة. ربما تكون هناك غرفة تجربة مستخدم إضافية لشيء يعرض تراكب صفحة مرئيًا جدًا أسفل الصفحة والذي يمكن أن تقوم أطر العمل بتوحيده في المراسلة. التكرار في paulirish و @ s3thompson لأفكارهم بعد عطلة نهاية الأسبوع.

Fwiw ، أظن أن واجهة برمجة التطبيقات هذه لن تكون جاهزة لبضعة أشهر أخرى. عندما يكون متاحًا ، سيكون متاحًا فقط في Canary مبدئيًا وبعد 6-7 أسابيع قد يجعله مستقرًا.

لا يبدو تحذير DOM أبسط فحسب ، بل يبدو أكثر فاعلية.

أنا أتفق مع جيك بشأن هذا. دعنا نستمر في الدردشة حول حل DevTools ، لكني أود أيضًا معرفة ما قد يكون React مفتوحًا للقيام به كبديل في حالة عدم ملاءمة واجهة برمجة التطبيقات لاحتياجاتك أو أنها خارجة عن الجدول الزمني.

بالنظر إلى أن كل إطار يوفر وضع التطوير الخاص به (وقد يكون هذا الوضع مختلفًا تمامًا بين الإطارات) ، يبدو من العدل تمامًا أن الإطار يجب أن ينفذ التحذير بطريقة فريدة مماثلة.

jakearchibald ، هل تدرك أن إعداد هذا المعيار يعني أن الصفحات التي تستخدم أطر عمل متعددة (أو مكتبات تتبع في المجموعة) قد يؤدي إلى عرض قدر عشوائي من التحذيرات المشفرة غير الحتمية للمستخدمين النهائيين؟

لقد بذلت المتصفحات بعض الشوط لتجنب تعريض أدوات devtools للصفحة.

وأنا متأكد من أن السبب يعود جزئيًا على الأقل إلى عدم عرض الرسائل الخاصة بالمطور على المستخدمين النهائيين.

لا يبدو تحذير DOM أبسط فحسب ، بل يبدو أكثر فاعلية.

لا أحد يجادل ضد بساطة أو فعالية الحل. ستنجح ، ولكن على حساب المساومة على تجربة المستخدم. السرعة ليست الشيء الوحيد الذي يمكن أن يؤثر سلبًا على المستخدمين.

Fwiw ، أظن أن واجهة برمجة التطبيقات هذه لن تكون جاهزة لبضعة أشهر أخرى. عندما يكون متاحًا ، سيكون متاحًا فقط في Canary مبدئيًا وبعد 6-7 أسابيع قد يجعله مستقرًا.

addyosmani إذا كان الحل أفضل ، لا أرى كيف ستكون هذه مشكلة. أي تغييرات على React ستكون في إصدار رئيسي ، والذي أعتقد أنه سيتم تحديده لاحقًا فيما يتعلق بتوقيت الإصدار على أي حال.

الحل الذي تم تحديده سيؤثر بشكل محتمل على جميع التطورات المستقبلية. إن مسألة أسابيع مقابل شهور في هذا السياق مقبولة IMO.

أفهم أن بعض المطورين يشعرون بالغزو إذا قام إطار عمل بحقن شيء ما في DOM لم يضعوه بأنفسهم. لكني أشعر وكأنني لافتة في أسفل الصفحة تقول "هذا الموقع في DevMode" سيكون حلاً رائعًا لهذا ليس له تأثير كبير على تجربة المستخدم. أود أن أفهم لماذا يعتقد الكثير من الناس عكس ذلك.

aweary : إذا تم إطلاق موقع "يركز على الأمان" في DevMode ، فلا ينبغي الوثوق به حتى يتم إصلاح المشكلة. يمكن أن يتضمن "DevMode" جميع أنواع الاختصارات المتعلقة بالأمان مثل عمليات فحص CORS المعطلة أو كود مصدر القالب المكشوف وما إلى ذلك. إذا كان الموقع يركز على الأمان ، فيجب ألا يحدث هذا.

(أدرك أن "DevMode" له معنى محدد جدًا في React ، لكنني أحاول افتراض منظور غير مطور هنا)

تضمين التغريدة

أنت تدرك أن تعيين هذا المعيار يعني أن الصفحات التي تستخدم أطر عمل متعددة قد ينتج عنها قدر تعسفي من التحذيرات المشفرة التي يتم عرضها بشكل غير حتمي للمستخدمين النهائيين؟

أنا أدرك ذلك تمامًا. ستؤدي الصفحة ذات الأطر المتعددة في وضع التطوير إلى إلحاق ضرر جسيم بتجربة المستخدم دون سبب وجيه. يبدو أنك تفضل أن تمر دون أن يلاحظها أحد وغير مثبتة. أفضل أنه سيئ للغاية لغير المطورين (الرسائل المرئية التي تستهدف المطورين) بحيث يصلحها المطور على الفور ، مما يخلق تجربة مستخدم أفضل بكثير.

السرعة ليست الشيء الوحيد الذي يمكن أن يؤثر سلبًا على المستخدمين.

لا أرى أي شخص يدعي خلاف ذلك؟ أنا حزين جدًا بشأن هذا النوع من ردود الفعل 😞

يبدو أنك تفضل أن تمر دون أن يلاحظها أحد وغير مثبتة

jakearchibald هذا نوع من الاستنتاج الغريب ، لا أعتقد أنني سأقضي وقت فراغي هنا أتحدث معك إذا لم أرغب في إصلاح هذا؟ لمجرد أنني لا أتفق مع الحل الخاص بك لا يعني أنني استقلت لترك الأمر دون حل. هذا غير عادل حقًا.

أفضل أنه سيئ للغاية لغير المطورين (الرسائل المرئية التي تستهدف المطورين) بحيث يصلحها المطور على الفور ، مما يخلق تجربة مستخدم أفضل بكثير.

هذا ما أعتقد أنه غير مقبول بشكل أساسي: أنت تعاقب المستخدمين صراحةً أولاً.

إذا تم إطلاق موقع "يركز على الأمان" في DevMode ، فلا ينبغي الوثوق به حتى يتم إصلاح المشكلة.

إن وضع surma dev ليس غير آمن بطبيعته ، ولكن بغض النظر عن تجاوز الخط لافتراض أنه من الجيد بالنسبة لك توصيل ذلك للمستخدمين.

لا أعتقد أن الحل الذي يتطلب فتح أو تمكين أدوات التطوير كافٍ. لكي يتم ملاحظة ذلك ، يجب أن يكون مرئيًا لضمان الجودة والإدارة وربما للمستخدمين النهائيين. سوف يكون المطورون معتادون جدًا على رؤية هذا. على غرار كيفية تمييز تكوينات SSL الإشكالية. لا يلزم أن يكون كثيرًا ولكن يكفي ليكون ملحوظًا أن يسأل شخص ما عن ذلك ثم يتم إصلاحه.

يعد الحقن في DOM مشكلة لعدة أسباب. إنه أكثر جدوى إلى حد ما بالنسبة لـ React نظرًا لأننا مكتبة DOM ولدينا نقاط دخول DOM. من الصعب على المكتبات التي ليست خاصة بـ DOM وقد تعمل في عامل.

شيء واحد قد نكون قادرين على القيام به هو تغيير الأيقونة المفضلة طالما أننا نقدم طريقة لتجاوزها بشكل صريح. تحتوي العديد من المواقع بالفعل على رموز مفضلة منفصلة لوضع التطوير.

نحتاج إلى اكتشاف تجربة افتراضية للتعامل مع الأخطاء في React والتي قد لا تكون قادرة على إبقاء DOM في مكانه. يحذف التنفيذ الافتراضي الحالي في Master محتوى React من الشجرة إذا حدث خطأ. هذا هو أيضا الغازية.

إذا كانت لدينا طريقة لاكتشاف أنك لست في وضع التطوير ، فيمكننا تشغيل وضع الخطأ هذا. نحتاج حقًا إلى طريقة قوية للاشتراك في وضع التطوير بشكل دائم بعد ذلك.

على غرار كيفية تمييز تكوينات SSL الإشكالية.

هذا هو بالضبط نوع الشيء الذي أعتقد أنه سيكون مثاليًا. لقد اعتاد المستخدمون بالفعل على المتصفحات التي توفر معلومات الأمان حول المواقع التي يزورونها ، ومعلومات الأداء ليست قفزة كبيرة من هناك. بالإضافة إلى ذلك ، سيكون متسقًا لجميع الأطر / المكتبات التي تبلغ عن مشكلات الأداء المحتملة ولن تتداخل بشكل مباشر مع سير عمل المستخدم. 👍

تعجبني فكرة favicon: ملحوظة ، تعمل بدون أدوات تطوير أو امتداد ، ملحوظة من قبل الجميع ، لا تؤذي المستخدمين ، يمكن أن تكون متحركة للفت الانتباه ، مزعجة بما يكفي لجعل المطورين يريدون الاختفاء.

ماذا عن تفعيل وضع DEV؟
نحن نخطئ في جانب "تجربة المستخدم الجيدة" ، لأنه من السهل ملاحظة DX السيئ (و IMHO بالنسبة لمشكلات مثل هؤلاء المستخدمين يجب أن "يفوزوا" لأنهم لا يستطيعون الاختيار ، بينما يستطيع المطورون ذلك).
أنا متأكد من أن بعض الأطر تفعل ذلك بالفعل (مثل Relay إذا كنت أتذكر بشكل صحيح).

مقترحات حول كيفية تنفيذه:

• تمكين وضع التطوير فقط إذا تم تعيين NODE_ENV صراحة على development
• تمكين وضع التطوير إذا كان __DEV__ العالمي هو === true
• تصدير وحدة أدوات التصحيح ليتم تمكينها في userland

يبدو الأول هو الأفضل لأنه قد يكون الاثنان الآخران مشفرين بدون حارس (مثل بيان 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"] }
);

إذا كان النطاق الحالي مدرجًا في القائمة ، فلن يظهر تحذير dev مطلقًا. خلاف ذلك ، فإنه يفعل. في ظل هذا النظام:

• استخدام dev build على جهازك المحلي باستخدام localhost أو 127.0.0.1 : لا يوجد تحذير للمطورين على الإطلاق ، ولا يلزم اتخاذ أي إجراء من المطور.
• باستخدام dev build على جهاز dev باستخدام اسم مضيف آخر : تحصل على تحذير DOM حتى تضيف اسم المجال إلى القائمة التي تم تمريرها إلى render . بعد ذلك ، لن تحصل أبدًا على تحذير DOM.
• باستخدام dev build على جهاز prod : تحصل على تحذير DOM حتى تقوم بتبديل React إلى إصدار prod.

الشيء الوحيد الذي يقلقني بشأن هذا الحل هو أنه قد يدفع المطورين إلى ترك قائمة بجميع نطاقات خوادم التطوير الخاصة بهم في الكود ، وقد يصل هذا الرمز إلى الإنتاج. بالنسبة للشركات التي تعتبر نطاقات خوادم التطوير الخاصة بها سرًا ، ستكون هذه مشكلة. أفكار؟

aickin المشكلة في هذا النهج هي أنه يتطلب من المستخدمين أن يكونوا على دراية بالتكوين ، وبالتالي المشكلة التي يحلها. تكمن المشكلة في أن الأشخاص ليسوا على دراية بالتمييز بين dev / prod في المقام الأول.

تحرير : فما باللك ، أرى أنه لا يزال هناك تحذير DOM قيد التطوير.

تعمل البيئات الموجودة على جانب الخادم على إصلاح هذا من خلال إظهار صفحة خطأ "خاصة" تتضمن تفاصيل تصحيح الأخطاء وتخبرك أيضًا بعدم عرضها في الإنتاج.

نظرًا لأننا نخطط لجعل React "تفشل بسرعة" وإلغاء تحميل المشاهدات ما لم تقدم حد خطأ مخصص ، فقد نضيف أيضًا حد خطأ افتراضي "المربع الأحمر" في التطوير والذي يعمل كصفحة تعليمية.

بعد ذلك ، في المرة الأولى التي يكون فيها المستخدم لديه خطأ في الإنتاج ، سيرى رسالة خطأ مطولة خاصة. قد تكون هذه فرصة للتثقيف حول إنشاء DEV.

لكني أشعر وكأنني لافتة في أسفل الصفحة تقول "هذا الموقع في DevMode" سيكون حلاً رائعًا لهذا ليس له تأثير كبير على تجربة المستخدم. أود أن أفهم لماذا يعتقد الكثير من الناس عكس ذلك.

يكره معظم المستخدمين تطبيقات الويب إذا كانوا يعرفون أنها تطبيق ويب ، فلماذا؟ نظرًا لأن العقلية الشائعة سابقًا للويب كانت أنه عندما يظهر على الشاشة يتم ذلك ، بغض النظر عن مدى سوء تصرفه وتعلم المستخدمين أن الويب سيء. ومع ذلك ، فمن الممكن تمامًا إنشاء تجربة مستخدم رائعة على الويب ، ولكن للقيام بذلك يجب أن أمتلك DOM. إذا قام شخص ما بحقن لافتات عشوائية في أماكن عشوائية ، فقد يبدأ العنصر الخطأ في التمرير ، أو قد يتسبب في إعادة رسم الشاشة بأكملها عند التمرير أو قد يتداخل مع إيماءات السحب أو أي شيء آخر على سبيل المثال. النقطة المهمة هي أنه طالما أن هذا الشعار مرفوع ، فلا يمكنني تطويره لأنني لا أعرف أن التجربة هي نفسها عندما اختفى هذا الشعار.

كحل إطار عمل ، أحب حقًا فكرة favicon ، فهي لا تعيق التطوير ، ولا تبدو غريبة للمستخدمين ، ولا من المحتمل أن تدمر UX ولكنها ستلاحظ. ومع ذلك ، فهي تعمل فقط لمكتبة أو إطار عمل واحد في ذلك الوقت ولا تعمل على الإطلاق للمكتبات التي تعمل في العمال. الحل الحقيقي هو وسيلة جيدة للقيام بذلك من خلال المتصفح الذي يمكنه دعم العديد من أطر العمل والمكتبات ويمكن الوصول إليه من جميع السياقات.

هناك حل آخر يدعم العديد من الأطر والملفات اللاصقة وهو أكثر وضوحًا ، لكنه يتطلب طلب إذن ، وهو إظهار إشعار المستعرض.

وإليك فكرة: قم بتحديث مستندات البدء على الصفحة الرئيسية لـ رد فعل لدفع إنشاء تطبيق رد فعل بشكل أكبر. وشدد على أهمية بناء npm في تلك المستندات. لا نحتاج إلى تحذير DOM ، بل نحتاج إلى الوعي.

أعتقد أن ropilz قد تطرق إلى هذا سابقًا في الموضوع بتعليقه "_ .. يمكننا حتى ربط أي خدمة نريد إخطار devs .._" بتعليقها ، ولكن ربما لم يتم ملاحظتها (أو لم يتم الاعتراف بها).

كما أفهمها ، فإن المشكلة الأساسية التي يتم حلها هنا هي

• لتنبيه _developers_ بطريقة أو بأخرى عندما يواجه المستخدمون _ النهاية_الإنتاج موقعًا يعمل في وضع التطوير
• لا يمكننا الاعتماد على مطوري البرامج الذين يرون رسائل console.log (أو حتى تحذيرات DOM لهذه المسألة) في الإنتاج ، _ ما لم يكن هؤلاء المطورين يستخدمون بنشاط موقع الإنتاج بأنفسهم (أو نعتمد على المستخدمين النهائيين ، QA / فرق الدعم وما إلى ذلك لإبلاغ المطور بهذه التحذيرات)
• هناك وسيطات UX (صالحة) _ ضد_ تعرض للمستخدمين النهائيين تحذيرًا مرئيًا لـ DOM مخصصًا لجماهير المطورين.

ماذا لو كان هناك شيء مشابه لـ CSP report-uri ، لأطر العمل لإرسال تحذيرات وضع dev إلى ، بدلاً من إظهار تحذير في الموقع على الموقع حيث تكون مرئية للمستخدمين النهائيين؟

من الواضح أن هناك عددًا من الأشياء التي يجب مراعاتها ، مثل:

1. من الناحية المثالية ، سيتم تشغيل مثل هذه التقارير افتراضيًا ، ولكن ماذا سيكون الإعداد الافتراضي report-uri ؟ (هل نتوقع أن يستضيف كل إطار خدمته المجانية ، على غرار https://report-uri.io؟ (قد يكون هذا ممكنًا لأطر العمل الكبيرة التي ترعاها الشركة مثل React & Angular ؛ ولكن بالتأكيد غير عملي لأطر العمل مفتوحة المصدر الأصغر مثل Preact و Vue وما إلى ذلك)
2. بمجرد الإبلاغ عن تحذير ، كيف يتم إخطار مالك / مطور الموقع؟ (ربما تكون طريقة جيدة لغير المطورين للمشاركة في مشروع ، من خلال التطوع لمراقبة هذه التقارير والمساعدة في تعقب / إخطار المشرف؟)

أعترف تمامًا أن هذا الاقتراح هو مجرد فقاعة فكرية ، ولم أفكر في مدى عمليّة هذا أو كيف سيعمل بالفعل ؛ لكنني أردت أن أثيره لأنه يبدو لي أن التحدي المتمثل في "الإبلاغ عن مشكلات الإنتاج" قد تم حله جزئيًا بالفعل لإعداد تقارير CSP / HPKP ، وربما يمكننا استكشاف شيء مشابه هنا؟

من المهم التراجع خطوة إلى الوراء وإدراك أن React هي إطار عمل. لا يجب عليك:

• قم بتعديل DOM لتقديم شيء ما بشكل مرئي فقط كتذكير للمطورين . لا توجد طريقة تعمل بشكل جيد خارج الصندوق ما لم تفهم وتطور شيئًا يمكن أن يعمل في جميع البيئات دون إعاقة المطورين وفقدان ثقة المستخدم في حالة ظهوره في الإنتاج (إذا كانت تجربتي تشير إلى أن هذا سيحدث بشكل متكرر ولن يتمكن الكثيرون من نشر حل سريع لإيقاف تشغيله).

• قم بتعديل الأيقونة المفضلة. يتم تخزين الأيقونة المفضلة مؤقتًا بشكل مزعج ، وتستخدم للإشارات المرجعية ، وأيقونات تطبيقات الويب المحفوظة على الأجهزة المحمولة إذا لم يتم تحديد الآخرين ، وما إلى ذلك. وهذا ينطوي على مخاطر نشر الإنتاج عن طريق الخطأ (أو عن قصد) في وضع التطوير ، مما يؤدي إلى محو شعار العلامة التجارية.

• إخطارات المتصفح. عندما ينظر إليك ، من المحتمل أن ينظر إليك مستخدم. سيؤدي ظهور إشعار إلى طلب أذونات المتصفح وانبثاق أشياء غريبة لن يفهمها المستخدمون. من وجهة نظري ، فإن افتراض أن المطورين سيشاهدونها في الغالب هو أمر معكوس تمامًا وربما يدمر الثقة للمستخدمين.

ليس من مهمة React مجالسة مطوري الأطفال. أقترح إما:

1. اجعل وضع التطوير مشتركًا. عندما يدرك المطورون أنهم لا يستطيعون تصحيح شيء ما ، سيبحثون عن كيفية تشغيله (الذي يحتاج إلى توثيقه في كل مكان ). لا ، ليست مهمة React أن تطلب منهم إيقاف تشغيله مرة أخرى. مشكلتهم.

2. اترك الأمر لرسالة console.log البسيطة (ويجب أن يكون هذا قابلاً للتعطيل). دع المطورين يجدونها ويتعاملون معها. إذا لم يفعلوا ذلك ، حسنًا. لا يمكنك الوصول إلى كل منظمة وجعلها تفعل الأشياء بشكل صحيح. إنها فقط غير قابلة للتطوير.

يجب أن لا أوافق على لمس DOM لعرض تحذير. يبدو الأمر سهلاً وبسيطًا لـ React لأنها مكتبة DOM ، لكن تخيل ما إذا كان على جميع المكتبات أن تعرض تحذيرها الخاص في DOM. ستكون فوضى تامة.

هناك العديد من المكتبات التي يستخدمها المطورون والتي من المحتمل أن يكون لها وضع التطوير الخاص بهم. أعتقد أن تعيين process.env.NODE_ENV إلى production كان بالفعل معيارًا شائعًا في تجميع الوحدات النمطية للمتصفح. هذا ما نحتاجه لتحسين الوعي.

أوافق على أن مستندات React لا تظهر بوضوح أن هناك فرقًا بين التطوير وبناء الإنتاج. عندما تفتح المستندات ، يجب عليك الانتقال إلى Advanced Guides لقراءة الفرق بين dev وبناء الإنتاج. العنوان هو تحسين الأداء ، وهو شيء لن يلقي نظرة على المبتدئين بالتأكيد لأنهم يستخدمون React لأنهم سمعوا أنه سريع. أعتقد أنه يمكن تحسين المستندات للحصول على مستندات أخرى بعنوان "استخدام React في الإنتاج" أو ما شابه ذلك في قسم البدء السريع .

لا يقرأ المبتدئون عادةً الأدلة المتقدمة ولكنهم سيفتحون بعض الروابط في البداية السريعة إذا كان العنوان واضحًا بدرجة كافية ويبدو مهمًا. أعلم أنني فعلت ذلك لأن هذا ما أفعله عندما أبدأ في تعلم React. لم أقرأ دليل البدء ، لكني قرأت بعض الصفحات في قسم البدء السريع.

هناك طريقة أخرى يمكننا اتباعها وهي إظهار تحذير في وحدة التحكم عند استخدام React في وضع dev مع رابط لإصلاح هذه النقطة في المستندات. يعد فتح وحدة التحكم في الإنتاج للمطورين أمرًا غير معتاد ، ولكن في البيئة المحلية عند التطوير سيفتحون وحدة التحكم بالتأكيد. بهذه الطريقة عند التطوير محليًا ، سوف يدركون أنهم بحاجة إلى القيام بشيء ما قبل النشر في الإنتاج.

تم إطلاق http://code.gov على الرغم من تحذيرات وحدة التحكم. هذا هو بالضبط نوع الشيء الذي يجب أن نهدف إلى منعه. (هذا الموقع هو Angular ، لكن الأمر نفسه ينطبق على React)

إليك مشكلة 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.

لم أستخدم Angular 2 من قبل (مما يجعلني مبتدئًا في هذه الحالة). رد فعلي الأولي بعد أن رأيت التحذير هو أنني فقط أحاول الاتصال بـ enableProdMode() . إنه لا يعمل. أعتقد أنه يمكن تحسين رسالة وحدة التحكم لحالة Angular. بدلاً من الاعتماد على السحر ، يجب أن يشيروا إلى المستندات.

عند فتح مستندات Angular ، لا أرى أي شيء حول إنشاء الإنتاج. أعتقد أن هذه مشكلة لكل من Angular و React. كلاهما يستخدم وضع التطوير ، لكنهما لا يخبران الأشخاص مسبقًا في المستندات حول كيفية تعطيله. هذا هو السبب في أن تحسين المستندات يمكن أن يقطع شوطًا طويلاً في تعليم المطورين

أنا لا أعارض إظهار تحذير المستخدم عندما يرتكب المطورون "أخطاء" ، ولكن إدخال بعض عناصر DOM العشوائية هو مجرد تدخلي. أحب الطريقة التي تتعامل بها المتصفحات مع مشكلة HTTPS حيث خصص المتصفح واجهة مستخدم لإظهار أن الموقع غير آمن. ليس لدينا واحد للحالة المتعلقة بالأداء. نظرًا للمخاوف المتزايدة بشأن أداء الويب بشكل عام ، لا أرى سبب عدم توصل بائع المتصفح إلى طرق لإخبار المستخدم أن الموقع الذي يزوره سيء.

يجب معالجة ذلك على مستوى الأدوات ، لذا من المحتمل أن يتمكن webpack و Babel من إخطار المطورين بفوائد تعيين NODE_ENV.

موافق علىpveyes ، لقد أوضحت نفس النقطة لفريق Angular.

matthewp ، هناك مشكلة أقدم بكثير حول هذا https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 وقد تواصل فريق Angular مباشرة وقدم لهم الحل - يبدو أن هناك القليل من الرغبة في تطبيقه. السؤال هو ، هل كان تحذير DOM سيجعل هذا الإصلاح أكثر إلحاحًا ، أم أنه منعه من التشغيل في وضع dev من البداية؟

السؤال هو ، هل كان تحذير DOM سيجعل هذا الإصلاح أكثر إلحاحًا ، أم أنه منعه من التشغيل في وضع dev من البداية؟

أكثر من المحتمل أن يروا التحذير في التنمية ، جوجل كيفية تعطيله ، وتعطيله. ثم نشرها في وضع dev دون أن تدرك ذلك في المستقبل لأنهم ينسون. أثناء التطوير ، تريد أن تبدو وكأنها إنتاج ، لذا لا يمكنك إدخال جزء عشوائي من DOM. لا يمكنك الحصول على نظام ضمان الجودة أو نظام التدريج الذي يرى هذا إما لأنه لن يكون مؤشراً على الإنتاج.

لذلك ينتهي بك الأمر مع مجموعة من الأكواد غير المرغوب فيها لتعطيل هذا الشيء الذي يفسد مع UX الخاص بالموقع. ليس الأمر كما لو أن المهندس الأصلي الذي قام بتعطيله أثناء التطوير سيتذكره بالضرورة ؛ ربما انتقلوا حتى قبل أن ينتقلوا إلى الإنتاج.

لست متأكدًا من كيفية عمل عملية النشر في code.gov ، ولكن إذا كان الأمر مشابهًا لما جربته كمقاول حكومي ، فإن نشر وضع التطوير العرضي في الإنتاج سيكون إما:

1. فرض التراجع الكامل عن النشر بالكامل (يستغرق بعضها 6 أشهر للحصول على الموافقة وتجميع كل شيء بدءًا من تغييرات واجهة المستخدم إلى تحديثات برنامج الخادم) ، على الأرجح في اليوم التالي ، ثم تحصل على اجتماعات وأوراق متابعة فيما يتعلق بما حدث و جدولة نافذة نشر جديدة (سيُطلب منك مرارًا وتكرارًا ، ما إذا كانت البرامج النصية أو خدمات قاعدة البيانات أو أيًا منها في وضع التطوير بسبب تحذير واحد في واجهة المستخدم). لقد رأيت هذا يحدث لأشياء بسيطة للغاية. في بعض الأحيان يمكنك الحصول على استثناءات ولكن YMMV.

2. سوف يلاحظها المستخدمون ، وسيتم تصحيحها ولكن نظرًا لأنه من المحتمل ألا تؤثر على الوظيفة ، فلن يتم تحديثها حتى نافذة النشر التالية. حتى يتمكن جميع المستخدمين من رؤيته لأسابيع أو شهور.

على الأقل كانت تلك تجربتي. النقطة المهمة هي أنه حتى لو لوحظ اقتحام DOM مباشرة بعد النشر ، فأنت لا تعرف ما هي البنية التحتية / العملية الخاصة بهم وقد لا يكون شيئًا يمكنهم إصلاحه على الفور (على الرغم من أنه ينبغي أن يكونوا قادرين على ذلك).

ستكون رسائل التحذير أكثر وضوحًا عند دمج # 7360 (المربع الأصفر). يمكننا أيضًا إضافة رسالة إلى المربع الأصفر (أطلق عليها اسم "React Development Mode Warnings"؟).

عند فتح مستندات Angular ، لا أرى أي شيء حول إنشاء الإنتاج. أعتقد أن هذه مشكلة لكل من Angular و React. كلاهما يستخدم وضع التطوير ، لكنهما لا يخبران الأشخاص مسبقًا في المستندات حول كيفية تعطيله. هذا هو السبب في أن تحسين المستندات يمكن أن يقطع شوطًا طويلاً في تعليم المطورين

إنه حق في صفحة التثبيت:

https://facebook.github.io/react/docs/installation.html#development -and-production-الإطلاق

وحول تحسين الأداء:

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

لا أعتقد أنه من العدل أن نقول إن المستندات ليست صريحة حيال ذلك.

عندما تفتح المستندات ، يجب عليك الانتقال إلى Advanced Guides لقراءة الفرق بين dev وبناء الإنتاج. العنوان هو تحسين الأداء ، وهو شيء لن يلقي نظرة على المبتدئين بالتأكيد لأنهم يستخدمون React لأنهم سمعوا أنه سريع. أعتقد أنه يمكن تحسين المستندات للحصول على مستندات أخرى بعنوان "استخدام React في الإنتاج" أو ما شابه ذلك في قسم البدء السريع.

إنه هناك ، في الصفحة الأولى (التثبيت):

https://facebook.github.io/react/docs/installation.html#development -and-production-الإطلاق

أنت على حق. اسف هذا خطأي. افترضت أن بنية الإنتاج موجودة في قسم مختلف ، لذا لم أبحث هناك وأبحث عن العنوان ذي الصلة في الشريط الجانبي بدلاً من ذلك (ووجدت صفحة تحسين الأداء). كان يجب أن أعرف أفضل.

أنا لست مبتدئًا في React ، ولهذا السبب عندما أفتح المستندات للتحقق من افتراضاتي - أن مستندات React ليست صريحة بشأن prod vs dev - لم أفتح مستندات التثبيت 🙇

لا قلق. إذا لم يكن مرئيًا بدرجة كافية ، فأنا منفتح على الاقتراحات من أجل وضع أفضل. على سبيل المثال يمكننا إنشاء صفحة مخصصة لها ( Deploying to Production ).

دعونا لا ننسى أن هذه المشكلة هي قضية مهمة يجب حلها ولكنها ليست القضية الأكثر أهمية التي يجب تسليط الضوء عليها. كما أنني لست مقتنعًا بأنه سيكون كافياً حتى لو تم إبرازه في الصفحة الأولى لأن الناس سيشاهدونه ويتصفحونه ، وينسونه ، ويفكرون "أنا أعرف ما أفعله". لذلك لن أبالغ في التركيز على موضوع المستندات.

الطريقة الحقيقية الوحيدة لمعالجتها هي الكشف والإخطار.

KrisSiegel يعد الحصول على الأيقونة المفضلة مؤقتًا نقطة جيدة. أتساءل عما إذا كان علينا تبديلها بعد ثانية أو ثانيتين ثم اقلبها مرة أخرى لفترة وجيزة كل بضع ثوان. بهذه الطريقة ، من غير المرجح أن تقوم مشكلة التخزين المؤقت والإشارات المرجعية بتحديد وقتها في وقت الرمز الذي تم تجاوزه.

اعتقدت أن تلاعبات JS إلى الرموز المفضلة لا يتم تخزينها مؤقتًا ولكن ربما أكون مخطئًا.

أود أن أزعم أن المكان المناسب للحصول على خطافات لهذا ليس Chrome أو Firefox ، بل هو webpack أو Browserify أو Rollup.

بناء ما يُقصد به كحزمة إنتاج لـ React ولكن بدون تمكين وضع الإنتاج هو مجرد خطأ في البناء. أعتقد أن سبب عدم وجود اتفاق حول كيفية تقديم هذا في وقت التشغيل يعكس عدم كون هذه المشكلة يجب معالجتها في وقت التشغيل.

taion أوافق. أعتقد أن هذا ينتمي بالتأكيد إلى أداة البناء ، وليس في DOM.

أعتقد أنه يجب أن يكون مكان أدوات البناء لفرضية أنه يجب تعيين بيئة العقدة على الإنتاج من أجل كود الإنتاج. قد لا يكون مطلوبًا لجميع المشاريع ، لكنني أعتقد أنه افتراض جيد.

إذا تم تشغيل npm run build في المحطة ، ولم يتم ضبط البيئة على الإنتاج ، فيجب أن تحصل على تحذير أحمر في الجهاز مع الناتج الافتراضي: env is not set to production, some scripts may be in development mode

حاليًا لا أحصل على مثل هذا التحذير من webpack.

تحرير: توضيح مضاف

أو فقط قم بتعيين NODE_ENV لك حقًا.

إذا كانت تحذيرات وحدة التحكم لا تعمل ، فلست متأكدًا من أن تحذيرات الإنشاء ستعمل.

يجب أن يقوم الإصدار إما بتهيئة الأشياء نيابةً عنك ، وإلا فسوف يفشل إذا تم تكوينه بشكل خاطئ للإنتاج. على الأقل بالنسبة لـ React ، هذه _is_ علامة وقت بناء.

jakearchibald أنا متأكد من أنه سيظل يتجاهل البعض ، ولكن على الأقل سيظهر التحذير لهم عند إنشائه ، بدلاً من عدم رؤيته لأن التحذير مخفي بعيدًا في وحدة تحكم المتصفح التي قد لا يفتحونها أبدًا في الإنتاج . والأهم من ذلك أنه يمنح أولئك الذين لديهم خبرة أقل فكرة عما ينبغي عليهم فعله لجعل إنتاج الكود جاهزًا.

في حين أن العديد من المطورين يقومون بتحديث المكتبات ، فمن الشائع عدم تحديث حزمة الويب والأدوات بشكل عام ، لأن الكثير من الناس يفترضون أنها تعمل فقط ، وقد يكون تحديث webpack و co.

بناء ما يُقصد به أن يكون حزمة إنتاج لـ React ولكن بدون تمكين وضع الإنتاج هو مجرد خطأ في البناء.

يعد استخدام نسخة جاهزة من React من CDN أيضًا تكوينًا مدعومًا ، ولكن لا توجد خطوة بناء على الإطلاق في سير العمل هذا. لذلك ، فإن حل هذه المشكلة الذي يركز فقط على البنية سيتجاهل حالة استخدام CDN.

أنا بصراحة لست متأكدًا من شعوري حيال ذلك ؛ يمكنني رؤية الحجج المؤيدة والمعارضة لوجود تحذيرات مطوّرة لاستخدام React CDN.

taion بصفتك شخصًا يدعم حل البناء فقط ، هل تعتقد أن هذه حالة استخدام مهمة يجب تغطيتها؟

ماذا يعتقد الناس الآخرون؟

أعتقد أن التوثيق هناك واضح تمامًا أنه يجب عليك استخدام حزم .min.js للإنتاج. ربما يمكن أن يستخدم حجم خط عريض ، أكبر ، شيء من هذا القبيل. ولكن إذا كان شخص ما يستخدم حزمة React غير المصغرة في الإنتاج لموقعه على الويب ، فستواجه مشكلات أخرى على أي حال.

أعتقد أن التوثيق هناك واضح تمامًا أنه يجب عليك استخدام حزم .min.js للإنتاج.

موافق ، ولكن الصفحة أيضًا واضحة جدًا حول كيفية تكوين أداة البناء الخاصة بك للإنتاج إذا قمت بتضمين React كحزمة npm. أعتقد أن بيت القصيد من هذه المشكلة كان محاولة خلق حفرة من النجاح للأشخاص الذين لا يقرؤون بعناية تلك الصفحة من التوثيق.

على الرغم من ذلك ، يبدو أنك قد لا توافق ، وأنك تعتقد أن استخدام أداة التطوير من CDN ليست حالة مهمة لمنعها من خلال تحذير مطور أكثر عدوانية. هل هذا ملخص عادل لموقفك ، أم أنني أفتقد بعض الفروق الدقيقة؟

أعتقد أن تكوين CDN + dev خاطئ بشكل أكثر وضوحًا ، لأنه يتطلب من المستخدم استخدام بنية غير محدودة من React. من الصعب أن تفشل بهذه الطريقة لأن عبء المعرفة المطلوب _فقط لاستخدام البنية المصغرة _ يكون أقل.

التكوين الذي تعتقد فيه أن الأشياء جاهزة للإنتاج لأنك قمت بتشغيل تصغير في webpack أو Browserify لكنك في الواقع لست كذلك لأنك لم تقم بتعيين NODE_ENV - لا يمكنك الحصول على ذلك عبر حزم CDN.

أعتقد أن علامة التبويب React في Chrome Developer Tools كافية لإخبارك بما إذا كنا في DEV Mode .

أعتقد أنه من الجدير بالذكر أن هناك سابقة لإطار عمل يضخ عنصر DOM في الصفحة في وضع dev:

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

على الرغم من أنه بقدر ما أستطيع أن أقول ، لا أعتقد أن هذا يعمل بشكل افتراضي.

بعد المناقشة أعلاه ، يبدو أن هناك هدفًا عامًا لتحقيق حل مثالي يلبي جميع القيود ولكنه يمنع بشكل موثوق الجميع من العمل في وضع التطوير عندما لا يكون كذلك. ذكر OP أنه يجب أن تكون هناك مقايضة بين الخبرات المحتملة للمطورين والمستخدمين ، وأعتقد أن هذا هو الحال إلى حد كبير.

لمحاولة إعادة صياغة المشكلة:

• يصل عدد مواقع React غير الصفرية إلى الإنتاج دون تعطيل وضع التطوير
• نود تقليل هذا الرقم
• لا نريد إزعاج مطوري React
• لا نريد تأجيل الوافدين الجدد إلى React
• لا نريد أن يرى المستخدمون النهائيون للمواقع التي تم إنشاؤها في React تحذيرات مطوّرة مروعة
• لا نريد كسر المواقع بسبب وجود عناصر DOM أجنبية

بالنظر إلى ذلك ، أعتقد أن الخطوة الأولى اللائقة ستكون أن تعلن React في وضع dev أنها في وضع dev عبر console.warn أو console.info مع تعليمات للتأكد من أن هذا معطل للإنتاج تعيين.

من المؤكد أن هذا لن يلفت انتباه الجميع ولكنه _إنه بداية جيدة_ والذي يجب أن يقلل من عدد الأشخاص الذين يشحنون عن غير قصد إلى الإنتاج ولا يغلق أي أبواب للتحسينات المستقبلية.

بالنظر إلى ذلك ، أعتقد أن الخطوة الأولى اللائقة ستكون أن تعلن React في وضع dev أنها في وضع dev عبر console.warn أو console.info مع تعليمات للتأكد من تعطيلها لنشر الإنتاج.

ليس من الخطأ أن تكون في وضع التطوير رغم أنك ... تتطور. ما هي الاستدلالات الأخرى التي يمكن أن نستخدمها؟

أيضًا ، نظرًا لأن لا أحد يقرأ وحدة التحكم في الإنتاج ، أتساءل عما إذا كان بإمكاننا التخلص من المهلة بحيث يتم تسجيلها إذا كنت تستخدم حلول الإبلاغ عن الأعطال.

ليس من الخطأ أن تكون في وضع التطوير رغم أنك ... تتطور. ما هي الاستدلالات الأخرى التي يمكن أن نستخدمها؟

أعتقد أنه يجب أن يكون مشابهًا لإشعار React DevTools الحالي

رسالة إعلامية تذكرك بأنك في وضع التطوير وأنه يجب تعطيل وضع التطوير لمواقع الإنتاج. هذا (من الناحية النظرية) يجب أن يجعل المطورين يدركون أن هناك تمييزًا وأن هناك بعض الإجراءات التي يجب اتخاذها للتحضير لاستخدام الإنتاج.

كما تقول ، لن يرى أي شخص تقريبًا تحذير وحدة التحكم في الإنتاج الفعلي - وبحلول هذه المرحلة ، يكون الوقت قد تأخر قليلاً.

نأسف على أن يبدو الأمر وكأنه سجل عالق ، ولكن لا يبدو أن تحذيرات وحدة التحكم تعمل. على سبيل المثال https://code.gov.

نأسف على أن يبدو الأمر وكأنه سجل عالق ، ولكن لا يبدو أن تحذيرات وحدة التحكم تعمل. على سبيل المثال https://code.gov.

يظهر مثال مضاد واحد أنه ليس معصومًا عن الخطأ - لكنني لا أعتقد أن أي نهج سيكون كذلك.

إذا كان تحذير وحدة التحكم قادرًا على زيادة الوعي وتقليل عدد الأشخاص الذين يقومون عن طريق الخطأ بتشغيل وضع التطوير عندما لا ينبغي عليهم ذلك ، فإن هذا يبدو كخطوة في الاتجاه الصحيح. الكمال هو عدو الخير.

تضمين التغريدة

نعم ، ولكن إذا تم إعداد أداة الإنشاء الخاصة بـ code.gov باستخدام الخطافات هنا ، فهذا _ من شأنه_ أن يمنع المشكلة التي تلاحظها ، على الأقل في سياق React الذي يستخدم خطافات وقت البناء لهذا الغرض. إنهم يستخدمون حزمة الويب بعد كل شيء.

أنا لا أقول أن webpack يجب أن يصدر تحذيرًا بشأن البناء. أقول إن الإصلاح الصحيح هو إما أن حزمة الويب تعين لك process.NODE_ENV ، أو أن حزمة الويب هذه قد فشلت في الإنشاء افتراضيًا إذا حاولت إنشاء بنية إنتاجية بدون تهيئة الإنتاج المناسبة.

أردت الرد بسرعة على نقطة سابقة من addyosmani حول "انتهاكات" DevTools. نحن نصمم نماذج أولية تظهر مؤشرات أقوى لأخطاء معينة في Chrome DevTools ، لكن هذا العمل لا يزال مبكرًا جدًا ، وأنا أميل إلى الموافقة مع jakearchibald على أن إظهار تحذير (حتى لو كان مخيفًا أكثر من console.warn ) ليس كذلك حل جيد بما فيه الكفاية.

ماذا عن التقصير في الرد على وضع الإنتاج وتشغيل وضع التطوير إذا وفقط إذا كان NODE_ENV == 'development' أو اسم المضيف هو localhost / 127.0.0.1 ؟ سيحصل معظم المطورين على السلوك الصحيح خارج الصندوق وستكون هناك دائمًا طريقة لفرض وضع التطوير يدويًا إذا كنت بحاجة إلى ذلك حقًا.

يبدو أنه ليس من المثالي أن تستمر في ضرب هذا الفرع بما قد يكون شرطيًا معقدًا إلى حد ما (لأنك لا تحتاج فقط إلى الفشل في Node) طوال الوقت.

راجع للشغل ، -p (وضع "الإنتاج" ، والذي يتيح أيضًا التصغير بالإعدادات الافتراضية) في حزمة الويب 2 مجموعات NODE_ENV للمستخدمين: https://webpack.js.org/guides/production-build / # عقدة -متغير بيئة.

يبدو هذا منطقيًا تمامًا بالنسبة لي ، ويجب أن يمنع هذه المشكلة لكل شخص تقريبًا يستخدم حزمة الويب. لماذا الإصرار على التعامل مع أي من هذا في وقت التشغيل؟

راجع للشغل ، -p (وضع "الإنتاج" ، والذي يتيح أيضًا التصغير بالإعدادات الافتراضية) في حزمة الويب 2 مجموعات NODE_ENV للمستخدمين: https://webpack.js.org/guides/production-build/#node -environment-variable.

نعم. نحن على علم بهذا. TheLarkInn من Webpack core يمكن أن يؤكد بالتأكيد ، لكن ما أفهمه هو أن -p لا يستخدم على نطاق واسع في أجهزة الصراف الآلي لمجتمع Webpack. تكمن المشكلة الأساسية هنا أيضًا في أنه إذا تم قبول أي حل ، على غرار الوضع الراهن مع تحذيرات console.log ، فمن غير المحتمل أن نرى تغييرًا حقيقيًا لمستخدمي React. نريد أن نمنح الناس تغييرًا أفضل عند شحن الشيء "السريع".

من الجدير بالذكر أن عدم القدرة على اكتشاف بيئات DEV و PROD بسهولة في Webpack (-p كونها غير كافية) تسبب أيضًا في بعض الألم في https://github.com/webpack/webpack/issues/3216.

أنا أقول إن الإصلاح الصحيح هو أن حزمة الويب تحدد العملية NODE_ENV بالنسبة لك ، أو أن حزمة الويب تلك قد فشلت في الإنشاء افتراضيًا إذا حاولت إنشاء بنية إنتاجية بدون تهيئة الإنتاج المناسبة.

أنا مستعد لمتابعة هذا ولكن سيكون تغييرًا جذريًا لـ Webpack مما يمكنني قوله. أنا شخصياً أشعر أن حل وقت التشغيل الذي يتضمن رسالة تراكب واضحة _ فقط_ معروضة باستخدام بعض الأساليب الاستدلالية الذكية (المضيف المحلي ، DevTools مفتوح ، إلخ) سيغطينا بشكل كافٍ.

ومع ذلك ، نظرًا لأننا نواصل الرجوع إلى عملية Webpack. عنصر NODE_ENV ، سأكون فضوليًا إذا كان لدىsokra أو TheLarkInn أي آراء حول هذا العنصر .

يختلف فهمي عن فهمك هناك - أعتقد أن -p هي الطريقة الواقعية التي يستخدمها معظم المستخدمين غير الخبراء في webpack لإنشاء عمليات الإنتاج.

حتى الحزم البارزة تستخدم -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 ، سيستخدم الأشخاص تصميمات غير مصغرة ، وفي هذه الحالة يواجهون مشكلات أكبر.

أنا شخصياً أشعر أن حل وقت التشغيل الذي يتضمن رسالة تراكب واضحة معروضة فقط باستخدام بعض الأساليب الاستدلالية الذكية (المضيف المحلي ، DevTools مفتوح ، إلخ) سيغطينا بشكل كافٍ.

أشعر أن هذا قد تم إسقاطه عدة مرات ("من غير المقبول لإطار عمل أن يضخ الأشياء في DOM") دون تقدير سيناريو _ فقط_ الذي سيحدث فيه هذا.

أنا معكم تمامًا بأن الاضطرار إلى التعامل مع رسالة دائمة وأشياء غير متوقعة في DOM باستمرار أثناء التطوير أمر غير مقبول. ومع ذلك ، فإن ما نقترحه هنا هو رسالة يتم عرضها إذا و _ فقط _ إذا تم نشر DevMode للإنتاج (أدخل الاستدلال!). يمكن تضمين عدد عشوائي من عمليات الفحص ورسائل وحدة التحكم في الأدوات و CI وامتدادات المستعرض لمنع حدوث ذلك.

ولكن كملاذ أخير يائس وآمن من الفشل ، أعتقد أن وجود لافتة مرئية على الشاشة هو حل جيد ومناسب.

يتم عرضه فقط إذا تم نشر DevMode في الإنتاج (أدخل الاستدلال!)

لذلك لن يرى مطور هذه الرسالة مطلقًا ، وينشر (ربما عن طريق الخطأ) وضع مطور في الإنتاج وفجأة يرون هذا HTML الجديد معروضًا على تطبيقهم ليراه جميع المستخدمين؟

هذا يبدو وكأنه عقاب بالنسبة لي. إذا كنت لا تفهم وضع dev بالفعل وقمت بالنشر باستخدام هذا الإصدار النظري الجديد من React مع الرسالة ، فستتفاجأ وسيشاهدها المستخدمون على تطبيق الويب في ذلك الوقت أيضًا. لا أرى كيف يساعد هذا أي شخص ولكنه يعمل على إحراج المطور أو الشركة. بالتأكيد ، ربما يدفعهم ذلك إلى إصلاحه ، لكن هذه التكلفة مرتفعة جدًا في رأيي وتفتقر إلى القليل من التعاطف.

ولكن كملاذ أخير يائس وآمن من الفشل ، أعتقد أن وجود لافتة مرئية على الشاشة هو حل جيد ومناسب.

تكمن مشكلة هذا الحل في أنه مثالي للغاية وعندما تقوم بتطوير إطار عمل ، يجب أن تركز على حقيقة أن الشركات الأخرى قد لا يكون لديها أكبر سياسات نشر أو حتى أفضل ضمان الجودة (إن وجد).

نعم ، إذا قام شخص ما بالانتشار في وضع التطوير في الإنتاج ، فيجب أن يكون قادرًا على رؤيته وتغييره بسرعة. لسوء الحظ ، خاصة خارج صناعة التكنولوجيا ، هذا ببساطة غير ممكن أو ليس بالأمر السهل . غالبية الناس علقوا هنا؟ من المحتمل أن يكون لدى شركاتهم عمليات نشر يمكنها التعامل بشكل جيد مع هذا السيناريو. جوجل ، فيسبوك ، بلاي ستيشن ، إلخ ؛ يمكن لجميع شركات التكنولوجيا هذه التعامل مع هذه الغرامة ولكن هذا لا يمثل غالبية المستخدمين الذين يستخدمون React ، أليس كذلك؟ (في الواقع ، هل لدينا أي إحصائيات تتعلق باستخدام React؟ هل سيكون مفيدًا!)

نعم ، نعم ، يجب على هذه الشركات والحكومات تغيير عمليات وسياسات النشر الخاصة بهم وما إلى ذلك. ولكن الحقيقة هي أن معظم الشركات لديها عمليات نشر هراء وحماقة إلى ضمان الجودة غير الموجود.

لنأخذ سيناريوهين مررت بهما شخصيًا.

أولاً ، أثناء العمل في الحكومة ، اعتمادًا على الفرع والقسم ، من المحتمل أن يكون لديك نشر واحد كل 3-6 أشهر. تعمل عمليات النشر هذه على تجميع أكبر قدر ممكن من العناصر ، وإذا فشل أي جزء من النشر بالكامل ، فقد يتم التراجع عن كل شيء. لذلك كنا نستخدم هذا البرنامج المسمى OWF والذي ، إذا لم تكن مألوفًا ، يشبه iSocial من حيث أنه يعرض تطبيقات ويب متعددة في تطبيق ويب واحد باستخدام إطارات iframe (إجمالي ، أعلم ، لكن ابق معي هنا). كانت هناك خطوة تهيئة يدوية في نشر العديد من تطبيقاتنا التي فشلت والتي تسببت في عرض أخطاء 404 و 500 في بعض إطارات iframe بدلاً من التطبيق المقصود.

نظرًا لأن المطورين عادةً لا يستطيعون الوصول إلى النظام الذي يتم نشره فيه ، فقد استغرق الأمر عدة ساعات قبل أن نكتشف أي مشكلات. في تلك المرحلة ، كان علينا أن نجعل رئيسنا يتصل برئيس شخص آخر للاتصال برئيسه لإخباره أن ذلك لم يؤثر على أي شيء آخر حتى لا يتراجعوا عن عملية النشر بأكملها. ثم كان لدينا الكثير من الأوراق والوثائق لملئها قبل أن نتمكن من إعادة أي شخص لبعض التهيئة بعد عدة أيام. في غضون ذلك ، جلس التطبيق ، غير قادر على العمل ، خلال تلك الفترة الزمنية بأكملها.

ثانيًا ، عندما عملت في مجال التمويل ، كان لدينا نشر تم تضمينه عن غير قصد اسم مطور بدلاً من تخطيط عنصر فعلي على موقع الويب (أعتقد أنه كان يختبر شيئًا ما؟). على أي حال ، تمت ملاحظته على الفور ولكن من أجل إصلاحه ، كان علينا الحصول على عنصر تحكم في التغيير الطارئ الذي استغرق حتى وقت لاحق من ذلك اليوم. لذلك كان على عملائهم رؤية هذه اللافتة الغبية لمدة 8 ساعات كاملة تقريبًا قبل إصلاحها.

نقطتي هي: يجب توخي الحذر الشديد عند حقن عناصر عشوائية في DOM لم يضعها المطور هناك. خاصة إذا كنا نتحدث عن عرضه فقط في بعض السيناريوهات ، فعندئذ في المرة الأولى التي يراها شخص ما ، سيكتشف كيفية تعطيله بسرعة حتى لا يحتاجوا إلى إزعاجه مرة أخرى.

تضمين التغريدة

إذا كنت لا تفهم وضع dev بالفعل وقمت بالنشر باستخدام هذا الإصدار النظري الجديد من React مع الرسالة ، فستتفاجأ وسيشاهدها المستخدمون على تطبيق الويب في ذلك الوقت أيضًا.

كنت أشعر بالفضول لمعرفة ما إذا كانت أفكارك حول النهج مختلفة إذا تم عرض الرسالة فقط أثناء فتح DevTools (أي شيء من المحتمل أن يراه المستخدمون غير المطورين). توسيع فعال لإستراتيجية console.log الحالية التي يستخدمها React بالفعل اليوم.

كنت أشعر بالفضول لمعرفة ما إذا كانت أفكارك حول هذا النهج مختلفة إذا تم عرض الرسالة فقط أثناء فتح DevTools (أي شيء من شأنه أن يكون فرصته منخفضة في أن يراه مستخدمو الإنتاج من غير المطورين). توسيع فعال لإستراتيجية console.log الحالية التي يستخدمها React بالفعل اليوم.

إذا كانت لديك أدوات مطورة مفتوحة ، فمن المحتمل أنك ترى رسائل console.log لذا تبدو تغييرات DOM تعقيدًا غير ضروري لإدارتها بالإضافة إلى أنها زائدة عن الحاجة. يمكنك دائمًا جعل رسائل وحدة التحكم في React أكبر / مربي الحيوانات. ربما شعار ASCII React. شيء يجذب انتباه شخص ما إذا حدث أن ذهب هناك.

في النهاية ، على الرغم من أنني أعتقد أن شخصًا ما سيواجه هذا الأمر ، اسأل على Stackoverflow عن كيفية تعطيل التحذير ، سيقوم شخص ما بإرسال رمز يوضح لهم كيفية القيام بذلك ، ثم يقوم الأشخاص بتعطيله ببساطة إذا واجهوه. أدوات البناء عديدة والعديد من الأشخاص الذين تحدثت إليهم في الماضي وجدوا أنها مربكة أو صعبة (كان إصدار Babel 6 وقتًا "ممتعًا"). ستصادف الكثير من الأشخاص الذين لا يستخدمونها بشكل صحيح أبدًا.

على الأقل هذه تجربتي ¯ \ _ (ツ) _ / ¯

يا للعجب ، أخيرًا اشتعلت حتى أسفل الخيط. تمام. لقد كنت أفكر في هذا قليلا.

يمكن أن يفرض Webpack تحديد NODE_ENV الذي يمكن أن تستخدمه React بعد ذلك لتفادي قيام الأشخاص بشحن DEV إلى PROD بسهولة أكبر ، ولكن هذا سيكون تغييرًا جذريًا في Webpack. أتحدث إلى شون الآن حول مدى جدوى شيء من هذا القبيل لـ Webpack 3. الحفاظ على مكدس React + Webpack مبتدئ وصديق للأداء هو شيء أعرف أن كلا المعسكرين يهتم بهما.

لقد شعرت أن هذا هو المفضل لدي حتى الآن ولكني لم أبيع 100 ٪ بعد.

1. لذلك يمكن أن يفرض أن يتم تمرير ENV كلما قام أي شخص بتشغيل webpack. تشير رسالة خطأ مفيدة إلى أنه يجب عليك توفير متغير env لتشغيل webpack.

ومع ذلك ، يوفر هذا نقطة ارتداد كبيرة للمستخدمين. لا يقوم الجميع بالكتابة من أجل حث أو بيئة تطوير أو حتى معرفة ما هي البيئة. سأثير مشكلة على webpack / webpack للحصول على تعليقات حول هذا الأمر ، لأن شعوري الغريزي هو أن الجميع لن يرغب في ذلك ، وسواء كنت أوافق أم لا ، يجب أن نفكر في الرد.

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

2. سيكون الحل webpacky هو إنشاء مكون إضافي مستقل يمكن ربطه بدورة حياة المترجم ، والتحقق مما إذا كان قد تم تجريد الكود ، أو إذا لم يتم توفير ENV ، وإصدار تحذير أو خطأ من اختيارك.

ومع ذلك ، يمكنني أن أتخيل أن الرد هو "لكن لن يعرف المستخدمون أبدًا كيفية القيام بذلك وما إلى ذلك". وبالتالي CRA ، وبالتالي هذه المسألة الآن.

يمكننا إنشاء نمط محلل جديد يتحقق من حزمة React (أو أي حزمة fw تحتاجها).

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

التي من شأنها أن تنطبق تلقائيًا على تكوين برنامج التحويل البرمجي للمستخدمين دون الحاجة إلى المعرفة أو الاهتمام.

مرة أخرى فقط حقا العصف الذهني.

TheLarkInn أعتقد أن السلوك الحالي -p في webpack 2 كافٍ ، أليس كذلك؟ حالة الفشل الوحيدة هي إذا قام شخص ما بإعداد UglifyJsPlugin بنفسه ونسي القيام بـ DefinePlugin ، لكن هذا يبدو وكأنه حالة أقل احتمالًا بكثير.

taion نعم / لا

يطبق -p فقط "معالجات" الإنتاج على الكود الخاص بك ، ومع ذلك فإننا لا نفترض أي افتراضات و / أو ليس لدينا أي معرفة بما تم تعيين NODE_ENV عليه. هذا ما يجعل الناس بحاجة إلى استخدام DefinePlugin() .

لكنني أعتقد أنها أقرب منطقة "_reasonable_" إلى _guess_ أو _imply_ حيث يقوم المستخدم بتشغيل الكود الخاص به في ENV الإنتاج. سيكون هذا هو المجال الوحيد الذي نريده للتأكد من أن المجتمع والفريق على ما يرام.

TheLarkInn أعتقد أن هذا تغير في الإصدار 2: https://webpack.js.org/guides/production-build/#node -environment-variable

آه آسف هذا صحيح أنا مخطئ. ومع ذلك ، لا يتم استخدامه بشكل متكرر لأن الناس يريدون المزيد من التحكم الدقيق فيما يقومون بتحسينه. (مثل addyosmani المذكورة)

هل هذا حقا شائع جدا؟ عندما بدأت استخدام حزمة الويب ، بدا واضحًا أن -p هو الطريق الصحيح. كما أشرت أعلاه ، حتى المكتبات التي لديها الكثير من الأسباب لتطبيق المزيد من التعديلات لا تزال تستخدم -p .

يمكننا إنشاء نمط محلل جديد يتحقق من حزمة React (أو أي حزمة fw تحتاجها).

"حزمة الويب": {
"plugin": "ReactEnviornmentPlugin"
}
التي من شأنها أن تنطبق تلقائيًا على تكوين برنامج التحويل البرمجي للمستخدمين دون الحاجة إلى المعرفة أو الاهتمام.

TheLarkInn إذا كنت أقرأ هذا بشكل صحيح ، لتشغيل نمط المحلل ، ستحتاج حزمة التطبيق json إلى تحديد ReactEnvironmentPlugin يدويًا ، أليس كذلك؟ أم أنني أسيء فهم الاقتراح؟ :)

يمكنني أن أتخيل بعض سحر الدقة في Webpack الذي يكتشف أن مشروعًا يستخدم React ويقوم بالتبديل الصحيح للبيئة بالنسبة لهم ، ولكن هذا يبدو وكأنه اقتران محكم من تحسين خاص بإطار العمل إلى مجمع وقد لا يكون مرغوبًا فيه.

أقل من أنه سيكتشف التفاعل ، وأكثر من ذلك أنه سيكتشف حقول وصف وحدات js تتضمن حقل webpack مع مكون إضافي. لكنك على حق ، إنها مرتبطة بشدة وليست فكرتي المفضلة أيضًا.

لا أعتقد أن هذا يمنحك حقًا أي ضمانات ما لم يكن لدى webpack مفهوم وضع "الإنتاج" لمعرفة كيفية تكوين React - وهذا يبدو زائدًا نظرًا لأنه ، كما نوقش أعلاه ، -p يقوم بالفعل بالشيء الصحيح وهو ما سيصل إليه المستخدمون عمومًا عند إنشاء إنتاج مصغر باستخدام حزمة الويب على أي حال.

لقد تحدثنا عن هذا أكثر قليلاً وأعتقد أن هناك حلًا معقولًا.

لطالما فكرنا في تمكين "مربع تحذير" لتحذيرات React قيد التطوير. يمكنك مشاهدة العرض هنا (PR: https://github.com/facebook/react/pull/7360). يظهر فقط عندما يكون لديك تحذيرات ولكنها شائعة جدًا أثناء التطوير (ويجب إصلاحها دائمًا) ، لذلك من المفترض أن أي شخص قضى أكثر من خمس دقائق في تطوير تطبيق ما سيرى مربع الحوار ويدرك أنه موجود.

بعد هذا التغيير ، سيكون من الصعب أن تكون غير مدرك لوضع التطوير. من المحتمل أن تبحث عن "كيفية إزالة مربع حوار التحذير" وتتعرف على المزيد حول البناء للإنتاج. إذا لم تقم بذلك ، فمن المحتمل أن يتم نشر بعض التحذيرات في وقت ما ، وسوف يراها المستخدمون. أعتقد أنه في هذه الحالة لن يلوم الناس React في حد ذاتها لأننا لا نظهر فقط الصندوق على أنه بغيض - نحن فقط نفعل ما يفترض أن يفعله وضع التطوير.

(بالمناسبة ، لقد استخدمنا مربع تحذير مشابهًا قيد التطوير في Facebook لفترة طويلة ، لذا فهو يتوافق مع الطريقة التي نعتزم استخدام React بها.)

أنا سعيد حقًا برؤية هذا الاقتراح ،gaearon! إنه كل شيء حلمت به ؛)

فقط كجانب: ربما يجدر التفكير في وجود رابط في المربع مباشرة لعدم مطالبة المطورين بـ google لمعرفة كيفية التخلص منه.

نعم ، نقطة جيدة. سنضيف شيئا.

gaearon أجد هذا الحل بغيضا للغاية ؛ لا أريد أبدًا تحذيرات لغزو DOM حتى أثناء التطوير. هذا لا يخدم أي غرض للمطور المشترك ومن المحتمل أن يتم تعطيله بالكامل من قبل معظم. تعرض أدوات المطور تحذيرات لسبب ما ، فلا داعي للاختراع.

كما أنني أجد أنه من المزعج أن حلول DOM تستمر في الظهور بدون أي رد على أي من الحجج السابقة ضدها. إذا كان سيتم تجاهل نقاطي ، فلا بأس بذلك ، فهذا ليس مستودعي ، لذا فهذا عادل بما فيه الكفاية ، ولكن من المحبط أن ترى نفس الحجة تظهر ، وينشر الأشخاص ضدها ، ويبدو أن الناس يؤيدون النقاط لأنه لا يوجد أبدًا أي جدال ضدهم ، ثم يعودون فورًا. اشطف ، كرر.

بينما أوافق على صحة هذا فيما يتعلق بمعظم التحذيرات ، تشير تحذيرات React على وجه التحديد إلى الأخطاء الموجودة في التعليمات البرمجية الخاصة بك. هم ليسوا مجرد اقتراحات.

من السهل رفض مربع الحوار ومن السهل تأجيل التحذيرات الفردية (في حالة عدم اهتمامك بها لفترة من الوقت) ولكنها بحاجة إلى الإصلاح.

للمقارنة ، هكذا يبدو مربع الحوار في قاعدة بيانات Facebook:

لا يعاني آلاف المهندسين من هذه المشكلة وهم أكثر إنتاجية بفضلها ، لذلك نعتقد أنها تقصير معقول. للتوضيح ، سيكون إصدار المصدر المفتوح أقل صراخًا:

إذا كانت لديك اقتراحات حول تعديلات النمط ، فلا تتردد في التعليق على https://github.com/facebook/react/pull/7360.

إضافة إلى ما قاله دان ، أقوم بالبناء فوق # 7360 للربط بتدفق مسجل الأخطاء الذي تمت إضافته مؤخرًا. أحاول حاليًا تجربة نوعين من إخطارات التوست الأقل تدخلاً. سأقوم بنشر بعض لقطات الشاشة و / أو Plnkr قريبًا للتعليق.

هل ستتضمن هذه التحذيرات تحذير "رمز المطور المصغر"؟ هذا من شأنه أن يحل الكثير من الأشياء بدقة إذا كان الأمر كذلك.

لا أفهم سبب عدم إمكانية استخدامه لهذا الغرض.

تضمين التغريدة

بينما أوافق على صحة هذا فيما يتعلق بمعظم التحذيرات ، تشير تحذيرات React على وجه التحديد إلى الأخطاء الموجودة في التعليمات البرمجية الخاصة بك. هم ليسوا مجرد اقتراحات.

ينبغي أن تكون تلك أخطاء أو استثناءات IMO. لماذا لا؟ تفرض الاستثناءات تصحيح الأشياء ولكن التحذير القابل للرفض لا يفعل ذلك.

لا يعاني آلاف المهندسين من هذه المشكلة وهم أكثر إنتاجية بفضلها ، لذلك نعتقد أنها تقصير معقول.

لقد ذكرت هذا في نقطة سابقة ولكني أعتقد أن هؤلاء المهندسين على الأرجح أفضل من 90٪ من الأشخاص الذين سيستخدمون الإصدار مفتوح المصدر. أجد أنه عكس التقصير المعقول. هناك سبب لوجود تحذيرات في أدوات التطوير ؛ إعادة اختراعها لا يعقلني. سيتم تعطيله ولن يتم رؤيته مرة أخرى.

يبدو أن React تحاول فعل الكثير من IMO.

عندما قمت بالتعاقد مع الحكومة ، كان لدينا مكتبة مشتركة كان على جميع الواجهات الأمامية استخدامها. سيستغرق الأمر أخطاء في وحدة التحكم وعرضها كنخب منبثق. لم يتم نشره للإنتاج عدة مرات فقط من قبل فرق متعددة ولكن العديد من المطورين رأوه مرة واحدة ثم سألوا عن كيفية تعطيله بشكل دائم. أرى هذا على أنه أكثر من نفس الشيء.

لطالما فكرنا في تمكين "مربع تحذير" لتحذيرات React قيد التطوير. يمكنك مشاهدة العرض هنا (PR: # 7360). يظهر فقط عندما يكون لديك تحذيرات ولكنها شائعة جدًا أثناء التطوير (ويجب إصلاحها دائمًا) ، لذلك من المفترض أن أي شخص قضى أكثر من خمس دقائق في تطوير تطبيق ما سيرى مربع الحوار ويدرك أنه موجود.

أنا حقًا أحب # 7360 ،gaearon. يثلج الصدر سماع الدعم لإبراز الحاجة إلى التبديل إلى PROD لعمليات النشر في مربع التحذير الجديد. إنه جميل ومرئي.

إضافة إلى ما قاله دان ، أقوم بالبناء فوق # 7360 للربط بتدفق مسجل الأخطاء الذي تمت إضافته مؤخرًا. أحاول حاليًا تجربة نوعين من إخطارات التوست الأقل تدخلاً. سأقوم بنشر بعض لقطات الشاشة و / أو Plnkr قريبًا للتعليق.

bvaughn نتطلع إلى رؤية المزيد من التكرارات :)

بالنسبة للأشخاص الذين يشعرون أن نهج مربع التحذير قد يكون تدخليًا للغاية ، فإن المكتبات الأخرى (مثل VueJS) تعرض بالفعل تراكبات DOM أثناء سير عمل dev / iteration لتشجيع إصلاح الأخطاء أو المسارات البطيئة:

كانت تجربتي الخاصة أنه على الرغم من أنه يمثل إزعاجًا بسيطًا ، إلا أن هذه الرسائل أكثر وضوحًا مما قد تراه في وحدة التحكم. أشعر أن دان محق في أنه سيضع على الأقل مزيدًا من التركيز على وضع التطوير ليس شيئًا يجب نشره لحثه ونأمل أن يؤدي إلى المزيد من المواقع التي تشحن "الوضع الأسرع" إلى المستخدمين النهائيين.

بعد هذا التغيير ، سيكون من الصعب أن تكون غير مدرك لوضع التطوير. من المحتمل أن تبحث عن "كيفية إزالة مربع حوار التحذير" وتتعرف على المزيد حول البناء للإنتاج. إذا لم تقم بذلك ، فمن المحتمل أن يتم نشر بعض التحذيرات في وقت ما ، وسوف يراها المستخدمون. أعتقد أنه في هذه الحالة لن يلوم الناس React في حد ذاتها لأننا لا نظهر فقط الصندوق على أنه بغيض - نحن فقط نفعل ما يفترض أن يفعله وضع التطوير.

ينبغي أن تكون تلك أخطاء أو استثناءات IMO. لماذا لا؟ تفرض الاستثناءات تصحيح الأشياء ولكن التحذير القابل للرفض لا يفعل ذلك.

بينما يجب إصلاحها ، قد يكون لدي المزيد من الأمور الملحة في متناول اليد. على سبيل المثال ، غالبًا ما أقوم بعمل نموذج أولي / محاكاة لواجهات المستخدم ، وأثناء قيامي بذلك أكتب كودًا سريعًا وعادة ما يكون دون المستوى الذي يمكن لـ React التحذير منه. بينما أريد إصلاح هذه التحذيرات ، لا أهتم حقًا حتى أعرف أنني لن أتخلص من كل التعليمات البرمجية في الساعة التالية على الأقل. سيؤدي إجبار الأشخاص على إصلاحها على الفور إلى إبطاء التطوير التجريبي بشكل كبير.

بالنسبة للأشخاص الذين يشعرون أن نهج مربع التحذير قد يكون تدخليًا للغاية ، فإن المكتبات الأخرى (مثل VueJS) تعرض بالفعل تراكبات DOM أثناء سير عمل dev / iteration لتشجيع إصلاح الأخطاء أو المسارات البطيئة:

لقطة شاشة 2017-01-24 الساعة 10 57 11 صباحًا

هل أنت متأكد من أن هذا من Vue نفسها؟ يبدو كثيرًا مثل أخطاء إنشاء حزمة الويب التي يتم عرضها مع تراكب الخطأ من البرامج الوسيطة webpack-hot-middleware . إذا كانت هذه هي الحالة ، فسيكون الأمر مختلفًا تمامًا نظرًا لأن أدوات إنشاء وقت التطوير تضيف التراكب بدلاً من إطار عمل الواجهة الأمامية للأغراض العامة.

بشكل عام ، أنا أؤيد تراكب التحذير ، لكنني أعتقد أنه يجب أن يحتوي على نص توضيحي عليه يوضح ماهيته ، ولماذا يوجد ، وأنه يمكن ويجب تعطيله كجزء من إيقاف تشغيل وضع التطوير. خلف توسيع إذا كان ذلك طويلاً بعض الشيء - ولكن يبدو أنه مكان جيد مثل أي مكان آخر لتوصيل الرسالة.

أخشى التحديثات مثل 15.2.0 مع تراكب. نتوء طفيف وفجأة لديك مئات التحذيرات حول الدعائم التي يتم تمريرها إلى عُقد DOM. ربما أخطاء ، لكنني لا أعتقد أن تحذيرات الاستهلاك تنتمي إلى مثل هذا الفضاء التدخلي

ربما أخطاء ، لكنني لا أعتقد أن تحذيرات الاستهلاك تنتمي إلى مثل هذا الفضاء التدخلي

لا أعرف ما إذا كان قد تم الإبلاغ عن ذلك مسبقًا بوضوح ، ولكن الفكرة المتعلقة بتحذيرات المربع الأصفر (# 7360) لم تكن لإظهار _ all_ التحذيرات (إهمال أو غير ذلك). بدلاً من ذلك ، سيتم تسليط الضوء على بعض التحذيرات التي اعتبرها الفريق "مهمة بشكل خاص" بهذه الطريقة. من المفترض أن يبقى الباقي في وحدة التحكم.

على الأقل هذا ما استخلصته من المحادثة التي أجريتها أنا وتوم حول هذه الميزة قبل أسبوع أو أسبوعين.

كان تحذير الدعامة في 15.2 أيضًا خطأ IMO وليس مؤشرًا على MO العادي الخاص بنا. نود أن يكون لدينا طريقة للتحكم في مستويات التحذير من خلال الإصدارات الثانوية لتجنب ذلك.

السبب الرئيسي وراء عدم استخدام فريقنا لبناء الإنتاج هو أننا لا نستطيع تشغيل اختبارات وحدة JS ، نظرًا لعدم تضمين أدوات الاختبار.

أولاً ، جولة أخرى من الشكر لفريق React ( sebmarkbage و gaearon و tomocchino وغيرهم) لمناقشة هذه المشكلة معنا وكونهم منفتحين جدًا للتحدث إلينا حول الأداء والجوّال في BlinkOn وعمليات المزامنة الأخرى هذا الربع.

فحص الحالة

وفقًا لـaweary في https://github.com/facebook/react/pull/7360 ، تم تعليق حل Yellow Box لهذه المشكلة بالذات حتى اكتمال عمل React عالي الأداء V16 ولكن لا يزال من المفترض أن يحدث. https://github.com/facebook/fbjs/pull/165 يحتاج إلى الأرض ويتم تنفيذه في Fiber. يجب أيضًا تصميم واجهة برمجة تطبيقات عامة جيدة لفضح الخطافات. سوف أحتفظ بأصابعي 🤞

يبدو أن هذه المشكلة لا تزال سائدة

لا يزال عدد قليل جدًا من تطبيقات الإنتاج التي ظهرت عبر مكتبي يشحن وضع 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-version للوهلة الأولى بخلاف ذلك.

أفكار؟

السبب الرئيسي وراء عدم استخدام فريقنا لبناء الإنتاج هو أننا لا نستطيع تشغيل اختبارات وحدة JS ، نظرًا لعدم تضمين أدوات الاختبار.

أنا في حيرة من أمري بشأن هذا. هل تجري اختبارات على موقع الإنتاج؟ إذا لم يكن الأمر كذلك ، فما الذي يمنعك من استخدام بنية الإنتاج على موقع الإنتاج والتطوير في التطوير؟

بالنسبة إلى أي شخص آخر ، هل سيكون هناك دعم لـ https://facebook.github.io/react/docs/installation.html بما في ذلك وسيلة شرح واضحة ومرئية ضمن عنوان تثبيت React لتذكير الأشخاص بمراعاة وضع DEV في الإنتاج؟

بالتأكيد. تريد أن ترسل العلاقات العامة؟

بالتأكيد. تريد أن ترسل العلاقات العامة؟

أكثر من سعيد ل.

ربما تكون كلمة عن المعايير أمرًا رائعًا أيضًا للمساعدة في تثقيف أولئك الذين يقارنون الأداء بالتفاعل في وضع التطوير؟

يجعلني أعتقد أنه يمكن الاستفادة من ملحق devtools التفاعلي لعرض إشعار أو شيء واضح عند فتح صفحة باستخدام رد الفعل في وضع التطوير ربما؟

اعجبتني هذه الفكرة! لقد قمت بتجميع مجموعة من الرموز المقترحة لـ devtools (انظر facebook / رد فعل-devtools / سحب / 652).

نحتاج إلى تحديد كيفية اكتشاف dev vs prod React بطريقة آمنة للخلف وآمنة في المستقبل ، لكني أضفتها إلى جدول أعمال اجتماع يوم الاثنين.

لقد قمنا ببعض الخطوات المعقولة لمعالجة هذه المشكلة:

• تعرض الآن React DevTools (مع حوالي 700 ألف مستخدم) أيقونة حمراء مميزة لبناءات التطوير. يساعد هذا الأشخاص في التعرف على الفرق بين الإصدارات مبكرًا. كما أنه يخلق بعض الضغط من الأقران ، حيث يلاحظ المطورون ذلك على المواقع التي يزورونها ، ويقدمون تقارير إلى الأشخاص الذين يعملون عليها. لقد رأينا بعض المواقع الرئيسية تعمل على حل المشكلة في غضون أيام من طرحها.

• يرتبط الإشعار الموجود في React DevTools بموقعنا على الويب حيث نشرنا تعليمات لإنشاء بنية الإنتاج لجميع الحزم الرئيسية . كما جعلناها أكثر بروزًا على صفحة التثبيت .

• استمر إنشاء تطبيق React في اكتساب شعبية. يعلم هذا التمييز في وقت مبكر بأوامر منفصلة. يعرض أيضًا إشعارًا دائمًا حول وضع التطوير في الجهاز.

• يتم شحن React 16 Beta 1 (والإصدارات اللاحقة) مع react.development.js و react.production.min.js كأسماء ملفات لتوضيح أنه لا ينبغي استخدام الإصدار غير المصغر في الإنتاج.

أعتقد أننا قد نستكشف في المستقبل المزيد من الطرق لحل هذه المشكلة ، لكن في الوقت الحالي أشعر أنه يمكننا المضي قدمًا دون مزيد من الإجراءات الصارمة ، ومعرفة ما إذا كان ذلك مفيدًا. شكرا للجميع على المناقشة.