Three.js: ES6 JSM पुस्तकालयों के साथ JS पुस्तकालयों के लिए समर्थन जारी रखें

को निर्मित 5 अक्तू॰ 2020 · 51टिप्पणियाँ · स्रोत: mrdoob/three.js

क्या आपका फीचर अनुरोध किसी समस्या से संबंधित है?

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

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

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

स्टाइलिस्टिक रूप से, मैं नए नामित कार्यों को जोड़ने के बजाय अतिरिक्त कार्यक्षमता के साथ तीन को ओवरलोड करना पसंद करता हूं जो स्वतंत्र रूप से तैरते हैं। हालांकि यह स्पष्ट रूप से वरीयता है।

आप जो समाधान चाहते हैं उसका वर्णन करें

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

दस्तावेज़ीकरण से पता चलता है कि ES6 मॉड्यूल हर स्थिति में काम नहीं कर सकते हैं और उन स्थितियों के लिए यह एक बंडलर का उपयोग करने का सुझाव देता है जैसे कि ब्राउज़रिफ़/रोलअप/वेबपैक/पार्सल आदि ....

मेरे समाधान में एक स्वचालित ES6 बंडलर स्क्रिप्ट होगी जो /examples/jsm में मॉड्यूल के माध्यम से /examples/js गैर मॉड्यूल संस्करण उत्पन्न करने के लिए जाती है। इस प्रकार, डेवलपर्स को अब दो स्थानों पर परिवर्तन करने के बारे में चिंता करने की आवश्यकता नहीं है और यदि वे चाहें तो JS गैर-मॉड्यूल संस्करणों और वैश्विक var आयात शैली का उपयोग करना जारी रख सकते हैं।

JS गैर-मॉड्यूल फ़ाइलों की यह स्वचालित पीढ़ी निर्माण प्रक्रिया के हिस्से के रूप में की जा सकती है या पैकेज में एक कमांड हो सकती है। कोई व्यक्ति मैन्युअल रूप से चला सकता है। हालांकि मैं स्वचालित पीढ़ी का विकल्प चुनूंगा।

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

उन विकल्पों का वर्णन करें जिन पर आपने विचार किया है

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

अतिरिक्त संदर्भ

इस पुस्तकालय और हर उस व्यक्ति को बहुत प्यार जो या तो कोड में योगदान देता है या मुद्दों की रिपोर्टिंग/चर्चा करता है।

Suggestion

स्रोत

Bug-Reaper

👍5 🚀1 👎1

सबसे उपयोगी टिप्पणी

पेशेवरों और विपक्षों को साझा करने के लिए सभी को धन्यवाद। यह सुनिश्चित करने के लिए कि हम सोच-समझकर निर्णय ले रहे हैं, इन्हें साझा करना हमेशा अच्छा होता है।

यह कुछ ऐसा है जो मैं इस वर्ष कुछ मस्तिष्क चक्र खर्च कर रहा हूं, और मैंने ब्राउज़र विक्रेताओं से उनकी प्राथमिकताओं के बारे में भी पूछा है ताकि मैं आगे की योजना बना सकूं।

मैं मानता हूं कि ES6 मॉड्यूल भविष्य हैं, लेकिन आयात मानचित्रों के बिना उनके साथ विकसित होने से भारी सिरदर्द हो सकता है और आपके प्रवाह को पूरी तरह से तोड़ सकता है। जब हमने examples/js को पदावनत करने का निर्णय लिया तो मैं उम्मीद कर रहा था कि आयात मानचित्रों में अधिक कर्षण होगा, लेकिन ऐसा लगता है कि यह वर्तमान में ब्राउज़रों के लिए प्राथमिकता नहीं है।

इस वजह से, मैंने examples/js फ़ोल्डर बहिष्करण को तब तक निलंबित करने का निर्णय लिया जब तक कि ब्राउज़र आयात मानचित्रों को लागू नहीं कर देते। मैं अपने पहले घन को प्रस्तुत करने के लिए नए लोगों को पॉलीफिल या बंडलर के बारे में जानने के लिए मजबूर करने से नफरत करूंगा।

मैं @ बग-रीपर के समान निष्कर्ष पर पहुंचा। आज मैं एक स्क्रिप्ट बनाने पर विचार कर रहा हूं जो examples/jsm examples/js है।

mrdoob 12 अक्तू॰ 2020

❤13

सभी 51 टिप्पणियाँ

लोगों को बुनियादी वैनिला सीएसएस/जेएस/एचटीएमएल सिखाना बहुत आसान है, साथ ही पूरे नोड/एनपीएम + फ्रेमवर्क को एक ही समय में उनके गले से नीचे धकेले बिना। स्थैतिक पुस्तकालय यहाँ प्रवेश की बाधा को कम रखते हैं।

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

gkjohnson 5 अक्तू॰ 2020

👍9

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

सफाई देने के लिए धन्यवाद! यह वास्तव में एक अच्छी बात है!
मेरा मानना है:

<script type="module">

  import { OrbitControls } from 'https://unpkg.com/three@<VERSION>/examples/jsm/controls/OrbitControls.js';

  const controls = new OrbitControls();

</script>
````
is perhaps less intuitive and harder to understand for newcomers than:

Bug-Reaper 5 अक्तू॰ 2020

एक सेकंड रुकिए... हमारे पास अभी भी है:

<script src="path/to/local/build/three.js"></script>

विरोध के रूप में:

<script type=module src="path/to/local/build/three.module.js"></script>

पहली एक स्थिर स्क्रिप्ट है जिसका उपयोग पुराने-वैश्विक-तरीके के अनुसार किसी के html के भीतर किया जा सकता है ... है ना? ES6 में संक्रमण के बाद आप क्या नहीं कर सकते थे?

DefinitelyMaybe 5 अक्तू॰ 2020

👍1

अगर मैं सही ढंग से समझता हूं कि योजना अभी भी "/build/three.module.js" के अतिरिक्त "/build/three.js" को शामिल करने की है।

हां। हालाँकि, यह संदिग्ध है कि क्या यह दृष्टिकोण समझ में आता है। जब examples/js को हटा दिया जाता है, तो कुछ ही उपयोग के मामले बचे होते हैं जहां three.js और three.min.js अभी भी उपयोगी होते हैं।

three.js और three.min.js को हटाना वास्तव में फायदेमंद होगा क्योंकि यह हमें npm पैकेज के main प्रवेश बिंदु को बदलने की अनुमति देगा, #19575 देखें।

यदि हम इतनी आसानी से ऐसा कर सकते हैं, तो मेरा मानना है कि निर्माण प्रक्रिया के हिस्से के रूप में ES6 बंडलर स्क्रिप्ट के माध्यम से स्वचालित रूप से उन्हें उत्पन्न करके /examples/js का समर्थन जारी रखना समझ में आता है।

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

मेरा मानना है कि यदि आवश्यक हो तो उपयोगकर्ता को ES6 से ES5 रूपांतरण का ध्यान रखना होगा। कोड मिनिफिकेशन या अन्य बिल्ड-संबंधित कार्यों के लिए समान।

Mugen87 5 अक्तू॰ 2020

मुझे विश्वास है कि तुम सही हो। अगर मैं सही ढंग से समझता हूं कि योजना अभी भी " /build/three.module.js " के अलावा " /build/three.js " को शामिल करने की है।

सत्य

/examples फोल्डर से फिल करने में समस्या यह है कि जब आपने /build/three.js उपयोग किया था तब आपको /examples/js से फ़ाइलों का उपयोग करने की आवश्यकता थी और जब आपने /build/three.module.js उपयोग किया था तब /examples/jsm की फ़ाइलों का उपयोग करना होगा। /build/three.module.js , उर्फ लोडिंग विधि में निरंतरता रखें।

क्यों? क्योंकि मॉड्यूल का उपयोग करते समय मुख्य THREE ऑब्जेक्ट एक सादा जेएस ऑब्जेक्ट THREE = {} नहीं है बल्कि इसके बजाय एक आंतरिक ब्राउज़र का मॉड्यूल ऑब्जेक्ट है जिसे सील कर दिया गया है (विस्तार योग्य नहीं), इसलिए, /examples/js से फ़ाइलें THREE ऑब्जेक्ट में एक नई संपत्ति लिखने का प्रयास करता है विफल रहता है।

तो आप import * as THREE from '/build/three.module.js और THREE.WhateverExample = function() ... को मिला नहीं सकते

एक संभावित तरीका आयातित lib का नाम THREE के अलावा किसी और चीज़ में बदलना है और इसमें लिखे जाने वाले उदाहरणों के लिए एक सादा जेएस THREE वैश्विक ऑब्जेक्ट फिर से बनाना है ...

यह आमतौर पर की समस्या है

पारंपरिक जेएस में शामिल हैं

जो वैश्विक स्थान नामकरण को दूषित करता है, और क्योंकि आप लोड की गई फ़ाइल में नामों को संशोधित नहीं कर सकते हैं, इसलिए आपको इस तरह की त्रुटियां मिल सकती हैं ...
दूसरी ओर, मॉड्यूल के साथ, उपयोगकर्ता आयात के दौरान नामकरण की शक्ति प्राप्त करता है और यह अब 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>

devingfx 5 अक्तू॰ 2020

@ Mugen87 आप 100% सही हैं। यदि हम /examples/js को छोड़ देते हैं तो हम तीन. js और तीन.min.js को भी छोड़ सकते हैं क्योंकि वे अनिवार्य रूप से किसी भी ऐड-ऑन मॉड्यूल के साथ असंगत हैं। उनका उपयोग मामला आला होगा और यह भ्रम पैदा करने की लगभग गारंटी है।

@devingfx आप सही कह रहे हैं कि मॉड्यूल के फायदे हैं और संभावित वैश्विक नाम संघर्षों को समाप्त करता है। उपयोग के वर्षों में मैंने कभी भी तीन वैश्विक चर के साथ कुछ भी संघर्ष नहीं किया है और मुझे लगता है कि यह एक असंभव परिदृश्य है लेकिन आपकी बात तकनीकी रूप से सही है।

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

@ Mugen87 क्या यह वास्तव में एक पारंपरिक जेएस को बनाए रखने के लिए भयानक है जिसमें एक मॉड्यूल के अलावा एक वैश्विक संस्करण का उपयोग होता है? कई पुस्तकालय दोनों का समर्थन करते हैं और जो मैं पारंपरिक जेएस संस्करण को बता सकता हूं वह अक्सर मॉड्यूल संस्करण समकक्षों के रूप में लोकप्रिय रूप से उपयोग किया जाता है। दोनों के फायदे/नुकसान हैं और उनमें से कुछ वरीयता के लिए उबाल जाते हैं। क्या डेवलपर्स को गैर-मॉड्यूल संदर्भ में पुस्तकालय का उपयोग करने का विकल्प देना अच्छा नहीं है?

मैं तीन. module.js और /examples/jsm से स्वचालित रूप से तीन.min.js, तीन.js और /examples/js जेनरेट करने के लिए आवश्यक कोड ट्रांसपिलेशन सुविधाओं को बनाने/परीक्षण करने का ध्यान रखने को तैयार हूं। ट्रांसपिलेशन वर्कफ़्लो को चालाकी से पूरा करने के बाद, इसे कुछ न्यूनतम रखरखाव की आवश्यकता हो सकती है लेकिन यह != दो समानांतर संस्करणों को बनाए रखता है। अधिकांश भाग के लिए कोड को केवल मॉड्यूल फ़ाइलों पर अद्यतन करने की आवश्यकता होगी और केवल कभी-कभी आपको कुछ ट्रांसपिलेशन बकवास को ठीक करने की आवश्यकता होगी।

मेरे पास पर्याप्त परियोजनाएं हैं जो पारंपरिक वैश्विक वाक्यविन्यास पर भरोसा करती हैं और इसमें शामिल हैं कि मैं वैसे भी मॉड्यूल के ट्रांसपिलेशन को स्वचालित करने के लिए काम करने जा रहा हूं। मुझे लगता है कि बहुत कम से कम हम package.json में एक कमांड शामिल कर सकते हैं और इसे "लीगेसी-बिल्ड" कह सकते हैं जो मॉड्यूल को तीन.min.js, three.js और /examples/js में ट्रांसपाइल करता है जो मूल के समान व्यवहार करते हैं फ़ाइलें अब। इन फ़ाइलों को रेपो के लिए प्रतिबद्ध होने या डिफ़ॉल्ट रूप से बनाए जाने की भी आवश्यकता नहीं है। हम यह भी चेतावनी दे सकते हैं कि वे विरासत समर्थन के लिए हैं, उन्हें काम करने की गारंटी नहीं है, हम इसके बजाय मॉड्यूल का उपयोग करने का सुझाव देते हैं ...

वास्तविक रूप से हालांकि मुझे लगता है कि यह अधिक समझ में आता है कि उन्हें रेपो में रखें और बस उन्हें बिल्ड पर ट्रांसपिलिंग के माध्यम से स्वचालित रूप से जेनरेट किया जाए।

Bug-Reaper 6 अक्तू॰ 2020

package.json में एक कमांड और इसे "लीगेसी-बिल्ड" कहते हैं जो मॉड्यूल को ट्रांसपाइल करता है

उचित लगता है। बेबेल का हाल ही में विलय नहीं हुआ था? इसलिए मुझे लगता है कि यह ऐसा करने योग्य हो सकता है

संपादित करें: स्पष्ट करने के लिए, नहीं कहा गया है कि नया आदेश किसी के द्वारा चलाए जाने वाले उपयोगकर्ताओं को छोड़कर जो निर्माण कहना चाहते हैं

DefinitelyMaybe 6 अक्तू॰ 2020

👍1

क्या यह वास्तव में एक पारंपरिक जेएस को बनाए रखने के लिए भयानक है जिसमें एक मॉड्यूल के अलावा एक वैश्विक संस्करण का उपयोग होता है?

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

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

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

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

gkjohnson 6 अक्तू॰ 2020

👍5

अगर मैं सही ढंग से समझता हूं कि योजना अभी भी "/build/three.module.js" के अतिरिक्त "/build/three.js" को शामिल करने की है।
हां। हालाँकि, यह संदिग्ध है कि क्या यह दृष्टिकोण समझ में आता है।
जब example/js को हटा दिया जाता है, तो कुछ ही उपयोग के मामले बचे होते हैं जहाँ तीन.js और तीन.min.js अभी भी उपयोगी होते हैं।

@मुगेन 87 @mrdoob

माइकल,
वास्तव में "three.min.js" को कम से कम 2 साल और रखना जरूरी है।
इसलिए नहीं कि मेरे सारे नमूने इसी पर आधारित हैं।
लेकिन क्योंकि इस पर हजारों फाइलें और गूगल के शीर्ष कुत्ते आधारित हैं!
उदाहरण: https://www.google.com/search?source=hp&q=webgl+benchmark

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

रिकार्डो को भी इन सब के बारे में सोचना चाहिए।
चियर्स

RemusMar 6 अक्तू॰ 2020

❤2 👎1 👍1

three.js और three.min.js को हटाने पर चर्चा की जा सकती है और examples/js के चले जाने पर इसकी योजना बनाई जा सकती है। जब आप examples/js से फ़ाइलें आयात नहीं कर सकते, तो उनके खोए हुए महत्व को उजागर करना मेरे लिए केवल महत्वपूर्ण था।

Mugen87 6 अक्तू॰ 2020

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

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

यदि समय आता है जहां इसे बनाए रखना बहुत कठिन है, तो हम इसे हमेशा छोड़ सकते हैं, लेकिन मुझे लगता है कि उन समस्याओं के कारण छूट देने की मूर्खता है जो हमारे पास अभी तक नहीं हैं। अब इसे लागू करना सबसे आसान होगा जबकि हमारे पास अभी भी /examples/jsm और example /js के बीच 1 से 1 समानता है। हम संभवतः बड़े पैमाने पर /example/jsm मॉड्यूल पदानुक्रम को फिर से व्यवस्थित नहीं करेंगे और मुझे लगता है कि जब हम करते हैं तो हम बंडलर में वृद्धिशील अपडेट कर सकते हैं। मैं आगे बढ़ने जा रहा हूं और इसके लिए काम के सबूत पर काम करना शुरू कर दूंगा (बेबेल के साथ क्योंकि यह पहले से ही जोड़ा गया है?) अपना पैसा लगाने के लिए जहां मेरा मुंह है जैसा वे कहते हैं।

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

Bug-Reaper 7 अक्तू॰ 2020

👍1

मैं अन्य सहयोगियों के लिए नहीं बोल सकता लेकिन मैं इस विषय पर अपना विचार नहीं बदलूंगा। मैं examples/js को हटाने के लिए वोट करता हूं, जैसा कि यहां चर्चा की गई है और यहां #18749 की प्रतिबद्धता की गई है।

Mugen87 7 अक्तू॰ 2020

👍3

मैं उदाहरण/js को हटाने के लिए वोट करता हूं, जैसा कि यहां चर्चा की गई है और यहां #18749 की प्रतिबद्धता है।

मुझे इससे कोई दिक्कत नहीं है।
जब तक "three.min.js" कुछ और वर्षों के लिए उपलब्ध है ...

RemusMar 7 अक्तू॰ 2020

इनपुट मुगेन के लिए धन्यवाद, मैंने उस धागे के माध्यम से पढ़ा लेकिन यह निर्णय के स्पष्टीकरण के विरोध में एक घोषणा के रूप में अधिक प्रतीत होता है। मेरी धारणा यह है कि सरलीकृत विकास इस दिशा में आगे बढ़ने का प्राथमिक कारण है, क्या कोई अन्य हैं?

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

Bug-Reaper 7 अक्तू॰ 2020

👍1

मैंने उस धागे के माध्यम से पढ़ा था लेकिन यह निर्णय के स्पष्टीकरण के विरोध में एक घोषणा के रूप में अधिक प्रतीत होता है।

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

मेरी धारणा यह है कि सरलीकृत विकास इस दिशा में आगे बढ़ने का प्राथमिक कारण है, क्या कोई अन्य हैं?

मैं जो सबसे बड़ा देखता हूं वह उप-मॉड्यूल का उपयोग और आयात करने की क्षमता है जो अनावश्यक कोड को कम करता है और पुन: प्रयोज्य कार्यान्वयन के लिए बनाता है।

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

sciecode 7 अक्तू॰ 2020

👍4 ❤3

हाँ, अच्छा बिंदु। हमें पहले से ही Pass वर्ग (सभी FX पासों का आधार वर्ग) को EffectComposer में एम्बेड करने जैसे गंदे हैक करने होंगे ताकि यह सुनिश्चित किया जा सके कि लीगेसी कोड टूट न जाए।

Mugen87 7 अक्तू॰ 2020

👍1

बहुत अच्छे अंक पूरे दौर में बने।

लोगों को ऑन-ट्रैक/अप-टू-डेट प्राप्त करना और रखना (और मेरे अपने अनुभव से) एक कठिन मुद्दा है। इस पर कुछ विचार करने की कोशिश करेंगे।

DefinitelyMaybe 7 अक्तू॰ 2020

❤1

वास्तव में "three.min.js" को कम से कम 2 साल और रखना जरूरी है।

बैबेल का उपयोग करके ES5 बिल्ड बनाना हमेशा संभव होगा। जब यह सवाल आता है तो हमें जिस प्रश्न का उत्तर देना होगा, वह यह है कि क्या इसके लिए जिम्मेदारी हमारे पास है या डेवलपर के साथ है जो तीन.जेएस का उपयोग कर रहा है।

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

लेकिन क्योंकि इस पर हजारों फाइलें और गूगल के शीर्ष कुत्ते आधारित हैं!
उदाहरण: google.com/search?source=hp&q=webgl+benchmark

यह वह शीर्ष साइट है जो उस खोज से मेरे लिए सामने आती है, और वे R53 का उपयोग कर रहे हैं इसलिए मुझे नहीं लगता कि यह परिवर्तन उन्हें बहुत बुरी तरह प्रभावित करेगा: https://www.wirple.com/bmark/

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

looeee 8 अक्तू॰ 2020

👍2

@looeee आप कुछ अच्छे बिंदुओं को छूते हैं। जैसा कि ऊपर उल्लेख किया गया है, मैं सहमत हूं कि यहां एक ही समय में ES5 three.min.js और three.js को पदावनत करना समझ में आता है। शायद यह अपनी अलग चर्चा होनी चाहिए?

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

मुझे लगता है कि हमें मुख्य रेपो में एक फ़ाइल की अनुमति देना एक उचित समझौता है ताकि हम बेबेल ES6 से ES5 ट्रांसपिलर स्क्रिप्ट पर एक साथ काम कर सकें। क्या वहां वाकई कोई समस्या है? योगदानकर्ताओं को एक ऐसी सुविधा पर काम करने की अनुमति देना जो उन्हें मुख्य रेपो में एक साथ चाहिए?

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

Bug-Reaper 8 अक्तू॰ 2020

अगर मैं इसके लिए पीआर बनाता हूं और यह काम करता है

मेरा मतलब है, मुझे यह देखकर खुशी हो रही है कि यह शुरू हो गया है

क्या आप वाकई इसे अस्वीकार करने के लिए वोट देंगे?

यदि यह लाइनिंग पास में विफल रहता है तो सभी दांव बंद हो जाएंगे

DefinitelyMaybe 8 अक्तू॰ 2020

👍1

क्या वहां वाकई कोई समस्या है?

हां, चूंकि भंडार को बहिष्कृत कोडिंग पैटर्न को बढ़ावा नहीं देना चाहिए।

Mugen87 8 अक्तू॰ 2020

👍2

हां, चूंकि भंडार को बहिष्कृत कोडिंग पैटर्न को बढ़ावा नहीं देना चाहिए।

इसे आधिकारिक तौर पर अभी तक पदावनत नहीं किया गया है यदि हम three.js + three.min.js को बर्खास्त नहीं कर रहे हैं (स्वीकार किया गया है कि आईटीटी है कि हमें उन्हें भी बर्खास्त करना चाहिए) और एक बेबेल स्क्रिप्ट होने पर आपको मैन्युअल रूप से चलाना होगा शायद ही एक चमकदार समर्थन। मैं सहमत हूं कि हमें निश्चित रूप से लोगों को इसके बजाय मॉड्यूल का उपयोग करने के लिए प्रोत्साहित करना चाहिए और इसके बारे में बेबेल स्क्रिप्ट और जेनरेट की गई फाइलों में एक चेतावनी होनी चाहिए। मैं योगदानकर्ताओं को उन परिस्थितियों में लोगों के लिए एक साथ बैबल स्क्रिप्ट पर काम करने की अनुमति देने से असहमत हूं जो किसी भी कारण से मॉड्यूल का उपयोग नहीं कर सकते हैं जो एक बहिष्कृत कोडिंग पैटर्न को बढ़ावा दे रहा है। मुख्य रूप से क्योंकि अभी भी ऐसी स्थितियाँ हैं जहाँ मॉड्यूल का उपयोग करना अव्यावहारिक/अव्यावहारिक है। दस्तावेज़ इस आवश्यकता को स्वीकार करते हैं। मुझे लगता है कि हम उन लोगों के लिए सुरक्षित रूप से एक फ़ाइल जोड़ सकते हैं जिन्हें इस पर एक साथ काम करने के लिए इसकी आवश्यकता है।

Bug-Reaper 8 अक्तू॰ 2020

मैं सहमत हूं कि यहां एक ही समय में ES5 तीन.min.js और तीन.js को पदावनत करना समझ में आता है।

मेरा मतलब था कि हमें एक ही समय में example/js, three.min.js, और three.js को हटा देना चाहिए, यानी सभी ES5 कोड को एक से अधिक रिलीज़ में फैलाने के बजाय एक रिलीज़ में हटा दें।

looeee 9 अक्तू॰ 2020

👍2

@ मुगेन87

हां, चूंकि भंडार को बहिष्कृत कोडिंग पैटर्न को बढ़ावा नहीं देना चाहिए।

आप अभी भी विंडोज 10 में डॉस गेम्स चला सकते हैं।
और इसका मतलब यह नहीं है कि माइक्रोसॉफ्ट "बहिष्कृत कोडिंग पैटर्न" को बढ़ावा दे रहा है।

RemusMar 9 अक्तू॰ 2020

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

खैर, यह न भूलें कि उत्पादन के लिए तैयार एप्लिकेशन बनाने का मतलब है अपना कोड बंडल करना :)

मैं रोलअप जैसे बंडलिंग टूल की सराहना करता हूं जो उपलब्ध हैं लेकिन मुझे लगता है कि हमें कुछ प्रश्नों पर विचार करना चाहिए:

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

इसके बारे में मेरी व्यक्तिगत भावनाएँ:

यह पुस्तकालय एक दशक पुराना है। वहाँ एक विशाल पारिस्थितिकी तंत्र है जो ES5/UMD में लिखे गए उदाहरण फ़ोल्डर में मॉड्यूल पर निर्भर करता है। मुझे नहीं लगता कि पूरे पारिस्थितिकी तंत्र के लिए समर्थन छोड़ना उचित है।

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

क्या करे?

आइए प्रत्येक रिलीज के बाद दिए गए वितरण के लिए ES6 मॉड्यूल को ES5/UMD मॉड्यूल में संकलित करें।

हां, चूंकि भंडार को बहिष्कृत कोडिंग पैटर्न को बढ़ावा नहीं देना चाहिए।

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

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

मुझे ES5/UMD मॉड्यूल के बारे में भी ऐसा ही लगता है। मैं ऐसे पैटर्न, तकनीकों और टूलिंग को खोजने में सक्षम हूं जो वास्तव में उच्च गुणवत्ता वाले कोड आधारों को बनाए रखते हैं और उस व्यक्तिगत वरीयता का प्रयोग जारी रखना चाहते हैं।

gigablox 11 अक्तू॰ 2020

👎2 👍1

आइए प्रत्येक रिलीज के बाद दिए गए वितरण के लिए ES6 मॉड्यूल को ES5/UMD मॉड्यूल में संकलित करें।

लूई ने जो कहा उससे मैं सहमत हूं।

क्या यह मान लेना उचित है [...]

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

DefinitelyMaybe 11 अक्तू॰ 2020

आइए प्रत्येक रिलीज के बाद दिए गए वितरण के लिए ES6 मॉड्यूल को ES5/UMD मॉड्यूल में संकलित करें।

यह कोई भी कर सकता है; उस लागत को तीन.जेएस अनुरक्षकों द्वारा वहन करने की आवश्यकता नहीं है। मैं दोहराना चाहता हूं कि @gkjohnson ने ऊपर क्या कहा, examples/js और examples/jsm दोनों निर्देशिकाओं को बनाए रखने की लागत अधिक है। हम इसे अनिश्चित काल तक नहीं कर सकते हैं, और यह स्पष्ट है कि ES6 मॉड्यूल दो दृष्टिकोणों में से अधिक आधुनिक हैं। निम्नलिखित लागतों पर विचार करें:

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

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

हम समस्या को सरलता से फिर से लिख सकते हैं: हमारे सभी उदाहरण - जो कि तीन.जेएस पुस्तकालय के महत्वपूर्ण लेकिन वैकल्पिक भाग हैं - वर्तमान में किसी भी मॉड्यूल सिंटैक्स का उपयोग नहीं करते हैं। यूएमडी नहीं, कॉमनजेएस नहीं, ईएस6 मॉड्यूल नहीं। वे बस एक THREE वैश्विक नामस्थान पैच करते हैं। हम इसके बजाय ES6 आयात/निर्यात सिंटैक्स का उपयोग करके इसे अपडेट करना चाहते हैं, और कई प्रारंभिक चेतावनियां दी गई हैं कि इस परिवर्तन की योजना बनाई गई थी।

वहाँ एक विशाल पारिस्थितिकी तंत्र है जो ES5/UMD में लिखे गए उदाहरण फ़ोल्डर में मॉड्यूल पर निर्भर करता है। मुझे नहीं लगता कि पूरे पारिस्थितिकी तंत्र के लिए समर्थन छोड़ना उचित है।

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

donmccurdy 11 अक्तू॰ 2020

👍7

उदाहरण/जेएस और उदाहरण/जेएसएम निर्देशिका दोनों को बनाए रखने की लागत अधिक है।

मैं इसमें थोड़ा और खोदना चाहता हूं। मैंने बहुत सारे कस्टम टूलिंग लिखे हैं और फ्रंट एंड एप्लिकेशन के लिए ऑटोमेशन स्क्रिप्ट का निर्माण किया है और मुझे किसी भी तरह से मदद करने में खुशी होगी।

स्वचालन बनाना और बनाए रखना
डिबगिंग रिलीज विफलता जब स्वचालन टूट जाता है

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

यह सुनिश्चित करना कि सभी पुल अनुरोध स्रोत फ़ाइल को अपडेट करें, न कि जेनरेट की गई फ़ाइल को

हो सकता है कि कोई छोटी स्क्रिप्ट या परीक्षण रिलीज़ वर्कफ़्लो में इसमें मदद कर सके।

दस्तावेज़ीकरण बनाए रखना जो बताता है कि दोनों वर्कफ़्लो का उपयोग कैसे किया जाता है

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

CJS और ES6 वर्कफ़्लो दोनों का उपयोग करने का प्रयास करने वाले उपयोगकर्ताओं के बग रिपोर्ट और समर्थन प्रश्नों का उत्तर देना।

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

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

कुल मिलाकर मुद्दों की मात्रा को कैसे कम करें?

यदि वास्तविक लक्ष्य समग्र रूप से मुद्दों की मात्रा को कम करना है, तो शायद सख्त मुद्दे नीतियां इसमें मदद कर सकती हैं। मैं देख रहा हूं कि आप लोग पहले से ही Help (please use the forum) जैसे टैग का उपयोग करके इसके साथ बहुत अच्छा काम कर रहे हैं, लेकिन हो सकता है कि इस प्रकार की और चीजों की आवश्यकता हो।

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

युगल विचार:

लेखन के समय suggestions और enhancements में (271) खुले मुद्दे हैं। ऐसा लगता है कि ये लेबल बहुत शोर उत्पन्न करते हैं। हो सकता है कि वास्तविक सुझाव के रूप में केवल पीआर तैयार/चेक पास करें। बाकी सब कुछ इंस्टा-क्लोज करें और Discussion (please use the forum) के रूप में चिह्नित करें।

लेखन के समय loaders में (61) खुले मुद्दे हैं। यह लेबल भी बहुत शोर उत्पन्न करता प्रतीत होता है। मुझे इस लेबल के साथ suggestions और enhancements या खराब रूप से गठित बग रिपोर्ट से संबंधित बहुत सी समस्याएं दिखाई देती हैं। हो सकता है कि केवल अच्छी तरह से बनाई गई बग रिपोर्ट और पीआर तैयार/सुझावों के लिए पास किए गए चेक लें। बाकी सब कुछ इंस्टा-क्लोज करें और उसके अनुसार मार्क करें।

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

मैं सहमत हूं कि कुछ भी अपडेट किया जा सकता है, लेकिन अगर हम इन उपयोगकर्ताओं को स्थायी रूप से समर्थन जारी रखने के लिए थोड़ा सा काम करने का कोई तरीका ढूंढ सकते हैं तो मैं @ बग-रीपर से सहमत हूं:

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

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

gigablox 12 अक्तू॰ 2020

मैं इसमें थोड़ा और खोदना चाहता हूं। मैंने बहुत सारे कस्टम टूलिंग लिखे हैं और फ्रंट एंड एप्लिकेशन के लिए ऑटोमेशन स्क्रिप्ट का निर्माण किया है और मुझे किसी भी तरह से मदद करने में खुशी होगी।

अच्छा।

कुल मिलाकर मुद्दों की मात्रा को कैसे कम करें?

कृपया इसे ऑन-ट्रैक रखें। एक और सूत्र पर आगे चर्चा करने में खुशी हो रही है। यह कुछ हद तक मेरी पिछली टिप्पणी से संबंधित है।

मैं यह कहने में @ बग-रीपर से सहमत हूं:
मैं चाहता हूं कि हम सभी ने एक ट्रांसपिलेशन/बंडल वर्कफ़्लो नहीं बनाया है [...]

मुझे लगता है कि हम सभी इस पर सहमत हैं।

DefinitelyMaybe 12 अक्तू॰ 2020

mrdoob 12 अक्तू॰ 2020

❤13

@mrdoob

जब तक ब्राउज़र आयात मानचित्रों को लागू नहीं करता तब तक मैंने उदाहरण/जेएस फ़ोल्डर बहिष्करण को निलंबित करने का निर्णय लिया।
मैं @ बग-रीपर के समान निष्कर्ष पर पहुंचा। आज मैं एक ऐसी स्क्रिप्ट बनाने पर एक नज़र डाल रहा हूं जो उदाहरणों/जेएसएम फाइलों से उदाहरण/जेएस बनाता है।

एक बुद्धिमान निर्णय।
मैं

RemusMar 12 अक्तू॰ 2020

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

Mugen87 12 अक्तू॰ 2020

👍8

और मुझे नहीं लगता कि 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 मॉड्यूल के साथ समस्या यह है कि उपयोगकर्ता अपने स्वयं के प्रोजेक्ट में OrbitControls.js को /js फ़ोल्डर में कॉपी नहीं कर सकता है और इसे वैसे ही आयात कर सकता है जैसे वे करते थे। यह काम नहीं करेगा क्योंकि OrbitControls.js ../../build/three.module.js की तलाश में है।

आयात मानचित्रों के साथ, OrbitControls.js केवल three से आयात करेगा। उपयोगकर्ता फ़ाइल को जहाँ चाहे कॉपी कर सकता है और फिर आयात मानचित्र में पथ को समायोजित कर सकता है।

आयात मानचित्र हमें "पुराने" दिनों की तरह फ़ाइलों को आयात करने में आसानी के करीब लाते हैं। यह उतना आसान नहीं होगा जितना पहले था, लेकिन कम से कम उपयोगकर्ता को फ़ाइलें आयात करते समय ऑर्डर के बारे में चिंता करने की ज़रूरत नहीं होगी। कुछ जीतो कुछ खो दो।

mrdoob 12 अक्तू॰ 2020

👍3 👎1

सहमत हैं कि आयात मानचित्र आयात को विन्यास योग्य और इस प्रकार अधिक लचीला बना देंगे। हालांकि उपयोगकर्ता को अभी भी आयात मानचित्र को समायोजित करना है (और इस प्रकार समझें कि यह वास्तव में क्या है)।

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

Mugen87 12 अक्तू॰ 2020

👍2

मैं वास्तव में एक विरोधी पैटर्न के रूप में नहीं देखता।

इसी तरह मैंने वेबसाइट करना सीखा। कोई .css फ़ाइलों को /css फ़ोल्डर में रखेगा, फिर छवियों को /img में और .js फ़ाइलों को /js में रखेगा।

पिछले महीनों में मैं ES6 मॉड्यूल/सीडीएन दृष्टिकोण का उपयोग करके कुछ प्रयोग कर रहा हूं और यह मुझे अच्छा नहीं लगता कि पुस्तकालय एक अलग डोमेन से आते हैं जहां मेरी परियोजना है।

फ़ाइलों की प्रतिलिपि न बनाने पर एक बड़ी चीज़ जो हम खो देते हैं, वह है उन्हें संपादित करने में सक्षम होना। examples/js में फ़ाइलों को हमेशा ऐसे उदाहरण माना जाता था जिन्हें आप शीर्ष पर बना सकते हैं। अगर मैंने अपनी परियोजना में OrbitControls.js की प्रतिलिपि बनाई और यह वही नहीं किया जो मुझे चाहिए था तो मैं इसे संशोधित कर सकता था क्योंकि यह सिर्फ एक स्थानीय फ़ाइल थी।

mrdoob 12 अक्तू॰ 2020

❤7 👎1

इस तरह मैं अपनी परियोजनाओं को स्थापित करता था:

<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>

पहले जितना सुंदर नहीं था, लेकिन आपके लिए आयात निर्भरता/आदेश का ख्याल रखता है और बंडलर की आवश्यकता नहीं होती है।

फिर भी यह अभी भी उन लोगों के लिए काम करता है जो बंडल आधारित विकास करते हैं। वास्तव में, यह उनके लिए इसे बेहतर बनाता है क्योंकि ऐडऑन अब ../../build/three.module.js के बजाय ../../build/three.module.js three से आयात करते हैं।

mrdoob 12 अक्तू॰ 2020

👍4 👎1

और बात वास्तव में काम कर गई...

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

शायद स्पर्शरेखा लेकिन यह लोगों को सूचित करने लायक हो सकता है कि उनके पास पृष्ठ में शामिल तीन.जेएस की दो प्रतियां कंसोल में एक चेतावनी के माध्यम से शामिल हैं (भले ही वे एक ही संस्करण हों) जो तब तक समस्याएं पैदा कर सकती हैं जब तक कि उन्हें मिश्रण न करने के लिए ध्यान नहीं दिया जाता है। ~ मेरा मानना है कि रिएक्ट इसी तरह के कारणों से करता है ~ रिएक्ट वास्तव में इसे एक त्रुटि के संभावित स्रोत के रूप में इंगित कर सकता है। यह कम से कम लोगों को सीखने के दौरान इन तौर-तरीकों को मिलाने से दूर करने में मदद कर सकता है।

मैं @ बग-रीपर के समान निष्कर्ष पर पहुंचा। आज मैं एक ऐसी स्क्रिप्ट बनाने पर एक नज़र डाल रहा हूं जो उदाहरणों/जेएसएम फाइलों से उदाहरण/जेएस बनाता है।

यदि यह नई योजना है तो मुझे #15526/#15543 (जो अब परियोजना से हटा दी गई है) को पुनर्जीवित करने में मदद करने में प्रसन्नता होगी, जो प्रत्येक मॉड्यूल फ़ाइल को ES6 में बनाता है। यह देखते हुए कि कुछ उदाहरण बहुत सारी फाइलों में फैले हुए हैं (उदाहरण के लिए शेडर नोड्स) और हम कुछ मॉड्यूल को कई फाइलों में विभाजित करने में रुचि ले सकते हैं, यह शायद उन फाइलों की एक स्पष्ट सूची लेने के लिए रोलअप स्क्रिप्ट को अपग्रेड करने के लायक है जिन्हें हम कनवर्ट करना चाहते हैं। और आउटपुट। हमें उन फ़ाइलों के बीच स्वचालित रूप से निर्भरताएँ बनाने में सक्षम होना चाहिए जो आउटपुट हैं, साथ ही।

gkjohnson 12 अक्तू॰ 2020

फ़ाइलों की प्रतिलिपि न बनाने पर हम एक बड़ी चीज़ खो देते हैं, उन्हें संपादित करने में सक्षम होना

मैं सहमत हूं, हालांकि अगर हम सभी कक्षाओं में जा सकते हैं तो मुझे उम्मीद है कि कुछ ऐसा होगा:

import orbitalcontrols from  orbitalcontrolsURL

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

और फिर बाद में

let controls = new myorbitalcontrols

DefinitelyMaybe 14 अक्तू॰ 2020

👍2

फ़ाइलों की प्रतिलिपि न बनाने पर हम एक बड़ी चीज़ खो देते हैं, उन्हें संपादित करने में सक्षम होना
मैं सहमत हूं, हालांकि अगर हम सभी कक्षाओं में जा सकते हैं तो मुझे उम्मीद है कि कुछ ऐसा होगा:
ऑर्बिटलकंट्रोल से आयात करेंऑर्बिटलकंट्रोलURL
कक्षा mycontrols कक्षीय नियंत्रणों का विस्तार करते हैं {
// वे संपादन करें जिनकी मुझे परवाह है
}
और फिर बाद में
नियंत्रण दें = नया myorbitalcontrols

आप इसे पहले से ही कर सकते हैं ... भले ही माता-पिता "वर्ग" सरल जेएस फ़ंक्शन हो!

कोड वास्तव में काम कर रहा है (डीबगर त्वरित परीक्षण में):

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 )

})()

devingfx 14 अक्तू॰ 2020

उस aynom फ़ंक्शन से अलग और async/प्रतीक्षा वादों के बारे में चिंता करना, अच्छा

DefinitelyMaybe 14 अक्तू॰ 2020

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

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

उदाहरण के लिए, OrbitControls के लिए सबसे आम अनुरोधित परिवर्तन पैन को सीमित करना है । यह आसानी से पूरा किया जाता है जैसा कि उस धागे से @ Mugen87 की पहेली में दिखाया गया है।

संक्षेप में, आप minPan और maxPan वैक्टर जोड़ते हैं और $ controls.update विधि में controls.target क्लैंप करते हैं।

मुझे 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 15 अक्तू॰ 2020

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

DefinitelyMaybe 15 अक्तू॰ 2020

👍1

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

सावधान, यह एक विरासत बनाम रचना तर्क की ओर बारीकी से चल रहा है।

आदर्श रूप से एक पुस्तकालय को किसी भी पैटर्न का प्रचार नहीं करना चाहिए। यह इसकी विशेषताओं को बढ़ावा देना चाहिए और यह आपकी समस्याओं को हल करने का लक्ष्य कैसे रखता है।

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

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

आप अभी भी विंडोज 10 में डॉस गेम्स चला सकते हैं।

gigablox 15 अक्तू॰ 2020

👍5 😕1 👎1

विरासत बनाम रचना तर्क

कृपया कोई। इस 'तर्क' का समाधान नौकरी के लिए सर्वोत्तम उपकरण का उपयोग करना है। विरासत, संरचना, कार्यात्मक, परीक्षण संचालित ... के लिए एक जगह है आप इसे नाम दें।

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

प्रचार का मतलब यह नहीं है कि कोई अलग शैली का उपयोग नहीं कर सकता है।

जितना संभव हो उतना पिछड़ा संगतता

हां और ना।

इसे इसकी विशेषताओं को बढ़ावा देना चाहिए और इसका उद्देश्य आपकी समस्याओं को कैसे हल करना है

शायद इसलिए कि हम स्पष्ट हैं, आपके लिए क्या समस्या/सुविधा निर्धारित है?

DefinitelyMaybe 16 अक्तू॰ 2020

यह एक डेवलपर्स वर्कफ़्लो, स्टैक, बिल्ड सिस्टम, केस का उपयोग नहीं करना चाहिए

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

तब एकमात्र स्थिरांक सॉफ्टवेयर होगा जो रास्ते में कई उपयोग के मामलों के लिए बहुत अच्छा समर्थन प्रदान करता है

परिवर्तन ही स्थायी है। डेवलपर्स उस टूल का उपयोग करते हैं जो उन्हें पसंद है और कभी-कभी हम अन्य चीजों को भी छोड़ देते हैं।

स्वगत कथन के रूप में:

इसे इसकी विशेषताओं को बढ़ावा देना चाहिए और इसका उद्देश्य आपकी समस्याओं को कैसे हल करना है

जो पहले आया था? सुविधा, पैटर्न या समस्या?
निश्चित रूप से पैटर्न ने समस्या को हल करने में मदद की और फिर एक विशेषता बन गई
...या यह वह विशेषता थी जिसने समस्या पैदा की और हमें इसे हल करने के लिए एक पैटर्न मिला?

DefinitelyMaybe 16 अक्तू॰ 2020

जो पहले आया था? सुविधा, पैटर्न या समस्या?

पहले कौन आया? मुर्गी या अंडा?
कुछ लोग मुर्गा कहते हैं ...

RemusMar 17 अक्तू॰ 2020

चारों ओर शानदार चर्चा, सभी इनपुट के लिए सभी को धन्यवाद।

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

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

// 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 फ़ाइल में परिवर्तित करती है जिसमें तीन निर्दिष्ट होते हैं। उपयुक्त कंस्ट्रक्टर को ऑरिबिट कंट्रोल करता है। यह काम किया, जो अच्छा है :)! इसने थ्री.जेएस की 40k लाइनों को आउटपुट फाइल में भी बंडल किया, इतना अच्छा हाहा नहीं। मैं ऑर्बिटकंट्रोल कंस्ट्रक्टर को तीन पर ले जाने में मदद करने के लिए OC नामक एक मध्यस्थ वैश्विक संस्करण घोषित करके वैश्विक चर स्थान को आलसी रूप से प्रदूषित कर रहा हूं।

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

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

Bug-Reaper 17 अक्तू॰ 2020

👍2

यहाँ इस पर मेरी राय है:
https://github.com/mrdoob/three.js/pull/20529

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

किसी भी अनुभवी RegExp विज़ार्ड से मदद का उपयोग कर सकते हैं :) कुछ किनारे के मामलों को कम करने के लिए आप पीआर में और अधिक पढ़ सकते हैं।

gigablox 18 अक्तू॰ 2020

👍3 ❤2

Chrome का आयात मानचित्र शिप करने का इरादा:
https://groups.google.com/a/chromium.org/g/blink-dev/c/rVX_dJAJ-eI

mrdoob 18 दिस॰ 2020

🎉1

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स