Three.js: تقييم فصول ES6

إذن أنت تقترح استخدام هذا النمط بدلاً من ذلك؟

PointLight.prototype = Object.create( Light.prototype );
Object.assign( PointLight.prototype, {

class PointLight extends Light

الكالينجيون 😄 ولا مشاكل ...

@ sasha240100 يوما ما ...

mrdoob ليس تمامًا - الطريقتان اللتان ذكرتهما متكافئتان بشكل مباشر. أعتقد أن البروتوكول الاختياري يقارن

PointLight.prototype = Object.assign( Object.create( Light.prototype ), { 
    constructor: PointLight,
    prop1: 'something',
    method1: function someFunction() { .. },
    ...
});

مع

function PointLight () { ... };

PointLight.prototype = Object.create( Light.prototype );

PointLight.prototype.constructor = PointLight;

PointLight.prototype.prop1 = 'something';

PointLight.prototype.method1 = function someFunction() { .. };

...

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

looeee @ bfred- itmrdoob لماذا لا تستخدم فقط rollup-babel ؟

المقارنة :
تيار. وحدات الانسجام es5 + es6.

import { LineBasicMaterial } from './LineBasicMaterial';
import { Color } from '../math/Color';

function LineDashedMaterial( parameters ) {

    LineBasicMaterial.call( this );

    this.type = 'LineDashedMaterial';

    this.scale = 1;
    this.dashSize = 3;
    this.gapSize = 1;

    this.setValues( parameters );

}

LineDashedMaterial.prototype = Object.create( LineBasicMaterial.prototype );
LineDashedMaterial.prototype.constructor = LineDashedMaterial;

LineDashedMaterial.prototype.isLineDashedMaterial = true;

LineDashedMaterial.prototype.copy = function ( source ) {

    LineBasicMaterial.prototype.copy.call( this, source );

    this.scale = source.scale;
    this.dashSize = source.dashSize;
    this.gapSize = source.gapSize;

    return this;

};


export { LineDashedMaterial };

ES2015 +. نفس الكود ، لكن es2015 + مع babel-plugin-transform-class-properties :

import { LineBasicMaterial } from './LineBasicMaterial';
import { Color } from '../math/Color';

export class LineDashedMaterial extends LineBasicMaterial {
  type = 'LineDashedMaterial';

  scale = 1;
  dashSize = 3;
  gapSize = 1;
  isLineDashedMaterial = true;

  constructor(parameters) {
    super();
    this.setValues( parameters );
  }

  copy(source) {
    super.copy(source);

    this.scale = source.scale;
    this.dashSize = source.dashSize;
    this.gapSize = source.gapSize;

    return this;
  }
}

ميزات ES6 التي من شأنها تبسيط كود three.js:

• قيم المعلمات الافتراضية.
  
  
  
  • يمكن بسهولة استبدال هذه الأجزاء من الكود
  
  
• اختزال الملكية
  
  
  
  • يمكن استخدامها هنا
  
  
• دالة السهم
  
  
  
  • https://github.com/mrdoob/three.js/blob/dev/src/loaders/JSONLoader.js#L36
  
  

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

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

هل نحتاج Object.assign في هذه الحالات؟

@ Mugen87mrdoob بعض المعلومات الشيقة عن أداء es6. خاصة على Object.assign :

من هذا المقال

كيف يمكننا نقل أساليب مثل Vector3.unproject إلى صيغة الفصل؟ تستخدم الطريقة بالفعل إغلاقًا لإنشاء نطاق جديد.

@ Mugen87 ألا يمكن أن يكونوا مجرد كائنات ذات نطاق وحدة نمطية غير مُصدرة؟ شيء من هذا القبيل؛

const tempMatrix = new Matrix();    

export default class Vector3{
    unproject() {
        // uses tempMatrix
    }
}

آه نعم ، أعتقد أن هذا يجب أن يعمل 😊

تم اقتراح هذا الشهر الماضي على تويتر :

https://astexplorer.net/#/gist/9db8b707e3f69f94ded4af737f879fa7/b12fb12806e97df96278ec8b7d52018c8421872f

تضمين التغريدة يبدو أنه يعمل بالفعل. ألا يمكننا إنشاء فرع ، وتحويل بعض الفئات إلى es6 ونرى كيف يتم تجميعها؟

@ satori99 كفكرة عن كيفية الاحتفاظ بـ tempMatrix داخل كود Vector3 لتجنب المشاكل مع globals:

export default class Vector3 {
    static tempMatrix = new Matrix();

    unproject() {
        // uses Vector3.tempMatrix
    }
}

تضمين التغريدة يبدو أنه يعمل بالفعل. ألا يمكننا إنشاء فرع ، وتحويل بعض الفئات إلى es6 ونرى كيف يتم تجميعها؟

تبدو جيدة بالنسبة لي! أنا أركز حاليًا على WebVR ، لذا يجب أن يكون شخصًا آخر غيري.

@ sasha240100 فائدة استخدام متغيرات نطاق الوحدة النمطية هي أنها تظل مخفية عن كود المستخدم العادي ، والذي يبدو مناسبًا للمتغيرات المؤقتة.

لا أمانع في النهج البيثوني "نحن جميعًا بالغون هنا" فيما يتعلق بالمتغيرات الخاصة ، ولكن يجب ألا تلوث المتغيرات المؤقتة مساحة الاسم دون داعٍ.

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

نعتذر عن الدخول. ربما ينبغي علينا تغيير عنوان المشكلة إلى شيء مثل - "تقييم فئات ES6" ، حيث تغير الخيط الآن إلى شيء مختلف تمامًا.

لماذا تغير النمط @ Mugen87 @ satori99 ؟

method =(()=>{ 
    const vec3forThisScope =...; 
    return (arg)=>{...}
})()

لماذا لا تجرب الكتابة المطبوعة ، فيمكن تجميعها في إصدارات أخرى من js

سيكون TypeScript حقًا خيارًا رائعًا للتفكير فيه لأنه مدقق من نوع transpiler ومجموعة شاملة من JavaScript ، لذلك من السهل نقل قاعدة التعليمات البرمجية إلى ملفات .ts وإعادة تشكيلها تدريجيًا إلى ES6 مع فحص النوع.

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

بعض المقالات المفيدة:

• لماذا لا يجب أن تخاف من TypeScript
• TypeScript مقابل ES6 مقابل ES2015
• فاز TypeScript
• ما هو TypeScript ولماذا مع Anders Hejlsberg

على حد تعبير المطور الأساسي Anders Hejlsberg ، وُلدت TypeScript استجابة لشكاوى العملاء والفرق الداخلية من أن JavaScript لا يصلح للتطبيقات الكبيرة.

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

حتى تتمكن المتصفحات من تنفيذ TypeScript محليًا ، أفضل الاستمرار في استخدام JavaScript.

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

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

أعتقد أنك تفتقد تمامًا فكرة استخدام لغة مكتوبة وفوائدها في التطوير في قاعدة رموز كبيرة. ما زلت تكتب وتستخدم JavaScript ، بيت القصيد من TypeScript هو أنها مجموعة شاملة من JavaScript. أنت تكتب JavaScript بأنواع ، يتم تجميعها في JavaScript في الإصدار المستهدف ECMAScript المحدد ، والذي يمكن تكوينه في خيارات المترجم ، والقيم المسموح بها هي "es3" أو "es5" أو "es2015" أو "es2016" أو "es2017" أو " esnext '.

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

راجع روابط ملعب TypeScript أدناه للحصول على أمثلة رائعة:

• مثال جافا سكريبت الكلاسيكي
• مثال على إضافة أنواع
• مثال على إضافة أنواع بها خطأ
• استخدام مثال الطبقات
• مثال على استخدام الفئات ذات الخطأ

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

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

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

لا توجد أنواع تبدو أكثر من حل وسط من اختيار أحد هذه الأنواع.

حفظ Typescript للمشاريع الأكثر تعقيدًا من النتيجة التي تقوم بإنشائها - خاصةً أطر الواجهة الأمامية التي كان من الممكن تنفيذها في HTML في المقام الأول. كانت وجهة نظري الأصلية هي التخلص من مرض JavaScript ، وليس جعله أسوأ. JavaScript هي لغة بسيطة تقريبًا تستخدم أحيانًا لنتائج معقدة مثل three.js. الطباعية لا طائل من ورائها.

في 6 سبتمبر 2017 الساعة 1:55 مساءً ، كتب Joe [email protected] :

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

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

أعتقد أنك تفتقد تمامًا فكرة استخدام لغة مكتوبة وفوائدها في التطوير في قاعدة رموز كبيرة. ما زلت تكتب وتستخدم JavaScript ، بيت القصيد من TypeScript هو أنها مجموعة شاملة من JavaScript. أنت تكتب JavaScript بأنواع ، يتم تجميعها في JavaScript في الإصدار المستهدف ECMAScript المحدد ، والذي يمكن تكوينه في خيارات المترجم ، والقيم المسموح بها هي "es3" أو "es5" أو "es2015" أو "es2016" أو "es2017" أو " esnext '.

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

راجع روابط ملعب TypeScript للحصول على أمثلة:

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

^ سأكون بخير حتى مع النمط الوحشي ، طالما أنه متسق.

joejordanbrown يبدو أنك مغرم بالنص المطبوع. لا تتردد في تفرع المشروع ونقله إلى نسخة مطبوعة. ثلاثة. 🙌

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

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

لقد ذكرت Flow ، المشاكل التي أراها في ذلك هي:

• ترخيص التدفق هو BSD 3-clause " Facebook BSD + Patents License " ، حظرت مؤسسة Apache Software Foundation استخدام هذا الترخيص في المشاريع الجديدة. يمكنك قراءة المزيد من التفاصيل هنا .

• يفتقر دعم IDE مقارنةً بـ TypeScript.

• قاعدة المستخدمين صغيرة مقارنة بـ TypeScript ،

• الكتابات المتاحة للمكتبات العامة غير مكتملة ، يحتوي TypeScript على الكثير من المطبوعات التي يتم صيانتها جيدًا.

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

• يستخدم Flow ملفات .js التي تم وضع علامة عليها باستخدام // @flow ، وقد يكون هذا محيرًا لأنك ترى امتداد .js لذا توقع JavaScript ولكن في الواقع ، إنه FlowType. حيث تستخدم TypeScript امتدادها الخاص .ts . يتيح لك هذا أيضًا الحصول على ملفات إخراج TypeScript و JavaScript بأسماء متطابقة في نفس الدليل ، وهو أمر مثالي لمشروع صغير ، من الواضح أن هذا لن يكون هو الحال في مشروع كبير على الرغم من أنك تستخدم بنية نظام لإدارة عملية البناء.

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

أصبح Typescript متاحًا للتطوير غير المقيد للعملاء اعتبارًا من مارس 2017. يتم استخدام TypeScript و Angular على TypeScript في Google Analytics و Firebase و Google Cloud Platform والأدوات الداخلية الهامة مثل تتبع الأخطاء ومراجعات الموظفين والموافقة على المنتج وأدوات التشغيل.

لقد اعتقدت أنني سأفتح المناقشة حول استخدام لغة مكتوبة وأرى ما يعتقده الآخرون حول الفكرة. يبدو أن mrdoob يعارض تمامًا حتى مناقشة الفكرة.

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

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

عدم لعب دور محامي الشياطين ، ولكن يبدو أنه فعل ذلك

إجراء مناقشة مفتوحة

لقد كانت قصيرة حقًا :)

أشترك في وجهة نظر مماثلة ، إنها مكتبة JS و JS موحدة. لا يمكنك أن تخطئ في اختيار JS لمكتبة JS ، بينما يمكنك ذلك إذا اخترت شيئًا آخر. لقد أخذت للتو Flow كأحد البدائل للطباعة ، dunno إذا كان هناك آخرون.

على أي حال ، يبدو أننا خرجنا عن الموضوع حقًا.

قام Mugen87 بتغيير العنوان من
قم بإزالة مرض JavaScript لتقييم فئات ES6

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

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

سأعالج هذه المشكلة بتحديث هذه الصفحة:

https://github.com/mrdoob/three.js/wiki/Mr.doob 's-Code-Style٪ E2٪ 84٪ A2

وإضافة إما:

أ) "... استخدام تعيين الكائن ..."
ب) "... لا تستخدم Object.assign"

نمط واحد في جميع أنحاء المكتبة. لا حاجة لتغييره.

لا يزال نمط الخطين المخلصين ، على سبيل المثال ، فصول المواد أكثر وضوحًا ونظافة.

انها في أول وظيفة.

أقترح:

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

على أي حال ، يبدو أننا خرجنا عن الموضوع حقًا.

بالفعل. joejordanbrown لا تتردد في إنشاء موضوع جديد لمناقشة TypeScript.

راجع للشغل ، إنها أيضًا ممارسة OSS سيئة لتجاهل المحادثات السابقة ... https://github.com/mrdoob/three.js/issues/341#issuecomment -47000692

العودة إلى الموضوع. اعتقدت أننا بالفعل حل هذه المشكلة؟

https://github.com/mrdoob/three.js/issues/11552#issuecomment -319449068

نحن فقط بحاجة إلى شخص ما ليجربها.

حسنًا ... أولاً وقبل كل شيء

النمط الأول (أفضل IMO):

function MyClass() {...}

MyClass.prototype = Object.assign( Object.create( MyClassToInherit.prototype ), {

    constructor: MyClass,

    prop1: 'something',

    method1: function someFunction() { .. },

    ...

});

النمط الثاني:

function MyClass() {...}

MyClass.prototype = Object.create( MyClassToInherit.prototype );

MyClass.prototype.constructor = PointLight;

MyClass.prototype.prop1 = 'something';

MyClass.prototype.method1 = function someFunction() { .. };

...

arctwelve تم تقديم هذا النمط لعدة أسباب. هذه ليست العادة السرية!

بادئ ذي بدء ، يسمح بقراءة واضحة عن وراثة الكائن. من الواضح هنا أن Object.assign يتعلق بميراث الكائن. ثم لا يمكنك أن تفقد الكائن الموروث في العديد والعديد من السطور MyClass.prototype .
ثانيًا ، في حالة تعدد الميراث ، يكون هذا أكثر وضوحًا أيضًا.
ثالثًا ، منشئ الفصل مقروء ولا يفقد في العديد من السطور مثل النقطة الأولى.
رابعًا ، هذا يسمح بتجميع الخصائص والطرق في نفس الموقع (داخل القوس) وهو الأمر الأكثر وضوحًا عندما يكون لديك فئات 3 ، 4 ، 5 ... إلخ في نفس الملف.
خامسًا ، يسمح هذا النمط بفحص النسخة الصحيحة لبعض الخصائص "الموروثة".

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

على أي حال !

في الوقت الحاضر ، يجب أن ننتقل إلى بناء جملة ES6!

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

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

هل ستنشئ فرع es6؟ أم لوحدنا؟

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

هل انت متاكد من ذلك؟ أتوقع أن يكون Object.Assign أبطأ ، إن وجد. لكن في كلتا الحالتين أشك في أن هذا يكفي للقلق بشأن الأداء.

إطلاقا: https://jsperf.com/inline-prototype-vs-assign-prototype/1

تحت الكروم الإصدار 61.0.3163.100 (بناء رسمي) (64 بت) النموذج الأولي المعين أسرع بحوالي 60٪

مثير للاهتمام. شكرا لإجراء الاختبار.

هذه النتيجة لا تصمد لجميع المتصفحات بالرغم من ذلك. في Firefox ، تكون متماثلة تقريبًا ( Object.Assign ~ 3٪ أسرع) ، بينما في Edge Object.Assign أبطأ بنسبة 33٪.

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

بالنسبة لي ، فإن النمط Object.Assign هو أنظف وأسهل في القراءة ، وهذه هي الحجة الرئيسية لصالحه.

نعم ، هذا عبارة عن بضع ملي ثانية لكل ملف وفقط عندما يتم تحليل الملف في المرة الأولى بواسطة محرك جافا سكريبت ... ولكن بالنسبة لمكتبة كبيرة مثل threejs ، يمكن أن يكون الكسب حوالي 200 ميلي ثانية عند تحميل الصفحة.
لا تنسى حد 3scd للمستخدم الأمامي الذي لا يستطيع الانتظار أكثر!

أحاول إنشاء مشروع Angular باستخدام threejs ويبدو دائمًا أنني أخترق كل جزء من threejs.
بادئ ذي بدء ، يجب أن يكون بناء الجملة es5 مع ثلاثة ثابت موجودًا ، على سبيل المثال ، إذا كنت بحاجة إلى OrbitalControls.
لدينا كتابة threejs ، ولكن سيكون أكثر ملاءمة أن تكون في نفس الحزمة. تحتوي الكتابة على OrbitalControls ، لكن لا يمكننا ببساطة الاستيراد مثل import { OrbitalControls } from 'three; .
Webpack به اهتزاز شجرة ، لذلك في حالة es6 يمكننا تضمين كل ما نحتاجه داخل مشروع واحد وعدم نقلهم إلى مشروع منفصل.
mrdoob فلماذا التنضيد سيء للغاية؟ سيتم تجميعه على أي إصدار مع كتابة على أي حال.
يتم استخدامه أيضًا في العديد من الأطر الأخرى مثل React.

FriOne لست متأكدًا مما إذا كان mrdoob يعتقد حقًا أن Typescript سيئة ولكنني أعتقد أنه ضد مناقشة Typescript في هذه المشكلة / الخيط لأنه ليس موضوع هذا الموضوع. أعتقد أن فصول ES6 لا تعمل ضد أو من أجل تنضيد. إذا قمت بتحويل مصدر الشفرة إلى ES6 ، فسيكون من الأسهل نقل قاعدة الشفرة إلى Typescript لأن تركيبها متشابه جدًا. نعم ، أعتقد أن Typescript يمكن أن تتيح الكثير من الخيارات الجديدة. على سبيل المثال ، يمكن أن يساعد "تحويل" رمز أكثر تحسينًا ، ويساعد المطورين الجدد على تعلم المكتبة بشكل أسرع ، وربما يفتح الأبواب للتجارب في المستقبل ، على سبيل المثال: https://github.com/AssemblyScript/assemblyscript. أعتقد أن هناك الكثير من المزايا مع وصف Typescript @ joejordanbrown للمحترفين بالتفصيل.

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

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

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

مرحبًا ، نحن مجموعة من 5 طلاب من KTH نتطلع إلى المساهمة في مشروع مفتوح المصدر لدورة تدريبية ونود محاولة تحويل جزء من المشروع إلى بناء جملة ES6 الجديد.

لقد قمت بنقل Three.js إلى TypeScript مرة أخرى (r82) جنبًا إلى جنب مع بعض الأمثلة ، كدليل على المفهوم.

https://github.com/flyover/three.ts

يستغرق تحميل الأمثلة قليلاً ، حيث يتم نقل مصدر TypeScript سريعًا. يتم تحميلها بنفس سرعة النسخ الأصلية عند استخدام JavaScript المترجمة.

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

اكتمل هذا WestLangley و mrdoob

bhouston ما هو الاستنتاج هنا؟

pkieltyka نعم أعتقد أيضًا أن TypeScript سيكون له معنى كبير لمكتبة مثل Three.js. إلى جانب جميع المزايا التقنية ، فإنه سيسهل أيضًا استخدام المكتبة ويساعد المبتدئين على استكشاف واجهة برمجة التطبيقات. لكنني أعتقد أيضًا أنه من المهم إنهاء كل ES6 Stuff أولاً ثم التفكير في TypeScript. أعتقد أنه من أحدث إصدار من JavaScript ، ليس من المعقد جدًا إضافة أنواع في شكل TypeScript.

لطيف flyover انظر أيضًا إثبات المفهوم لإصدار TypeScript من Three.js. هل تلقيت تعليقات من المشرفين على Three.js؟

أنا أدعم أيضًا الكتابة المطبوعة لـ three.js. typecirpt هو الأفضل أساسًا
الممارسة وجافا سكريبت الخام لم يعد كذلك.

في يوم السبت ، 5 يناير 2019 ، 4:13 صباحًا كتب tschoartschi < [email protected] :

pkieltyka https://github.com/pkieltyka نعم أعتقد أيضًا أن TypeScript
سيكون له معنى كبير لمكتبة مثل Three.js. بجانب كل
الإيجابيات الفنية من شأنه أيضًا أن يسهل استخدام المكتبة ويساعد المبتدئين
لاستكشاف API. لكني أعتقد أيضًا أنه من المهم إنهاء كل ES6
اشياء أولاً ثم ضع في اعتبارك TypeScript. أعتقد من الأحدث
JavaScript ليس معقدًا جدًا إضافة أنواع في شكل TypeScript.

flyover https://github.com/flyover من الجيد أيضًا رؤية إثبات لمفهوم
نسخة تيب سكريبت من Three.js. هل تلقيت ملاحظات من المشرفين
من Three.js؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451639995 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAj6_bkdND7I0_F4AJcBV0DYLpToUIVhks5vAGykgaJpZM4N9vH8
.

bhouston أوافق على أن TypeScript هي تقنية رائعة لكنني لن أصفها بالطريقة التي فعلتها. أعتقد أنه يجب علينا دائمًا البقاء على مقربة قدر الإمكان من JavaScript الخام وإضافة ميزات TypeScript في الأعلى. نظرًا لأن TypeScript يتبع مواصفات JavaScript عن كثب ، فإن TypeScript يقرأ بالفعل مثل ES6 مع الأنواع.

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

سيكون من المثير للاهتمام معرفة ما إذا كان موقفmrdoob من TypeScript قد تغير. يبدو أن TypeScript أصبح المعيار "الفعلي" لـ "JavaScript مكتوب" (لاحظ أنني وضعت ادعاءاتي تحت الفاصلة العليا لأن هذه ليست حقائق ثابتة)

يجب أن تكون الخطوة الأولى هي اعتماد ميزات ES6 ، خاصة الفئات ووظيفة السهم و "let" و "const".

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

يبدو أن القيام بالأمرين معًا في وقت واحد سيؤدي إلى تعقيد الأمور ، بالنسبة لي.

من الرائع أن نسمع أن TypeScript يمكن أن يكون خيارًا في وقت ما في المستقبل :-) ، ربما يمكننا إعادة استخدام بعض الأعمال التي قام بها flyover

لكنني أتفق تمامًا مع looeee لإنهاء جميع عناصر ES6 أولاً ثم التركيز على الخطوات التالية

إنهاء جميع الأشياء ES6

سأكون سعيدًا إذا تمكنا على الأقل من البدء

خطوة نصف جيدة إلى TypeScript woudl تتمثل في إضافة ملفات الكتابة بجانب كل ملف JavaScript. وبالتالي سيكون هناك كلاهما:

Vector3.js
Vector3.d.ts

هذا يعطينا جميع مزايا TypeScript كملفات جانبية.

يوجد حاليًا ملف @ types / three ولكنه قديم ويتم الاحتفاظ به بشكل منفصل - وبالتالي سيكون دائمًا خارج البيانات.

المنافس الرئيسي لـ Three.JS هو Babylong وهو مطبوع بالكامل وأعتقد أنه يستفيد من ذلك.

لكن قتل @ type / three ودمجها كملفات تعريف نوع السيارات الجانبية في ثلاثة ملفات مناسبة ستكون خطوة أولى رائعة.

نحتاج أيضًا إلى دمج جميع الأمثلة في / src مع نوع من اهتزاز الشجرة.

هيكل الكود الخاص بـ Three.JS في الوقت الحالي هو 2014 وهو مجرد ألم للعمل معه.

كل الأمثلة؟

أمثلة / شبيبة

في يوم الإثنين ، 7 يناير 2019 ، الساعة 10:25 صباحًا ، كتب دوسان بوسنجاك < [email protected] :

كل الأمثلة؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/mrdoob/three.js/issues/11552#issuecomment-451970482 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAj6_Q3Kakb5Qn2DqGbMVvLkW_28cOyaks5vA2b5gaJpZM4N9vH8
.

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

خطوة نصف جيدة إلى TypeScript woudl تتمثل في إضافة ملفات الكتابة بجانب كل ملف JavaScript. وبالتالي سيكون هناك كلاهما:

Vector3.js
Vector3.d.ts

هل تعمل ملفات .d.ts كملفات .h في c؟

هل تعمل ملفات .d.ts كملفات .h في c؟

هذا تشبيه جيد جدا. لقد قام شخص مثير للاهتمام بمعظم هذا بالفعل هنا: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/three وبالتالي فإنه في الحقيقة سيكون مجرد امتلاك هذه الأنواع من الملفات ودمجها في Three.js. إذا كنت تريد يمكننا إنشاء علاقات عامة تدمج هذا في Three.js وتقسيمها بشكل صحيح.

لإظهار مدى شعبية Typescript ، انظر إلى عدد @ Types / three التي يتم تنزيلها في الأسبوع:

https://www.npmjs.com/package/@types/three - 63000 تنزيل أسبوعيًا.

محرج!

إذا كنت تريد يمكننا إنشاء علاقات عامة تدمج هذا في Three.js وتقسيمها بشكل صحيح.

يبدو جيدا بالنسبة لي 👍

هل من الممكن تشغيل فحص سطر أوامر ، مشابه لـ eslint ، للتأكد من محاذاة ملفات النوع والملفات المصدر .js ؟ إذا كنا نمتلك ملفات d.ts ، فسيكون من الأفضل بشدة أن يكون لديك طريقة للتحقق بانتظام من تطابقها.

لإظهار مدى شعبية Typescript ، انظر إلى عدد @ Types / three التي يتم تنزيلها في الأسبوع:

https://www.npmjs.com/package/@types/three - 63000 تنزيل أسبوعيًا.

أود أن أعزو هذا أكثر إلى شعبية Visual Studio Code ، لأنه يحدث تلقائيًا عند استخدام Visual Studio Code ، عبر ميزة اكتساب النوع التلقائي.
ومع ذلك ، لا يمكن تجاهله.

flyover @ bunnybones1mrdooblooeeedonmccurdybhouston @ roomle - buildpkieltykaFriOne @ joejordanbrown حيث يبدو أنكم جميعًا مهتمون بـ TypeScript. أعتقد أنه من المنطقي نقل جميع مناقشات TS هناك. إذا كنت مهتمًا يمكنك العثور عليه هنا: https://github.com/mrdoob/three.js/issues/15545

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

الخطوة الأولى هي تحويل بعض الوظائف الإضافية إلى ES6.

https://github.com/mrdoob/three.js/tree/dev/examples/jsm

الضوابط واللوادر والمصدرون هم مرشحون جيدون. لا تتردد في المساعدة!

mrdoob فقط للتأكيد ، تقصد تحويلها إلى وحدات ES ولكن لا تستخدم ميزات ES6 الأخرى حتى الآن ، أليس كذلك؟

أفترض أن عملية إجراء هذا التحويل هي:

1. استخدم البرنامج النصي modularize.js لتحويل الملف الأصلي إلى وحدة ES.
2. تنظيف المشاكل إذا لزم الأمر.
3. في مرحلة ما (هذا الإصدار ، أو في المستقبل القريب) سنبدأ في استخدام rollup-examples.config.js لتحويل وحدات ES إلى وحدات UMD ، وعند هذه النقطة لن يتم الاحتفاظ بالإصدار الموجود في examples/js بواسطة كف.
4. بمجرد استقرار ذلك ، يمكننا النظر في تغييرات أخرى مثل إدخال ميزات ES6.

mrdoob فقط للتأكيد ، تقصد تحويلها إلى وحدات ES ولكن لا تستخدم ميزات ES6 الأخرى حتى الآن ، أليس كذلك؟

نعم انا اسف. كان يجب أن أحدد.

لقد أنشأنا أنا و bhouston العلاقات العامة الموعودة التي تساهم في ملفات * .d.ts لمعظم مشروع Three.JS. https://github.com/mrdoob/three.js/pull/15597

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

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

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

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

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

أردت فقط تنفيذ خريطة ظل محددة لسيناريو محدد. كان من المفيد أن تكون قادرًا على تجاوز getDepthMaterial على سبيل المثال. في الوقت الحالي ، أقوم بحقن WebGLShadowMap الخاص بي في عملية الإنشاء بإصدار نسخ / لصق بما في ذلك التغييرات المطلوبة.
سيكون من الرائع أن تعرض كل فئة three.js أكبر قدر ممكن. باستخدام الكتابة المطبوعة ، يمكنك بسهولة وضع علامة على الوظائف مثل private أو protected لوصف الغرض المقصود. يبدو صفحتي من فئة ES6 / ShadowMap على سبيل المثال كما يلي:

interface MaterialCache {
  [uuid: string]: {[uuid: string]: MeshDepthMaterial}
}

class ShadowMap {
  public enabled: boolean = false
  public autoUpdate: boolean = true
  public needsUpdate: boolean = false
  public type: ShadowMapType

  …

  protected depthMaterials: MeshDepthMaterial[]
  protected materialCache: MaterialCache

  constructor (renderer: WebGLRenderer, objects: WebGLObjects, maxTextureSize: any) {
    …
  }

  protected getDepthMaterial (object: Object3D, material: Material) {
    …
  }
}

export { ShadowMap as WebGLShadowMap }

يبدو الأمر وكأنك في المنزل إذا سُمح لك بتعديل فصول "المستوى المنخفض"

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

هل نحتاج Object.assign في هذه الحالات؟
امين

يمكنك القيام بإغلاق الفصول الآن. ليس من الواضح كيف تتنقل في هذا السكر النحوي. شاهد إجابتي على StackOverflow: https://stackoverflow.com/questions/39297258/iife-in-es6-class-literal/56077521#56077521 (يجب أن أكون متواضعًا وأعترف أنني لا أفهم تمامًا كيف / لماذا يعمل .)

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

@ Mugen87 نعم أعتقد أيضا أننا يجب أن نحسن استخدام نطاق الوحدة. قد يساعد هذا أيضًا في أشياء مثل اهتزاز الأشجار. تمت مناقشة هذا بالفعل في العديد من القضايا الأخرى مثل هذا: https://github.com/mrdoob/three.js/issues/6241#issuecomment -398703521

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

لا مشكلة. لقد ذكرت للتو الاحتمال. إذا كان لديك حل أفضل / أنظف قيد التنفيذ ، فأنا حريص على رؤيته قيد التنفيذ. كان مشروع Three.js (الاستخدام والمصدر والمناقشات وما إلى ذلك) هو المصدر الرئيسي لمعرفي JS ، لذا من المحتمل أن يفيدني تقديم أنماط برمجة جديدة وأفضل إلى Three.js ومشاريعي أيضًا. لا شيء يؤسف له. ؛-)

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

هل يمكنك أن تشرح قليلاً لماذا تعتبر IIFEs صنفًا مضادًا

لن أستخدم أسلوبًا يحتمل أن يعيق اهتزاز الأشجار كما هو مذكور هنا: https://github.com/mrdoob/three.js/pull/14695. إلى جانب ذلك ، أعتقد أن النمط بأكمله يشبه الاختراق. عادةً ما يؤدي استخدام أساليب "خيالية" بشكل أفضل. يجب أن يؤدي تجنب عمليات الإغلاق غير الضرورية أيضًا إلى تحسين أداء تنفيذ التعليمات البرمجية بشكل عام (لا يمكن إثبات ذلك بمرجع ولكني سمعته في حديث منذ بعض الوقت).

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

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

لا بأس في إزالة IIFEs. أعتقد أنني مسؤول عن ذلك في عام 2013. كان الهدف هو التخلص من نمط متغير ثابت كان من الصعب الحفاظ عليه. تم القيام به في هذا العلاقات العامة:

https://github.com/mrdoob/three.js/pull/2941

https://github.com/mrdoob/three.js/issues/2936

وناقشت حتى في وقت سابق هنا:

https://github.com/mrdoob/three.js/pull/2920#issuecomment -12217793

حقيقة مثيرة للاهتمام ، عندما وضعناها ، لم يكن هناك اختلاف في أداء الكود.

أفترض أن عملية إجراء هذا التحويل هي:

1. استخدم البرنامج النصي modularize.js لتحويل الملف الأصلي إلى وحدة ES.
2. تنظيف القضايا إذا لزم الأمر.
3. في مرحلة ما (هذا الإصدار ، أو في المستقبل القريب) سنبدأ في استخدام rollup-examples.config.js لتحويل وحدات ES إلى وحدات UMD ، وعند هذه النقطة لن يتم الاحتفاظ بالإصدار الموجود في examples/js بواسطة كف.
4. بمجرد استقرار ذلك ، يمكننا النظر في تغييرات أخرى مثل إدخال ميزات ES6.

مهلا. ربما فاتناها ولكن ما كانت هذه خطواتنا التدريجية نحو الفصول الدراسية؟

1. [x] استخدم البرنامج النصي modularize.js لتحويل الملف الأصلي إلى وحدة ES.
2. [x] تنظيف المشاكل إذا لزم الأمر.
3. [] في مرحلة ما (هذا الإصدار ، أو في المستقبل القريب) سنبدأ في استخدام تجميع أمثلة.config.js لتحويل وحدات ES إلى وحدات UMD ، وعند هذه النقطة لن يتم الاحتفاظ بالإصدار في الأمثلة / js بواسطة كف.
4. [] بمجرد استقرار ذلك ، يمكننا التفكير في تغييرات أخرى مثل إدخال ميزات ES6.

في الخطوات أعلاه ، انتهينا أساسًا من الخطوتين (1) و (2).

الخطوة (3) لم نعد نقوم بهذه الطريقة ، ولكن بدلاً من ذلك سنقوم بإهمال وإزالة المجلد examples/js في مرحلة ما (انظر https://github.com/mrdoob/three.js/pull/18749) .

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

^ لكن ربما أقرأ كثيرًا بين السطور هنا ، ربما @ Mugen87 أو mrdoob يمكنه التأكيد؟

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

في احسن الاحوال. شكرا لكم. سوف نلقي نظرة فاحصة على تلك الطرق

مُعاد نشره من إصدار مغلق.
أهلا،

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

تلخيصي السريع لما صادفته حتى الآن:

• يجب علينا إهمال مجلد الأمثلة قبل القيام بأي شيء آخر
• هناك أجزاء من src / التي لم يتم تمديدها بأي من الأمثلة التي يمكن تحويلها
• مع بعض التغييرات على البرنامج النصي modularize.js ، يمكننا البدء في الأمثلة / js / الذي يولد الأمثلة المقابلة / البرامج النصية jsm.

هل فاتني شيء؟

يجب علينا إهمال مجلد الأمثلة قبل القيام بأي شيء آخر

لست متأكدًا من المسؤول عن أي خطوة تالية محددة في المجلد examples/js . ما لم نتمكن من توضيح هذه الخطة ، كنت أفضل ألا يمنع هذا تحويل الأشياء إلى فصول ES. لهذا السبب ، لا أوافق إلى حد ما مع https://github.com/mrdoob/three.js/issues/11552#issuecomment -592768708. 🙂

علاوة على ذلك ، يبدو أننا فقط ننتظر موعدًا يتم تحديده

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

تحرير: إليك خلاصة مثال سريع آخر

لنبدأ تدريب التحويل .
تعليق تبعيات الملف .

تضمين التغريدة هل يمكنني أخذ بعض العناصر الموجودة في قائمة dependencies.json ؟

👍

دعنا نسمي dibs على الأشياء

DefinitelyMaybe ما هي أفضل طريقة للتعامل مع الميراث من سلف عميق مثل Object3D ؟ على سبيل المثال ، واجهت كسر تحويل src/audio/AudioListener.js :

[ROLLUP] bundles src/Three.js → build/three.js...
[ROLLUP] (!) Error when using sourcemap for reporting an error: Can't resolve original location of error.
[ROLLUP] src/audio/AudioListener.js: (137:1)
[ROLLUP] [!] Error: 'return' outside of function
[ROLLUP] src/audio/AudioListener.js (137:1)
[ROLLUP] 135:   };
[ROLLUP] 136: 
[ROLLUP] 137:   return AudioListener;
[ROLLUP]        ^
[ROLLUP] 138: }(Object3D));
[ROLLUP] Error: 'return' outside of function

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

لقد أسأت فهم ما كان يحدث مع AudioListener ... بعد بعض التصحيح ، أعتقد أن هناك مشكلة مطابقة في التحويل bubleCleanup . راجع https://github.com/mrdoob/three.js/pull/19934#issuecomment -667411997 لمزيد من المعلومات. لقد واجهت هذا مع عدد قليل من الفصول المختلفة ، لذلك ربما يتعين علينا فرزها قبل المضي قدمًا.

سيكون هذا هو الحال بالنسبة لبعض الملفات ولكن ليس كلها. كنا نتوقع مثل هذه القضية.

لأولئك الذين يتابعونك على طول ، يرجى قراءة سريعة للمناقشة هنا .

في هذه الأثناء ، ديبس على src/loaders !