Three.js: استمر في دعم مكتبات JS جنبًا إلى جنب مع مكتبات ES6 JSM

إذا فهمت بشكل صحيح ، فإن الخطة ستستمر في تضمين "/build/three.js" بالإضافة إلى "/build/three.module.js".

نعم. ومع ذلك ، من المشكوك فيه ما إذا كان هذا النهج منطقيًا. عند إزالة examples/js ، لم يتبق سوى عدد قليل من حالات الاستخدام حيث لا يزال three.js و three.min.js مفيدًا.

سيكون من المفيد بالفعل إزالة three.js و three.min.js لأنه سيسمح لنا بتغيير نقطة دخول main npm للحزمة $ # $ 6 $ # $ ، راجع # 19575.

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

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

أعتقد أن على المستخدم الاهتمام بتحويل ES6 إلى ES5 إذا لزم الأمر. نفس الشيء بالنسبة لتصغير الكود أو المهام الأخرى المتعلقة بالبناء.

أعتقد أنك على صواب. إذا فهمت بشكل صحيح ، فإن الخطة ستستمر في تضمين " /build/three.js " بالإضافة إلى " /build/three.module.js ".

صحيح

تكمن مشكلة التعبئة من المجلد /examples في أنك تحتاج إلى استخدام ملفات من /examples/js عند استخدام /build/three.js وملفات من /examples/jsm عند استخدام /build/three.module.js ، ويعرف أيضًا باسم الحفاظ على الاتساق في طريقة التحميل.

لماذا ا؟ لأنه عند استخدام استيراد الوحدة النمطية ، فإن الكائن الرئيسي THREE لم يعد كائن js عادي THREE = {} ولكنه بدلاً من ذلك كائن وحدة نمطية للمستعرض الداخلي مغلق (غير قابل للتمديد) ، وبالتالي ، الملفات من /examples/js الذي يحاول كتابة خاصية جديدة في THREE object.

لذلك لا يمكنك خلط import * as THREE from '/build/three.module.js و THREE.WhateverExample = function() ...

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

هذا هو عادة مشكلة

يتضمن JS التقليدية

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

السابق:

<script>
// a script you can't modify already use the name THREE
var THREE = document.getElementById('div-nb-3')
</script>

<script type="module">
import * as foo from '/build/three.module.js'

THREE.appendChild( new foo.WebGLRenderer().domElement )
</script>

@ Mugen87 أنت محق 100٪. إذا تخلينا عن / أمثلة / js ، فقد نتخلى أيضًا عن three.js & three.min.js لأنها غير متوافقة بشكل أساسي مع أي من الوحدات الإضافية. ستكون حالة استخدامها مناسبة وهذا يكاد يكون مضمونًا لإحداث ارتباك.

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

وهو من وجهة نظري نهج سيء. يجعل الصيانة أكثر تعقيدًا.

أعتقد أن على المستخدم الاهتمام بتحويل ES6 إلى ES5 إذا لزم الأمر. نفس الشيء بالنسبة لتصغير الكود أو المهام الأخرى المتعلقة بالبناء.

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

أنا على استعداد للاهتمام بإنشاء / اختبار ميزات تحويل الشفرة اللازمة لإنشاء ثلاثة.min.js و three.js و / أمثلة / js من three.module.js و / أمثلة / jsm . بعد أن تم تحسين سير العمل في عملية الترشيح ، قد يتطلب الأمر بعض الصيانة البسيطة ولكن ذلك! = الحفاظ على نسختين متوازيين. بالنسبة للجزء الأكبر ، ستكون هناك حاجة فقط إلى رمز الجزء ليتم تحديثه على ملفات الوحدة وفي بعض الأحيان فقط قد تحتاج إلى إصلاح بعض عمليات التثبيت في الترجمة.

لدي ما يكفي من المشاريع التي تعتمد على البنية العالمية التقليدية وتتضمن أنني سأقوم بالعمل لأتمتة نقل الوحدات على أي حال. أعتقد أنه يمكننا على الأقل تضمين أمر في package.json وتسميته "legacy-build" والذي ينقل الوحدات إلى three.min.js و three.js و / أمثلة / js التي تتصرف بشكل مشابه للأصل الملفات الآن. لا يلزم حتى الالتزام بهذه الملفات أو إنشاؤها افتراضيًا. يمكننا أيضًا تحذيرهم من الدعم القديم ، فهم غير مضمونين للعمل ، نقترح استخدام الوحدات بدلاً من ذلك ، إلخ ...

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

أمر في package.json وأطلق عليه اسم "legacy-build" الذي يترجم الوحدات

يبدو معقولا. ألم يتم دمج بابل مؤخرًا؟ لذلك أعتقد أن هذا قد يكون ممكنًا كما هو

تحرير: للتوضيح ، وليس لقول الأمر الجديد ليتم تشغيله من قبل أي شخص باستثناء المستخدمين الذين يريدون البناء المذكور

هل من الرهيب حقًا الاحتفاظ بمحتوى js تقليدي يستخدم متغير عالمي بالإضافة إلى وحدة نمطية؟

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

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

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

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

إذا فهمت بشكل صحيح ، فإن الخطة ستستمر في تضمين "/build/three.js" بالإضافة إلى "/build/three.module.js".

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

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

ميخائيل،
في الواقع ، يعد الاحتفاظ بـ "three.min.js" لمدة سنتين إضافيتين على الأقل أمرًا لا بد منه.
ليس لأن كل عيناتي مبنية عليها.
ولكن نظرًا لأن عدة آلاف من الملفات وأفضل تطبيقات Google تستند إلى ذلك!
مثال: https://www.google.com/search؟source=hp&q=webgl+benchmark

من ناحية أخرى ، من وجهة نظري ، "three.min.js" تعني تطوير واختبار أسرع.
ناهيك عن أنه يعمل دون اتصال ولا تحتاج إلى مضيف محلي.
فقط ضع جميع الملفات في مجلد في مكان ما ، واستخدم Firefox وانقر نقرًا مزدوجًا فوق ملف HTML.
لطالما أحببت ذلك من أجل التنمية!

يجب أن يفكر ريكاردو أيضًا في كل هذه الأمور.
في صحتك

إزالة three.js و three.min.js شيء يمكن مناقشته والتخطيط له عند اختفاء examples/js . كان من المهم بالنسبة لي إبراز أهميتها المفقودة عندما لا يمكنك استيراد الملفات من examples/js بعد الآن.

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

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

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

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

لا يمكنني التحدث باسم المتعاونين الآخرين لكنني لن أغير رأيي بشأن هذا الموضوع. لقد أصوت لحذف examples/js مع إصدار ديسمبر في 2020 كما تمت مناقشته والتزامه هنا # 18749.

أصوت لحذف أمثلة / js مع إصدار ديسمبر في 2020 كما تمت مناقشته والتزامه هنا # 18749.

ليس لدي أي مشكلة في ذلك.
طالما يتوفر "three.min.js" لسنتين أخريين ...

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

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

لقد قرأت هذا الموضوع ولكن يبدو أنه إعلان أكثر من كونه تفسيرًا للقرار.

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

افترض أن التطور المبسط هو السبب الرئيسي للتحرك في هذا الاتجاه ، فهل هناك أسباب أخرى؟

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

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

نعم ، نقطة جيدة. يتعين علينا بالفعل إجراء عمليات اختراق قذرة مثل تضمين فئة Pass (الفئة الأساسية لجميع تصاريح FX) في EffectComposer فقط لضمان عدم كسر الكود القديم.

نقاط جيدة جدا في كل النواحي.

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

في الواقع ، يعد الاحتفاظ بـ "three.min.js" لمدة سنتين إضافيتين على الأقل أمرًا لا بد منه.

سيكون من الممكن دائمًا إنشاء بنية ES5 باستخدام Babel. السؤال الذي سنحتاج إلى الإجابة عليه عندما يتعلق الأمر بذلك هو ما إذا كانت المسؤولية عن ذلك تقع على عاتقنا أم على المطور باستخدام three.js.

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

ولكن نظرًا لأن عدة آلاف من الملفات وأفضل تطبيقات Google تستند إلى ذلك!
مثال: google.com/search؟source=hp&q=webgl+benchmark

هذا هو أفضل موقع يظهر لي من هذا البحث ، وهم يستخدمون R53 لذلك لا أعتقد أن هذا التغيير سيؤثر عليهم بشكل سيء للغاية: https://www.wirple.com/bmark/

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

looeee أنت تتطرق إلى بعض النقاط الجيدة. كما ذكر أعلاه ، أوافق على أنه من المنطقي إهمال ES5 three.min.js و three.js في نفس الوقت هنا. ربما ينبغي أن يكون ذلك مناقشة منفصلة خاصة؟

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

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

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

إذا قمت بعمل علاقات عامة لهذا وكان يعمل

أعني ، أنا سعيد برؤية هذا يبدأ

هل ستصوت حقا لرفضه؟

سيتم إيقاف جميع الرهانات إذا فشلت في تمرير الفحص 😂

هل هناك حقا مشكلة هناك؟

نعم ، حيث يجب ألا يروج المستودع لأنماط الترميز المهملة.

نعم ، حيث يجب ألا يروج المستودع لأنماط الترميز المهملة.

لم يتم إهماله رسميًا حتى الآن إذا لم نقم بإقالة three.js + three.min.js (تم الاعتراف بالإجماع على ITT أنه يجب علينا التخلص من هؤلاء أيضًا) ولديك نص بابل يجب عليك تشغيله يدويًا بنفسك هو بالكاد تأييد متوهج. أوافق على أنه يجب علينا بالتأكيد تشجيع الأشخاص على استخدام الوحدات بدلاً من ذلك ولدينا تحذير في نص بابل والملفات التي تم إنشاؤها حولها. لا أوافق على السماح للمساهمين بالعمل على برنامج نصي بابل معًا للأشخاص في المواقف التي لا يمكنهم استخدام الوحدات لأي سبب من الأسباب يروج لنمط ترميز مهمل. بشكل رئيسي لأنه لا تزال هناك مواقف يكون فيها استخدام الوحدات غير ممكن / غير عملي. يقر المحققون بهذه الحاجة. أعتقد أنه يمكننا إضافة ملف واحد بأمان للأشخاص الذين يحتاجون إليه للعمل عليه معًا.

أوافق على أنه من المنطقي إهمال ES5 three.min.js و three.js في نفس الوقت هنا.

قصدت أنه يجب علينا إهمال الأمثلة / js ، و three.min.js ، و three.js في نفس الوقت ، أي إزالة جميع أكواد ES5 في إصدار واحد بدلاً من توزيعها على إصدارات متعددة.

امين

نعم ، حيث يجب ألا يروج المستودع لأنماط الترميز المهملة.

لا يزال بإمكانك تشغيل ألعاب DOS في نظام التشغيل Windows 10.
وهذا لا يعني أن Microsoft تروج "لأنماط الترميز المهملة".

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

حسنًا ، دعونا لا ننسى أن إنشاء تطبيق جاهز للإنتاج يعني تجميع الكود الخاص بك :)

أقدر أدوات التجميع المتوفرة مثل Rollup ولكن أعتقد أنه يجب علينا التفكير في سؤالين:

• هل من العدل أن نفترض ما إذا كان المطورون يريدون استخدام ثلاثة في الإنتاج ، فهم بحاجة أيضًا إلى استخدام إحدى أدوات التجميع هذه؟
• هل من العدل إسقاط الدعم للمكتبات الأخرى التي تعتمد على تحديثات وحدات ES5 / UMD في مجلد الأمثلة؟

مشاعري الشخصية حول هذا:

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

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

ماذا علينا ان نفعل؟

دعونا نجمع وحدات ES6 في وحدات ES5 / UMD لتوزيع معين بعد كل إصدار.

نعم ، حيث يجب ألا يروج المستودع لأنماط الترميز المهملة.

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

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

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

دعونا نجمع وحدات ES6 في وحدات ES5 / UMD لتوزيع معين بعد كل إصدار.

أنا أتفق مع ما قاله looeee.

هل من العدل أن نفترض [...]

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

دعونا نجمع وحدات ES6 في وحدات ES5 / UMD لتوزيع معين بعد كل إصدار.

يمكن لأي شخص القيام بذلك ؛ هذه التكلفة ليست بحاجة إلى أن يتحملها مشرفو الصيانة الثلاثة. أود أن أكرر ما قاله gkjohnson أعلاه ، فإن تكلفة الاحتفاظ بالدليلين examples/js و examples/jsm مرتفعة. لا يمكننا القيام بذلك إلى أجل غير مسمى ، ومن الواضح أن وحدات ES6 هي الأكثر حداثة من النهجين. ضع في اعتبارك التكاليف التالية:

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

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

يمكننا إعادة صياغة المشكلة ببساطة: جميع الأمثلة لدينا - التي تعتبر مهمة ولكنها أجزاء اختيارية من مكتبة three.js - لا تستخدم حاليًا أي بنية وحدة على الإطلاق. ليس UMD ولا CommonJS ولا وحدات ES6. إنهم ببساطة يصلحون مساحة الاسم العالمية THREE . نود تحديث ذلك ، باستخدام بناء جملة الاستيراد / التصدير ES6 بدلاً من ذلك ، وكان هناك العديد من التحذيرات المبكرة بأن هذا التغيير قد تم التخطيط له.

هناك نظام بيئي ضخم يعتمد على الوحدات في مجلد الأمثلة المكتوب في ES5 / UMD. لا أعتقد أنه من العدل إسقاط الدعم لنظام بيئي كامل.

لا أعتقد أنه من العدل أن نقول إن أي شيء في النظام البيئي three.js يعتمد بشكل كبير على مساحات أسماء THREE.* العالمية بحيث لا يمكن تحديثه لاستخدام صيغة الاستيراد / التصدير ، أو التحويل إلى ES5 ، أو لاستخدام الحزم. يوجد عدد من الحلول هنا ، ويسعدنا العمل مع المستخدمين للمساعدة في العثور على خيار مناسب لهم.

تكلفة صيانة كل من الأمثلة / شبيبة وأمثلة / جي إس إم الدلائل عالية.

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

إنشاء الأتمتة وصيانتها
تصحيح أخطاء الإصدار عند تعطل الأتمتة

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

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

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

الحفاظ على الوثائق التي تشرح كيفية استخدام كلا سير العمل

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

الإجابة على تقارير الأخطاء وأسئلة الدعم من المستخدمين الذين يحاولون استخدام مهام سير عمل CJS و ES6.

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

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

كيف يمكن تقليل حجم القضايا بشكل عام؟

إذا كان الهدف الحقيقي هو تقليل حجم المشكلات بشكل عام ، فقد تساعد سياسات المشكلات الأكثر صرامة في ذلك. أراكم يا رفاق تقومون بعمل رائع مع هذا بالفعل باستخدام علامات مثل Help (please use the forum) ولكن ربما يجب أن يكون هناك المزيد من هذه الأنواع من الأشياء.

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

أفكار الزوجين:

• في وقت كتابة هذا التقرير ، كان لدى suggestions و enhancements (271) إصدارات مفتوحة. يبدو أن هذه الملصقات تولد الكثير من الضوضاء. ربما فقط أن تكون جاهزًا للعلاقات العامة / تم اجتياز الشيكات كاقتراح فعلي. أغلق كل شيء آخر بواسطة Insta وحدد Discussion (please use the forum) .

• في وقت كتابة هذا التقرير ، كان لدى loaders (61) إصدارًا مفتوحًا. يبدو أيضًا أن هذه التسمية تولد الكثير من الضوضاء. أرى الكثير من المشكلات في هذا التصنيف ذات الصلة بـ suggestions و enhancements أو تقارير خطأ سيئة التكوين. ربما لا تأخذ سوى تقارير الأخطاء المشكَّلة جيدًا والعلاقات العامة الجاهزة / الشيكات التي تم اجتيازها للحصول على اقتراحات. قم بإغلاق كل شيء آخر ووضع علامة عليه وفقًا لذلك.

لا أعتقد أنه من العدل أن نقول إن أي شيء في النظام البيئي three.js يعتمد بشكل كبير على مساحات الأسماء الثلاثة العالمية * التي لا يمكن تحديثها لاستخدام بناء جملة الاستيراد / التصدير ، أو التحويل إلى ES5 ، أو استخدام المجمع.

أوافق على إمكانية تحديث أي شيء ، ولكن إذا تمكنا من إيجاد طريقة للقيام ببعض العمل لمواصلة دعم هؤلاء المستخدمين بطريقة مستدامة ، فأنا أتفق مع @ Bug-Reaper في قوله:

أفضل أننا جميعًا لم ننشئ سير عمل تحويل / حزمة بمفردنا عندما يمكن الاحتفاظ بشيء ما في الريبو الرئيسي للسماح لنا بالتعاون بشكل أفضل.

سنوفر بشكل جماعي لهؤلاء المستخدمين قدرًا هائلاً من الوقت من ترقية تطبيقاتهم / مكتباتهم وإنشاء أنظمة وتوثيق.

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

جيد.

كيف يمكن تقليل حجم القضايا بشكل عام؟

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

أتفق مع @ Bug-Reaper في قوله:

أفضل أننا جميعًا لم ننشئ سير عمل تحويل / حزمة [...]

أعتقد أننا جميعًا نتفق على هذا.

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

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

أوافق على أن وحدات ES6 هي المستقبل ، لكن التطوير معهم بدون خرائط استيراد يمكن أن يتسبب في حدوث صداع كبير ويعطل تدفقك تمامًا. عندما قررنا إهمال examples/js كنت آمل أن تحصل خرائط الاستيراد على مزيد من الجذب ، ولكن يبدو أنها ليست أولوية حاليًا للمتصفحات.

لهذا السبب ، قررت تعليق إيقاف العمل بالمجلد examples/js حتى تنفذ المتصفحات خرائط الاستيراد. أنا أكره إجبار المبتدئين على التعرف على polyfills أو bundlers من أجل تقديم مكعبهم الأول.

لقد توصلت إلى نفس النتيجة مثل @ Bug-Reaper. ألقي اليوم نظرة على إنشاء برنامج نصي ينشئ examples/js من ملفات examples/jsm .

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

قررت تعليق إهمال مجلد الأمثلة / js حتى تنفذ المتصفحات خرائط الاستيراد.
لقد توصلت إلى نفس النتيجة مثل @ Bug-Reaper. ألقي اليوم نظرة على إنشاء برنامج نصي يبني أمثلة / js من أمثلة / ملفات jsm.

قرار حكيم.
👍

mrdoob أنا بالطبع أقبل قرارك ولكن أعتقد أنه فرصة ضائعة. عاجلاً أم آجلاً ، سيتعين على المطورين الابتعاد عن البرامج النصية العالمية. ولا أعتقد أن Import Maps سيحدث فرقًا كبيرًا هنا. بدلاً من "إجبار" المستخدمين على تدفقات عمل أفضل ومستقبلية ، نسمح لهم بمواصلة استخدام البرامج النصية العالمية. في عام 2020.

ولا أعتقد أن Import Maps سيحدث فرقًا كبيرًا هنا.

ذات يوم رأيت أحدهم يفعل هذا:

<script src="js/three.js"></script>
<script src="https://cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/GLTFLoader.js"></script>
<script type="module" src="js/main.js"></script>

وداخل main.js كانوا يفعلون هذا:

import {OrbitControls} from "https://threejsfundamentals.org/threejs/resources/threejs/r119/examples/jsm/controls/OrbitControls.js";

والشيء نجح بالفعل ... 😐

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

تكمن المشكلة مع ES6 Modules بدون استيراد الخرائط في أنه لا يمكن للمستخدم نسخ OrbitControls.js إلى مجلد /js في مشروعه الخاص واستيراده كما اعتادوا. لن يعمل لأن OrbitControls.js يبحث عن ../../build/three.module.js .

باستخدام خرائط الاستيراد ، سيتم استيراد OrbitControls.js من three . يمكن للمستخدم نسخ الملف أينما يريد ثم ضبط المسار في خريطة الاستيراد.

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

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

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

أنا لا أعتبر حقًا مضادًا للنمط.

إنها فقط الطريقة التي تعلمت بها إنشاء مواقع الويب. يمكن للمرء وضع ملفات .css في المجلد /css ، ثم الصور في /img .js في /js .

على مدار الأشهر الماضية ، أجريت بعض التجارب باستخدام منهج ES6 Modules / CDN ولا أشعر بالرضا لأن المكتبات تأتي من مجال مختلف عن مكان مشروعي.

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

هذه هي الطريقة التي اعتدت بها لإعداد مشاريعي:

<script src="js/libs/three.js"></script>
<script src="js/libs/three/OBJLoader.js"></script>
<script src="js/libs/three/OrbitControls.js"></script>
<script>
    console.log( THREE, THREE.OBJLoader, THREE.OrbitControls );
</script>

مع خرائط الاستيراد ، ستبدو كما يلي:

<script type="importmap">
{
  "imports": {
    "three": "js/libs/three.module.js",
    "OBJLoader": "js/libs/three/OBJLoader.js",
    "OrbitControls": "js/libs/three/OrbitControls.js"
  }
}
</script>
<script type="module">
    import * as THREE from 'three';
    import { OBJLoader } from 'OBJLoader';
    import { OrbitControls } from 'OrbitControls';

    console.log( THREE, OBJLoader, OrbitControls );
</script>

ليست جميلة كما كانت من قبل ، ولكنها تعتني بتبعية / طلب الاستيراد من أجلك ولا تتطلب أداة تجميع.

ومع ذلك ، فإنه لا يزال يعمل مع الأشخاص الذين يقومون بالتنمية القائمة على الحزم. في الواقع ، هذا يجعله أفضل بالنسبة لهم لأن الإضافات تستورد الآن من three بدلاً من ../../build/three.module.js .

والشيء نجح بالفعل ... 😐

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

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

لقد توصلت إلى نفس النتيجة مثل @ Bug-Reaper. ألقي اليوم نظرة على إنشاء برنامج نصي يبني أمثلة / js من أمثلة / ملفات jsm.

إذا كانت هذه هي الخطة الجديدة ، فسيسعدني المساعدة في إحياء # 15526 / # 15543 (التي تم حذفها الآن من المشروع) والتي تبني كل ملف وحدة إلى ملف ES6. نظرًا لأن بعض الأمثلة منتشرة بين العديد من الملفات (Shader Nodes ، على سبيل المثال) وقد نكون مهتمين بتقسيم بعض الوحدات إلى ملفات متعددة ، فمن المحتمل أن يكون من المفيد ترقية البرنامج النصي للجمع للحصول على قائمة صريحة بالملفات التي نريد تحويلها والإخراج. يجب أن نكون قادرين على إنشاء التبعيات تلقائيًا بين الملفات التي يتم إخراجها أيضًا.

أحد الأشياء الكبيرة التي نخسرها عند عدم نسخ الملفات هو القدرة على تعديلها

أوافق على الرغم من أنه إذا تمكنا من الوصول إلى الفصول في كل مكان ، أتمنى شيئًا مثل:

import orbitalcontrols from  orbitalcontrolsURL

class mycontrols extends orbitalcontrols {
// do the edits I care about
}

ثم لاحقًا

let controls = new myorbitalcontrols

أحد الأشياء الكبيرة التي نخسرها عند عدم نسخ الملفات هو القدرة على تعديلها

أوافق على الرغم من أنه إذا تمكنا من الوصول إلى الفصول في كل مكان ، أتمنى شيئًا مثل:

استيراد عناصر التحكم المدارية من عناوين URL المدارية

تعمل عناصر التحكم في الطبقة على توسيع عناصر التحكم المدارية {
// إجراء التعديلات التي أهتم بها
}

ثم لاحقًا

اسمحوا الضوابط = ضوابط عضلية جديدة

يمكنك فعل ذلك بالفعل ... حتى لو كانت "class" الأصل عبارة عن وظيفة js بسيطة!

الكود يعمل بالفعل (في اختبار سريع لمصحح الأخطاء):

Promise.all([
    import('https://unpkg.com/three/build/three.module.js')
        .then( mod=> [mod.Camera, mod.WebGLRenderer] ),
    import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')
        .then( mod=> mod.OrbitControls )
])
.then( ([
    [ Camera, WebGLRenderer ],
    OrbitControls
])=> new ( class extends OrbitControls {} )( new Camera, (new WebGLRenderer).domElement )
)
.then( console.log )

... أو بناء جملة أبسط:

(async function() {

let { Camera, WebGLRenderer } = await import('https://unpkg.com/three/build/three.module.js')
,   { OrbitControls } = await import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')

class Con extends OrbitControls { }

let my = new Con( new Camera, (new WebGLRenderer).domElement )
console.log( my )

})()

بصرف النظر عن هذه الوظيفة الشاذة والقلق بشأن عدم التزامن / انتظار الوعود ، رائع

class mycontrols extend orbitalcontrols {
 // do the edits I care about
 }

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

على سبيل المثال ، التغيير الأكثر شيوعًا المطلوب لـ OrbitControls هو تحديد المقلاة . يمكن تحقيق ذلك بسهولة كما هو موضح في كمان @ Mugen87 من هذا الخيط.

باختصار ، أضف متجهات minPan و maxPan وقم بتثبيت controls.target في طريقة controls.update .

لقد حاولت القيام بذلك عن طريق تمديد OrbitControls . يمكنك إنشاء فصل دراسي ممتد ، وهو يعمل بشكل جيد. ومع ذلك ، تظهر المشاكل عند البدء في إجراء التغييرات. لا يمكنك ببساطة تمديد طريقة update :

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);
    }

    update() {
        super.update();
        console.log('Custom update function');
    }
}

تعمل هذه الفئة الموسعة ( خلل ) ، ولكن يتم تجاهل طريقة OrbitControlsPanLimit.update الجديدة هذه. لا تزال الطريقة الأصلية OrbitControls.update مستخدمة.

يمكنك الكتابة فوقه بإعادة تعريفه في المنشئ:

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);

        this.update = () => {
            console.log('Custom update function');
        }
    }
}

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

    //
    // internals
    //

    var scope = this;

    var changeEvent = { type: 'change' };
    var startEvent = { type: 'start' };
    var endEvent = { type: 'end' };

    var STATE = {
        NONE: - 1,
        ROTATE: 0,
        DOLLY: 1,
        PAN: 2,
        TOUCH_ROTATE: 3,
        TOUCH_PAN: 4,
        TOUCH_DOLLY_PAN: 5,
        TOUCH_DOLLY_ROTATE: 6
    };

    var state = STATE.NONE;

    var EPS = 0.000001;

    // current position in spherical coordinates
    var spherical = new THREE.Spherical();
    var sphericalDelta = new THREE.Spherical();

    var scale = 1;
    var panOffset = new THREE.Vector3();
    var zoomChanged = false;

    var rotateStart = new THREE.Vector2();
    var rotateEnd = new THREE.Vector2();
    var rotateDelta = new THREE.Vector2();

    var panStart = new THREE.Vector2();
    var panEnd = new THREE.Vector2();
    var panDelta = new THREE.Vector2();

    var dollyStart = new THREE.Vector2();
    var dollyEnd = new THREE.Vector2();
    var dollyDelta = new THREE.Vector2();

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

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

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

احذر ، هذا يسير عن كثب نحو حجة الميراث مقابل التركيب.

من الناحية المثالية ، لا ينبغي أن تروج المكتبة لأي أنماط. يجب أن تروج لميزاتها وكيف تهدف إلى حل مشاكلك.

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

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

لا يزال بإمكانك تشغيل ألعاب DOS في نظام التشغيل Windows 10.

الميراث مقابل تكوين حجة

من فضلك لا. الحل لهذه "الحجة" هو استخدام أفضل أداة للوظيفة. هناك مكان للإرث ، والتكوين ، والوظيفة ، والاختبار ... سمها ما شئت.

نظرًا لأننا نتحدث عن كيفية قيام المطورين الآخرين (استخدام ، إعادة استخدام ، تعديل) three.js ، فمن الصحيح الترويج لنمط يمكن فهمه واستخدامه بسهولة دون الخروج من ميزات متصفح js.

الترويج لا يعني أنه لا يمكن استخدام أسلوب مختلف.

بأكبر قدر ممكن من التوافق مع الإصدارات السابقة

نعم و لا.

يجب أن تروج لميزاتها وكيف تهدف إلى حل مشاكلك

ربما حتى نكون واضحين ، ما هي المشكلة / الميزة المحددة لك؟

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

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

سيكون الثابت الوحيد إذن هو البرامج التي تقدم دعمًا كبيرًا للعديد من حالات الاستخدام على طول الطريق

التغيير هو الثابت الوحيد. يستخدم المطورون الأداة التي يحبونها وأحيانًا نعطي أشياء أخرى تجربة.

جانبا:

يجب أن تروج لميزاتها وكيف تهدف إلى حل مشاكلك

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

الذي جاء أولا؟ الميزة أم النمط أم المشكلة؟

الذي جاء أولا؟ الدجاجة أم البيضة؟
يقول بعض الناس الديك ...

مناقشة رائعة في كل مكان ، شكرا للجميع على كل المدخلات.

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

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

// jsm-transpiler.js
export default [
  {
    input: './examples/jsm/controls/OrbitControls.js',
    output: {
      banner:"//warning this file was generated automatically",
      file: './examples/js/controls/OrbitControls.js',
      name:'OC',
      footer:'THREE["OrbitControls"]=OC.OrbitControls',
      format: 'umd'
    }
  }
];

هذا البرنامج النصي لتكوين مجموعة التحديثات يقوم بالفعل بتحويل الوحدة النمطية $ # OrbitControls .js غير الوحدة النمطية يتضمن تعيين THREE.OribitControls المُنشئ المناسب. عملت ، وهو أمر رائع :)! قام أيضًا بتجميع 40 كيلو سطرًا من THREE.js في ملف الإخراج ، وليس رائعًا. أنا أيضًا ألوث المساحة المتغيرة العالمية بتكاسل من خلال إعلان متغير عالمي وسيط يسمى OC للمساعدة في نقل مُنشئ OrbitControls إلى THREE.

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

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

هذا هو رأيي في ذلك:
https://github.com/mrdoob/three.js/pull/20529

هذا برنامج نصي مخصص للإنشاء يقوم بتحويل جميع وحدات JSM إلى وحدات JS ذات مساحة أسماء عامة في حوالي 30 ثانية. حققت نجاحًا جيدًا بهذه الطريقة. يحتاج إلى مزيد من الاختبارات ولكن جرب عددًا قليلاً من الوحدات النمطية الأكثر تعقيدًا مثل GLTFLoader في عالم مرحبًا وكان جيدًا.

يمكن استخدام المساعدة من أي معالجات RegExp المتمرسين :) لمناقشة بعض الحالات الجانبية التي يمكنك قراءة المزيد عنها في العلاقات العامة.

نية استيراد خرائط Chrome للشحن:
https://groups.google.com/a/chromium.org/g/blink-dev/c/rVX_dJAJ-eI