Three.js: तीन.जेएस के लिए Google क्लोजर कंपाइलर "बाहरी" फ़ाइल?

नहीं, तीन.जेएस की कोई बाहरी निर्भरता नहीं है, इसलिए अब तक कुछ इस तरह की जरूरत नहीं थी।

मुझे पता है, लेकिन यह स्वयं की परियोजनाओं के लिए एक संकलित वातावरण में तीन.जेएस को एकीकृत करने के लिए भी उपयोगी है।

ऐसी फाइल कैसी दिखेगी? क्षमा करें यदि यह आपके द्वारा साझा किए गए लिंक पर पहले से ही समझाया गया है, तो मुझे पृष्ठ थोड़ा भारी (बहुत अधिक टेक्स्ट) मिला और मैं पढ़ने/समझने में असमर्थ हूं।

@mrdoob , आपको उनके कुछ उदाहरण यहां मिलते हैं:

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fexterns

या

http://code.google.com/p/closure-compiler/source/browse/#svn %2Ftrunk%2Fcontrib%2Fexterns

और निम्नलिखित भी महत्वपूर्ण है:

http://code.google.com/closure/compiler/docs/js-for-compiler.html

टिप्पणियाँ/शीर्षक? मुझे लगता है कि इससे कोड को पढ़ना मुश्किल हो जाएगा ...

हाँ, लेकिन मुझे लगता है कि यह केवल इस बाहरी फ़ाइल के लिए पूरे कोड के लिए नहीं है। कोई इसे कर सकता है, लेकिन यह जरूरी नहीं है।

मैंने इसे http://www.dotnetwise.com/Code/Externs/index.html के साथ आजमाया है। लेकिन यह पूरी तरह से Three.js के साथ काम नहीं करता है। सभी परिभाषाएँ निकाली नहीं जाती हैं।

यहाँ ब्लॉग प्रविष्टि है:

http://blog.dotnetwise.com/2009/11/closure-compiler-externs-extractor.html

ऐसा लगता है कि यह this.method = function(){} पैटर्न का समर्थन करता है, लेकिन प्रोटोटाइप का नहीं ...

@mrdoob , क्लोजर-कंपाइलर एडवांस्ड ऑप्टिमाइज़र के साथ अपने स्वयं के एप्लिकेशन में THREE.js को एकीकृत करने की आपकी क्या सिफारिश है? क्या यह सच है कि वर्तमान में यह संभव नहीं है?

जहां तक ​​​​मैं समझता हूं कि उन्नत अनुकूलक में केवल उपयोग की जा रही कक्षाएं शामिल हैं, है ना? सिद्धांत रूप में यह काम करना चाहिए... क्या यह काम नहीं कर रहा है?

मैंने तीन.जेएस के साथ उन्नत अनुकूलन की कोशिश नहीं की, लेकिन मुझे याद है कि अन्य चीजों के लिए यह कोड को तोड़ता था। सामान्य तौर पर यह "सुरक्षित" नहीं था - डिफ़ॉल्ट सरल अनुकूलन के साथ यह हमेशा काम करता है, उन्नत के साथ कभी-कभी ऐसा नहीं होता है।

यदि आप संकलित करते हैं तो यह कोड को तोड़ता है, लेकिन एक एप्लिकेशन के रूप में (विधियों को बुलाया जा रहा है और वह सब) इसे काम करना चाहिए, है ना?

@mrdoob संकलित (अनुकूलित) कोड वाले पुस्तकालय का उपयोग करने के लिए आपको पुस्तकालय के सभी वर्गों और विधियों को घोषित करने के लिए "बाहरी" -फाइल की आवश्यकता है। इसके बिना काम नहीं चलता। लेकिन क्या कोई अन्य उपकरण है जो तीन.जेएस के साथ काम करता है? मुझे अपने तीन.जेएस-आवेदन को खराब करने (बदसूरत) करने की आवश्यकता है। एक उम्मीदवार है: https://github.com/mishoo/UglifyJS । लेकिन मैंने इसकी कोशिश नहीं की है।

Google क्लोजर एक्सटर्न एक फाइल है, जो संपूर्ण वस्तुओं का वर्णन करती है, जिसका उपयोग हम अपने संकलित कोड में करेंगे।
इस फ़ाइल के बिना कंपाइलर केवल फ़ंक्शन नामों से a() या b() जैसा कुछ बनाता है।

उदाहरण के लिए, यह JQuery के लिए है: http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.7.js

यह बहुत अच्छा होगा यदि बाहरी तीन.जेएस के लिए हो।

मैं इसके साथ अच्छा हूं, लेकिन मैं इससे खुद नहीं निपट सकता। किसी और को इस पर कदम बढ़ाना होगा।

@yurikor , जब आप node.js का उपयोग करते हैं, तो आप node-browserify और uglify-js का एक साथ उपयोग कर सकते हैं। फिर आपको कुछ भी बनाने की जरूरत नहीं है।

@remoe सलाह के लिए बहुत बहुत धन्यवाद। मैं इसे आजमाऊंगा।

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

मेरी परियोजना के लिए, मैंने अपनी परियोजना को संकलित करने में सक्षम होने के लिए पर्याप्त तीनj निर्यात के साथ एक साधारण फ़ाइल बनाई uglifyjs का उपयोग करता

साथ ही, क्लोजर कंपाइलर को मेरे सार्वजनिक इंटरफ़ेस प्रतीकों का नाम बदलने से रोकने के लिए, मुझे कोड की कई पंक्तियां जोड़नी blah.xyz माध्यम से एक्सेस की गई सभी संपत्तियों का नाम बदल देता है, लेकिन blah["xyz"] माध्यम से एक्सेस की गई किसी भी संपत्ति को स्पर्श नहीं करता है।

अंत में, क्लोजर कंपाइलर को यह बताने के लिए लाइन window['ColladaLoader2'] = ColladaLoader2 (फिर से एक स्ट्रिंग के उपयोग पर ध्यान दें) की आवश्यकता थी कि इस वर्ग को वैश्विक दायरे में निर्यात किया जाना चाहिए।

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

मेरे फोन से भेजा गया, मेरे व्याकरण और संक्षिप्तता के लिए खेद है।
12 फरवरी 2013 को सुबह 5:19 बजे, "रॉबर्ट कार्नेकी" नोटिफिकेशन @github.com ने लिखा:

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

मेरी परियोजना के लिए, मैंने एक साधारण फ़ाइल बनाई है
टाइप एनोटेशन के साथ जो काफी उपयोगी था क्योंकि इसने क्लोजर को सक्षम किया था
सभी प्रकार की जांच करने और मेरे कोड में कुछ बग खोजने के लिए कंपाइलर। मेरे पास है
इस फ़ाइल को मैन्युअल रूप से बनाया है। मैं मुख्य रूप से बग के लिए क्लोजर कंपाइलर का उपयोग करता हूं
जाँच, वास्तविक खनन के लिए मैं कम शक्तिशाली लेकिन सुरक्षित का उपयोग करता हूँ
uglifyjs https://github.com/mishoo/UglifyJS।

साथ ही, क्लोजर कंपाइलर को मेरे सार्वजनिक इंटरफ़ेस का नाम बदलने से रोकने के लिए
प्रतीकों, मुझे कोड की कई पंक्तियाँ जोड़नी थींhttps://github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3376 (वे चार कार्य मेरी लाइब्रेरी के एकमात्र सार्वजनिक कार्य हैं)। ध्यान दें
कि क्लोजर कंपाइलर blah.xyz के माध्यम से एक्सेस की गई सभी संपत्तियों का नाम बदल देता है,
लेकिन blah ["xyz"] के माध्यम से एक्सेस की गई किसी भी संपत्ति को स्पर्श नहीं करता है।

अंत में, लाइनhttps://github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3383 window['ColladaLoader2']
= ColladaLoader2 (फिर से एक स्ट्रिंग के उपयोग पर ध्यान दें) को बताने के लिए आवश्यक था
क्लोजर कंपाइलर कि इस वर्ग को वैश्विक दायरे में निर्यात किया जाना चाहिए।

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHubhttps: //github.com/mrdoob/three.js/issues/341#issuecomment -13426131 पर देखें।

जहां तक ​​​​मुझे पता है, सरल मोड कोई सत्यापन नहीं करता है। यह स्थानीय चर का नाम बदल देता है, और यदि यह किसी अज्ञात प्रतीक का सामना करता है, तो यह इसे अछूता छोड़ देता है, यह मानते हुए कि यह एक वैश्विक चर है।

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

एक उदाहरण के रूप में, सरल मोड निम्नलिखित कोड को बदल देता है

function fn() {
    var foo = {}; // local variable, safe to rename this
    foo.bar();    // undefined property, will crash here
}
fn();

बिना किसी चेतावनी के

function fn(){({}).bar()}fn();

जो स्पष्ट रूप से ({}).bar() पर दुर्घटनाग्रस्त हो जाएगा। उन्नत मोड निम्न कोड को आउटपुट करता है

({}).a(); // fn() inlined, private member 'bar' renamed to 'a'

जो अभी भी क्रैश हो जाता है, लेकिन कंपाइलर एक चेतावनी भी देता है

Property bar never defined on foo at line 3 character 0.

• बग क्लोजर पाए गए बग्स के प्रकार थे जहां मेरे पास फ़ंक्शन नाम में एक टाइपो था या जहां मैंने x, y, और z घटकों के लिए तीन अलग-अलग संख्याओं के बजाय THREE.Vector3 से Matrix4.makeTranslation किया था .
• अगर मेरे पास पूर्ण परीक्षण कवरेज होता (जो मैं नहीं करता), तो मुझे वे बग जल्दी या बाद में मिल जाते। कभी-कभी उन्हें डीबग करना मुश्किल होता है, हालांकि, अगर वे तुरंत प्रकट नहीं होते हैं।
• यदि थ्रीजेज़ ने प्रत्येक नई रिलीज़ (बनाए रखने के लिए भारी प्रयास) के साथ एक अप-टू-डेट निर्यात फ़ाइल की आपूर्ति की, तो क्लोजर कंपाइलर एक बदलते एपीआई से आने वाली सभी समस्याओं को पकड़ लेगा (जैसा कि Matrix4.makeTranslation के मामले में था)।
• क्लोजर कंपाइलर सेट करना मेरे लिए बहुत काम का है, क्योंकि इसे जावा रनटाइम की जरूरत है। मेरी लाइब्रेरी बनाने के लिए आवश्यक अन्य सभी उपकरण नोड/जावास्क्रिप्ट पर आधारित हैं।

क्लोजर लाइब्रेरी के साथ तीन.जेएस एप्लिकेशन को एकीकृत करने के लिए मैं वर्तमान में अपनी क्लोजर लाइब्रेरी externs.js फाइल बना रहा हूं। मूल रूप से हम जो पता लगाने की कोशिश कर रहे हैं वह है:
क्या सभी तीन.जेएस वर्गों और उनके द्वारा लागू की जाने वाली प्रोटोटाइप विधियों में से कहीं एक सूची है? सूची कुछ इस तरह होनी चाहिए:

तीन।बनावट
तीन। बनावट। निर्माणकर्ता
तीन। बनावट। क्लोन
तीन।बनावट।निपटान
तीन।डेटाटेक्चर।क्लोन

(और इसी तरह...)

Ps- Three.js बहुत अच्छा है, लेकिन उचित jsDocs के साथ, इस सूची को आसानी से निकाला जा सकता है :)

मेरे पास यहां तीन.जेएस निर्यात का आंशिक कार्यान्वयन

@crobi : आपने इसमें डॉक्टर टिप्पणियां क्यों

@taoeffect : टिप्पणियां ज्यादातर क्लोजर कंपाइलर उन्नत मोड के लिए हैं। मुझे दृढ़ता से टाइप किया गया कोड पसंद है।

@crobi , ओह टिप्पणियों का परिणाम लागू टाइपिंग में होता है? यह थोड़े अच्छा है, मुझे नहीं पता था कि उसने ऐसा किया है।

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

यहां क्लोजर के उन्नत अनुकूलन मोड के बारे में अधिकांश टिप्पणियां गलत हैं।

मुख्य मुद्दे को हल करने के लिए, आप किसी भी पुस्तकालय के लिए स्वचालित रूप से क्लोजर एक्सटर्न उत्पन्न करने के लिए निम्न टूल का उपयोग कर सकते हैं http://www.dotnetwise.com/Code/Externs/

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

--language_in=ECMASCRIPT5

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

सोम, जनवरी 13, 2014 अपराह्न 12:31 बजे, रोड्रिगो फॉर्मिगोन <
सूचनाएं@github.com> ने लिखा:

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

--भाषा_इन=ईसीएमएएससीआरआईपीटी5

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHub पर देखेंhttps://github.com/mrdoob/three.js/issues/341#issuecomment -32191167
.

सादर,
बेन ह्यूस्टन
आवाज: 613-762-4113 स्काइप: ben.exocortex ट्विटर: @exocortexcom
http://Clara.io - व्यावसायिक-ग्रेड WebGL-आधारित 3D सामग्री निर्माण

मुझे लगता है कि मैं ऐसी पोस्ट लिख सकता हूं। केवल स्पष्ट करने के लिए, हालांकि, कोई कारण थ्री.जेएस को बंद करके (बाहरी फ़ाइल के साथ या उसके बिना) चलाना चाहेगा, यह केवल प्रदर्शन अनुकूलन के लिए आवश्यक नहीं है। क्लोजर का उद्देश्य मुख्य रूप से जावास्क्रिप्ट (विशेष रूप से, बहुत बड़े कोड बेस) में बनाए रखने योग्य कोड लिखने में आपकी सहायता करना है। लक्ष्य डेवलपर्स को "वश में" जावास्क्रिप्ट (देशी जेएस लिखना) में मदद करना है, न कि इसे "बचाना" (जीडब्ल्यूटी या अन्य समान टूल का उपयोग करके)। यदि आप क्लोजर प्रोजेक्ट के हिस्से के रूप में थ्री.जेएस को संकलित करने का प्रयास करते हैं, तो कंपाइलर आप पर चिल्ला सकता है क्योंकि थ्री.जेएस इसके कुछ मानकों के अनुरूप नहीं हो सकता है (जेएसडीओसी पर्याप्त नहीं है, हो सकता है?)। --भाषा_इन कंपाइलर फ़्लैग का उपयोग करने से वह हल हो जाता है, हालाँकि आपको कुछ चेतावनियाँ मिलेंगी। यदि आप केवल अपना स्वयं का JS कोड संकलित करना चाहते हैं, लेकिन 3.js को एक बाहरी पुस्तकालय के रूप में संदर्भित करना चाहते हैं (इस प्रकार Three.js के सभी कोडबेस को अछूता और अडॉप्टिमाइज्ड छोड़ते हुए), तो आपको ऊपर उल्लिखित बाहरी फ़ाइल की आवश्यकता होगी। बाहरी फ़ाइल के बिना, क्लोजर संकलन त्रुटियों को यह कहते हुए फेंक देगा कि तीन। * कहीं भी घोषित नहीं किया गया है, आदि।

हालांकि मुझे अपने ब्लॉग पोस्ट को यह बताते हुए लिखने की सुविधा नहीं है कि कोई क्लोजर प्रोजेक्ट पर थ्री.जेएस का उपयोग कैसे और क्यों करना चाहता है, यहां मैंने देखा है कि Google क्लोजर टूल्स पर सबसे अच्छी प्रारंभिक प्रस्तुति है: (Google I/O 2011 से) https://www.youtube.com/watch?v=M3uWx-fhjUc (मुझे पता है कि यह एक लंबा वीडियो है, लेकिन वास्तव में यह स्पष्ट करता है कि कंपाइलर का उद्देश्य क्या है, और विभिन्न संकलन मोड वास्तव में क्या करते हैं। यह यह भी वर्णन करता है आपको बाहरी फ़ाइल की आवश्यकता क्यों होगी)।

नमस्ते, मैं तीन.जेएस का उपयोग करके एक एप्लिकेशन विकसित करने के लिए उत्सुक हूं, और इसलिए ADVANCED_OPTIMIZATIONS विकल्प समर्थन चाहता हूं।

जब एम्बेडिंग एप्लिकेशन केवल Three.js फ़ंक्शन के एक हिस्से का उपयोग करता है, तो डेड कोड हटाना दृढ़ता से काम करता है।

वर्तमान में, तीन.जेएस के लिए हर एक फ़ंक्शन को विकसित करने की आवश्यकता है, क्योंकि अभीष्ट उपयोग "सिर्फ तीन.मिन.जेएस की आवश्यकता है!" तक ही सीमित है। इस शास्त्रीय दृष्टिकोण को समझना आसान है, लेकिन इस दृष्टिकोण द्वारा लिखे गए कोड के लिए, जावास्क्रिप्ट मिनिमाइज़र कोड को कम कर सकते हैं केवल चर नामों को सिकोड़कर (छोटे चर नामों के लिए प्रभावी नहीं), रिक्त स्थान को हटाकर (केवल इंडेंट स्पेस, टैब और लाइन ब्रेक के लिए प्रभावी) और अन्य सस्ते ट्रिक्स।

"क्लोजर कंपाइलर स्टाइल" कोड के लिए ADVANCED_OPTIMIZATIONS विकल्प का उपयोग करके, यह संपूर्ण "आवश्यक नहीं कोड" को हटा सकता है, जो ज्यादातर बड़े पुस्तकालयों का वजन करता है। क्लोजर लाइब्रेरी जैसे

चूंकि three.js पहले से ही ऑब्जेक्ट-ओरिएंटेड शैली में लिखा गया है, मुझे लगता है कि पूरे कोड को "क्लोजर कंपाइलर स्टाइल" कोड में अपडेट करना (तकनीकी रूप से) मुश्किल नहीं है। जिन चीजों की मुझे चिंता है...

• क्लोजर कंपाइलर शैली को प्रत्येक फ़ंक्शन के लिए एनोटेशन की आवश्यकता होती है। वर्तमान में, उनमें से कोई भी नहीं है। अब तक विकसित किए गए सभी कार्यों में एनोटेशन जोड़ने में कितना समय लगेगा?
• क्लोजर कंपाइलर को सख्त प्रकार की परिभाषाओं की आवश्यकता होती है। यहां तक ​​​​कि शून्य और अपरिभाषित के लिए, आपको उनके लिए ठीक से काम करना चाहिए। यह उन कार्यों के लिए एक कठिन काम हो सकता है जिनमें "शून्य-अनुमत" पैरामीटर, "अपरिभाषित-अनुमत" पैरामीटर हैं, ...
• यदि आप ADVANCED_OPTIMIZATIONS द्वारा संकलित "पूर्ण-संस्करण वाली लाइब्रेरी" तैयार करना चाहते हैं, तो आपको एक उचित बाहरी फ़ाइल तैयार करनी चाहिए।

हाई शेड्यूल ज़ोर,

जाने के लिए यह एक अच्छा विचार है। क्या आप एक छोटा सा अंश साझा कर सकते हैं, कैसे
इसे तीन.जेएस में जोड़ा जाना है?

सस्नेह,

रामसुंदर माधवन

मंगल, जून 24, 2014 में 4:23 बजे पर, schedul Xor [email protected]
लिखा था:

नमस्ते, मैं तीन.जेएस का उपयोग करके एक एप्लिकेशन विकसित करने की आशा कर रहा हूं, और
इसलिए ADVANCED_OPTIMIZATIONS विकल्प समर्थन चाहते हैं।

जब एम्बेडिंग एप्लिकेशन केवल उपयोग करता है तो डेड कोड हटाना दृढ़ता से काम करता है
तीन.जेएस कार्यों का एक हिस्सा।

वर्तमान में, तीन.जेएस को विकसित किए गए प्रत्येक फ़ंक्शन की आवश्यकता होती है, क्योंकि
इच्छित उपयोग "बस तीन.मिन.जेएस की आवश्यकता है!" तक ही सीमित है। यह शास्त्रीय
दृष्टिकोण को समझना आसान है, लेकिन इस दृष्टिकोण द्वारा लिखे गए कोड के लिए,
जावास्क्रिप्ट मिनिमाइज़र केवल चर नामों को सिकोड़कर कोड आकार को कम कर सकते हैं
(छोटे चर नामों के लिए प्रभावी नहीं), रिक्त स्थान को हटाना (केवल प्रभावी
इंडेंट स्पेस, टैब और लाइन ब्रेक के लिए) और अन्य सस्ते ट्रिक्स।

"क्लोजर कंपाइलर स्टाइल" के लिए ADVANCED_OPTIMIZATIONS विकल्प का उपयोग करके
कोड, यह संपूर्ण "आवश्यक नहीं कोड" को हटा सकता है, जो ज्यादातर वजन करता है
बड़े पुस्तकालय। क्लोजर लाइब्रेरी जैसे पुस्तकालय
https://developers.google.com/closure/library/ बड़ा हो गया था, लेकिन
पुस्तकालय उपयोगकर्ता और डेवलपर इसकी परवाह नहीं करते क्योंकि वे जानते हैं कि
अधिकांश कोड संकलन चरण पर हटा दिए जाएंगे।

चूंकि तीन.जेएस पहले से ही वस्तु-उन्मुख शैली में लिखा गया है, मुझे लगता है कि यह है
नहीं (तकनीकी रूप से) पूरे कोड को "क्लोजर कंपाइलर" में अपडेट करना मुश्किल है
स्टाइल" कोड। जिन चीजों की मुझे चिंता है ...

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/mrdoob/three.js/issues/341#issuecomment -46957189।

@ शेड्यूल-एक्सर हमें निश्चित रूप से इसके साथ मदद की ज़रूरत है ... क्या कोड एनोटेशन वास्तव में आवश्यक हैं या क्या यह बाहरी लोगों के साथ पर्याप्त है?

नमस्ते,

मैं इस समुदाय के लिए नया हूँ, मुझे इनमें योगदान करने में दिलचस्पी होगी
परिवर्तन।

सस्नेह,

रामसुंदर माधवन

मंगल, पर 7:23 जून 24, 2014, पर Mr.doob [email protected] लिखा है:

@schedul-xor https://github.com/schedul-xor हमें निश्चित रूप से मदद की ज़रूरत है
इसके साथ... क्या कोड एनोटेशन वास्तव में आवश्यक हैं या क्या यह पर्याप्त है
बाहरी?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/mrdoob/three.js/issues/341#issuecomment -46973166।

ध्यान रखें कि उन्नत अनुकूलन के लिए एक निश्चित कोडिंग शैली की आवश्यकता होती है या वे आपके कोड को तोड़ देंगे। उदाहरण के लिए, three.js uniforms["diffuse"] और uniforms.diffuse मिलाता है, जिसकी क्लोजर उन्नत अनुकूलन के तहत अनुमति नहीं है। #3222 भी देखें।

हर जगह सख्त प्रकार के एनोटेशन जोड़ना काम की एक बड़ी मात्रा है, और बहुत सारी टिप्पणी लाइनें जोड़ता है (मेरी परियोजना में, इसने 2 के कारक से लाइन गिनती में वृद्धि की)।

अन्य वेब ढांचे/भाषाओं के लिए बाहरी फाइलें रखना अच्छा है।

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

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

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

चूँकि three.js एक बड़ा प्रोजेक्ट है, मैं सोच रहा हूँ कि मुझे पहले कहाँ काम करना चाहिए। जिस काम को आसानी से किया जा सकता है, उसी से शुरुआत करना बेहतर होगा।

फ़ाइल हेडर डालने के बारे में, प्रत्येक फ़ंक्शन के लिए फ़ंक्शन परिभाषा शैली कैसे बदलें?

THREE.Material = function(){
  :
};
THREE.Material.prototype = {
    constructor: THREE.Material,
    setValues: function ( values1, value2 ) {}
    getValues: function () { return this.a; }
    :
};

मैं

goog.provide('THREE.Material'); ← Write goog.provide('package.classname') at the first line

← three empty lines before <strong i="10">@constructor</strong>

/**
 * <strong i="11">@constructor</strong> ← Add <strong i="12">@constructor</strong> annotation to constructor
 */
THREE.Material = function(){
  :
};

← two empty lines before function definition
/**
 * <strong i="13">@param</strong> {!Array.<!string>} values1 Values1 explanation ← values1 is an array of strings. values1 can't be null, and elements inside values1 can't be null.
 * <strong i="14">@param</strong> {!number} value2 Value2 explanation ← value2 is a number.
 */
THREE.Material.prototype.setValue = function(values1, value2){
  goog.asserts.assertArray(values1);
  goog.asserts.assertNumber(value2);
  :
};


/**
 * <strong i="15">@return</strong> {!number} ← This function returns a non-null number.
 */
THREE.Material.prototype.getValue = function(){
  return this.a;
};

सभी पैरामीटर प्रकारों को सख्त करना और मूल्य प्रकारों को गैर-शून्य पर वापस करना आसान होगा। इससे ADVANCED_OPTIMIZATIONS संकलन त्रुटियों को पारित करना अधिक आसान हो जाएगा।

हम्म, मैं अभी भी कोड में बहुत सारी टिप्पणियों के साथ बहुत खुश नहीं हूं। कभी-कभी मुझे आश्चर्य होता है कि क्या पूरी चीज को टाइपस्क्रिप्ट की तरह पोर्ट करना बेहतर नहीं होगा (बहुत बुरा है कि एक माइक्रोसॉफ्ट के स्वामित्व में है)।

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

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

अंत में, किसी अन्य भाषा/ढांचे/कोडिंग शैली में तीन.जेएस के रूप में इतनी बड़ी परियोजना को पोर्ट करना कुछ ऐसा है जिस पर विस्तार से चर्चा की जानी चाहिए।

ठीक है, मैं मानता हूं कि three.js बहुत अधिक है, और इसलिए प्रत्येक फ़ंक्शन में एनोटेशन जोड़ने में कई सप्ताह लग सकते हैं। बंद होने से बेहतर AltJS मौजूद हो सकते हैं। इस पर अधिक गहराई से चर्चा की जानी चाहिए (यदि आप इसे किसी और चीज़ पर पोर्ट करना चाहते हैं)।

क्षमा करें, मैं प्रतीक्षा नहीं कर सकता। मैं वर्तमान प्रतिबद्धता को फोर्क कर दूंगा और पोर्ट करना शुरू कर दूंगा।

नमस्ते,

क्या इस एनोटेशन को जोड़ना स्वचालित करना संभव है? यदि हां, तो हम इसे जोड़ सकते हैं
बंद करने के उन्नत अनुकूलन को सक्षम करने से ठीक पहले build.py और जोड़ने के लिए।

सस्नेह,

रामसुंदर माधवन

बुध, जून 25, 2014 में 6:05 AM पर, schedul Xor [email protected]
लिखा था:

ठीक है, मैं सहमत हूं कि three.js विपुल है, और इसलिए प्रत्येक में एनोटेशन जोड़ना
कार्यों में कई सप्ताह लग सकते हैं। इससे बेहतर AltJS मौजूद हो सकते हैं
बंद करना इस पर चर्चा की जानी चाहिए (यदि आप इसे पोर्ट करने के लिए उत्सुक हैं
कुछ और) अधिक गहराई से।

क्षमा करें, मैं प्रतीक्षा नहीं कर सकता। मैं वर्तमान प्रतिबद्धता को फोर्क कर दूंगा और पोर्ट करना शुरू कर दूंगा।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/mrdoob/three.js/issues/341#issuecomment -47047966।

@ ramsundhar20 , मेरी राय में, एनोटेशन जोड़ना (गलत? कुछ नहीं से बेहतर। कोई बड़ी समस्या नहीं है। इसे अपडेट किया जा सकता है) पहले स्वचालन को और अधिक आसान बना देगा।

Three.js में वर्तमान में 163 जावास्क्रिप्ट फाइलें हैं जिनमें 1354 फ़ंक्शन परिभाषित हैं। हाँ यह बहुत बड़ा है, लेकिन यह बहुत दूर का लक्ष्य नहीं है।

// मुझे डर है अगर यह विषय जगह से बाहर है ...

@ शेड्यूल-एक्सोर फिर से, मैं वास्तव में प्रति फ़ंक्शन टिप्पणी करने का प्रशंसक नहीं हूं: /

@mrdoob ठीक है, मैं समझ गया।

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

यह अच्छा रहेगा :)

शुक्रिया! मैं इस पर काम करना शुरू कर दूंगा।

क्या क्लोजर कंपाइलर के साथ उपयोग की जाने वाली कम से कम एक आधार तीन.जेएस बाहरी फ़ाइल है? इसके लिए किसी भी अतिरिक्त Google शैली एनोटेशन के लिए Three.js स्रोत कोड की आवश्यकता नहीं है, यह केवल एक बाहरी ऐप से लिंकिंग बनाने के लिए है।

मुझे तीन.जेएस के लिए एक गुणवत्ता, पूर्ण बाहरी फ़ाइल में भी बहुत दिलचस्पी है। यहाँ एक है, लेकिन यह पूर्ण नहीं है:

https://github.com/cljsjs/packages/blob/master/three/resources/cljsjs/three/common/three.ext.js

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

हाँ, मेरा वोट गिनें। आदर्श रूप से एक उन्नत मोड संकलित करने के लिए, 100% टाइप किए गए तीनjs - या कम से कम एक बाहरी फ़ाइल।

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

सुपर-आक्रामक सेटिंग्स, जो कि उन्नत मोड + जेएस संपीड़न + प्रकार-आधारित अनुकूलन है, न केवल मृत कोड को हटा देगा, बल्कि सभी अच्छी चीजें कर सकता है जो एक अनुकूलन संकलक कर सकता है:

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

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

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

मुझे ऊपर बताई गई शाखा नहीं मिल रही है। क्या कोई अभी भी टाइप किए गए संस्करण पर काम कर रहा है?

@mrdoob मेनलाइन के संबंध में हृदय परिवर्तन की कोई उम्मीद?

मुझे मदद करने में खुशी होगी.

@mrdoob मेनलाइन के संबंध में हृदय परिवर्तन की कोई उम्मीद?

फिलहाल मैं WebGLRenderer को रीफैक्टर करने पर ध्यान केंद्रित कर रहा हूं

स्थिरांक को const बजाय var में बदल सकते हैं सभी वेबजीएल ब्राउज़रों के लिए अच्छा समर्थन है https://kangax.github.io/compat-table/es6/ (const->basic) और js इंजन const लिए अनुकूलित करना शुरू कर रहे हैं निश्चित क्षेत्र अनुकूलन का उपयोग करके वैश्विक स्थिरांक को तेज करना

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

संकलक समर्थन को बंद करने के लिए वापस: मैंने कुछ पठन और प्रयोग किया। यहाँ मुझे पता चला है:

• उन्नत मोड चलाने के लिए किसी एनोटेशन की आवश्यकता नहीं है,
• ऑप्टिमाइज़ेशन स्तर को क्रैंक करने के लिए एनोटेशन को धीरे-धीरे जोड़ा जा सकता है, और
• लोडर को काम करते रहने के लिए कुछ देखभाल की आवश्यकता होती है, लेकिन यह काफी आसान है।

मूल रूप से तीन अलग-अलग उपयोग के मामले हैं:

1. मॉडल को एप्लिकेशन और लाइब्रेरी के साथ कंप्रेस किया जा सकता है।
2. अनुप्रयोग और पुस्तकालय संकुचित हैं। मॉडल रनटाइम पर लोड होते हैं।
3. पुस्तकालय मूल मोड में संकलित है और एक उन्नत मोड ऐप इसका उपयोग करना चाहता है।

तीसरे को तीन.जेएस के लिए एक बाहरी फ़ाइल की आवश्यकता होती है और आईएमओ के बहुत कम लाभ के लिए बहुत काम है। तो मैं केवल पहले दो पर चर्चा करूंगा - ये पसंदीदा हैं, वैसे भी:

जब संकलक देखता है

anObject['aProperty']

यह संपत्ति के नाम को नहीं छूएगा (कोई तार कभी नहीं बदला जाता है)।

anObject.aProperty

दूसरी ओर संकलक को लगातार संपत्ति का नाम बदलने की अनुमति देता है, जब तक कि यह नहीं जानता कि anObject संकलित किए जा रहे एप्लिकेशन के बाहर है। कंपाइलर इसे बिल्ट-इन या स्पष्ट रूप से प्रदान किए गए _externs_ से जानता है।

यहाँ नुस्खा आता है:

• हम डॉट नोटेशन का उपयोग करके लोडर को लगातार गुणों तक पहुँचाते हैं।
• हम इनपुट टाइप करते हैं और केवल JSON के लिए एक बाहरी फ़ाइल लिखते हैं।
• उस बाहरी फ़ाइल के साथ संकलन केस 2 काम करने के लिए आवश्यक सभी होना चाहिए।
• उपयोग के मामले 1 के लिए हम बाहरी फ़ाइल का उपयोग नहीं करते हैं, बल्कि JSON में ऑब्जेक्ट कुंजियों से उद्धरणों को हटा देते हैं:

{
    "camera": {
        "object": {
    // ...

बस बन जाएगा

{
    camera: {
        object: {
    // ...

काफी सरल है, है ना?

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

बाहरी फ़ाइल फ़ाइल प्रारूप :-) का दस्तावेजीकरण करने वाले कभी-पुराने विकी पृष्ठों को भी बदल सकती है।

मुझे पता है कि यह मुद्दा काफी समय से बंद है। हालांकि मुझे हाल ही में एक क्लोजर कंपाइलर प्रोजेक्ट के भीतर तीन.जेएस का उपयोग करने में एक ही समस्या थी और इस पृष्ठ पर उतरा। मैंने एक टूल लिखा है जो .d.ts (टाइपस्क्रिप्ट डिक्लेरेशन फाइल्स) को क्लोजर कंपाइलर फाइल में बदल देता है। उपकरण और महान वर्णित निश्चित रूप से टाइप/थ्रीजेएस डिस्क्रिप्टर फ़ाइल का उपयोग करके यह पूरी तरह से काम करता है।
उपकरण: https://github.com/eredo/tsd2cce या npm install -g tsd2cce के माध्यम से स्थापित करें

उम्मीद है ये मदद करेगा...

@eredo जिसने मुझे पूरी तरह से मदद की। मैंने कोशिश की अन्य सभी जेनरेटर तीन.जेएस पुस्तकालय के लिए अच्छी संख्या में विधि परिभाषाओं को याद कर रहे थे। धन्यवाद!

@eredo @Corkle या कोई और, क्या आप हमें दिखा सकते हैं कि tsd2cce का उपयोग कैसे करें? पहला तर्क स्पष्ट रूप से .d.ts परिभाषा फ़ाइल है, लेकिन दूसरा तर्क क्या है? मुझे यह मुद्दा मिल रहा है। https://github.com/eredo/tsd2cce/issues/6

वास्तव में मैंने पाया कि फरवरी से r73 d.ts का उपयोग tsd2cce के साथ ठीक काम करता है, हालांकि r73 मेरे लिए बहुत पुराना है।

ऐसा करने का उचित तरीका अब d.ts फ़ाइलों से उत्पन्न करने के लिए tsicle का उपयोग करना होगा।

सभी को प्रणाम,

भावी पीढ़ी और सभी के लाभ के लिए मैंने Google क्लोजर कंपाइलर के ADVANCED_OPTIMIZATIONS और कुछ अन्य सुधारों के साथ पुस्तकालय को और छोटा करने के अपने प्रयासों पर यहां रिपोर्ट करने का निर्णय लिया।

मैंने एक extern.js बनाया है जो उन्नत अनुकूलन के साथ Three.min.js को चालू करने की अनुमति देता है। यह एकदम सही से दूर है।

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

मैं इस अनुमान-और-जांच को स्वचालित करना पसंद करूंगा और एक संपूर्ण extern.js प्राप्त करूंगा जो यथासंभव अधिक से अधिक संपत्ति के नामों को सुरक्षित रूप से प्रबंधित करता है। मुझे थ्री.जेएस के लिए यूनिट परीक्षणों का उपयोग करने और प्रोग्रामिक रूप से यह निर्धारित करने का विचार था कि कौन से मैंगल्ड प्रोपनामों के परिणामस्वरूप असफल परीक्षण हुए, लेकिन वर्तमान में कमांड लाइन से यूनिट परीक्षणों को चलाने के लिए संभव नहीं लगता है, उदाहरण के लिए फैंटमज के साथ। (शायद वेबजीएल के कारण)?

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

बाहरी.जेएस

अपडेट किया गया package.json बिल्ड-क्लोजर कमांड

मैंने लाइब्रेरी से सभी कंसोल.वार्न और कंसोल.एरर संदेशों को हटाने के लिए स्ट्रिंग रिप्लेस कमांड का भी इस्तेमाल किया, जैसा कि आप बिल्ड-क्लोजर कमांड में देख सकते हैं। इसके साथ, और कोड के कुछ वर्गों पर टिप्पणी करते हुए, मैंने अब तक मिनिफाइड लिब को लगभग 20% तक कम कर दिया है, और इसमें सुधार की गुंजाइश है।

@mrdoob यहां मेरी विधि की तरह कुछ करते हुए, आप अंततः एक extern.js की आपूर्ति कर सकते हैं जो उस कंपाइलर के लिए विशिष्ट एनोटेशन के साथ कोड को अव्यवस्थित किए बिना ADVANCED_OPTIMIZATIONS की अनुमति देता है, जो आपकी प्राथमिक चिंता प्रतीत होती है।

@medmr1 बहुत बढ़िया! क्या आपने अपने ऐप को तीन.जेएस लाइब्रेरी के साथ एक साथ संकलित करने का प्रयास किया है? यह आदर्श रूप से बाहरी फ़ाइल की आवश्यकता को रोक देगा।

मैंने पूरी चीज को बंद करने की कोशिश नहीं की है, नहीं। यह ठीक काम कर सकता है लेकिन मुझे संदेह है कि प्रोग्रामेटिक रूप से संदर्भित कुछ संपत्तियों के प्रबंधन के संबंध में अभी भी समस्याएं होंगी? आईई सामान var thing = ShaderLib[ shaderType + "BumpMapFrag"] लेकिन शायद मैं खुद को बहुत परेशानी बचाऊंगा?

हां, उन्नत अनुकूलन के साथ var thing = ShaderLib[ shaderType + "BumpMapFrag"] जैसा कुछ टूट जाएगा। संपत्ति संदर्भों को सांख्यिकीय रूप से विश्लेषण करने की आवश्यकता है। आप कुछ ऐसा कर सकते हैं:

function(shaderType) {
  if (shaderType == "a") {
    return ShaderLib.aBumpMapFrag;
  }
  if (shaderType == "b") {
    return ShaderLib.bBumpMapFrag;
  }
...

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

बाहरी लोगों के बजाय, आप @export एनोटेशन भी आज़मा सकते हैं।
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export -export-sometype