खोज…
परिचय
Meteor 1.3 के जारी होने से पहले, Meteor.js की फाइल निर्भरता और वैश्विक चर की हैंडलिंग से Meteor Developers निराश थे। जवाब में, परियोजना निर्भरता प्रणाली को अधिक सुव्यवस्थित बनाने के लिए, उल्का ने परियोजना संरचनाओं के लिए नए मानक निर्धारित किए। यह विषय मानकीकृत परियोजना संरचना और इसके पीछे के सिद्धांतों की व्याख्या करता है।
टिप्पणियों
ग्राहक
क्लाइंट निर्देशिका में सभी कोड केवल क्लाइंट-साइड या वेब ब्राउज़र में चलाया जाता है।
क्लाइंट / अनुकूलता
संगतता निर्देशिका में विरासत या 3 पार्टी कोड शामिल हैं, जैसे कि jQuery लाइब्रेरी इत्यादि।
lib
आपके Meteor प्रोजेक्ट में अन्य निर्देशिकाओं से पहले काम करने वाली निर्देशिका को लोड किया जाता है, और सर्वर और क्लाइंट दोनों पर लोड किया जाता है। यह डेटा मॉडल, आइसोमॉर्फिक लाइब्रेरी और व्यावसायिक तर्क को परिभाषित करने के लिए पसंदीदा स्थान है।
आयात
आयात निर्देशिका सर्वर पर एक निर्देशिका है जो सर्वर और क्लाइंट दोनों के लिए उपलब्ध है, लेकिन केवल क्लाइंट बंडल क्लाइंट को शिप करने से पहले।
संकुल
संकुल निर्देशिका वह है जहाँ स्थानीय विकास के दौरान कस्टम पैकेज संग्रहीत किए जाते हैं। मानक कमांड meteor add package:name का उपयोग करते समय meteor add package:name लिए meteor add package:name , उल्का इस निर्देशिका में पहली बार देखेगा यदि किसी स्थानीय पैकेज में इसके package.js नाम में संबंधित विवरण नाम हो package.js फाइल। यदि नहीं, तो यह हमेशा की तरह वायुमंडल को प्रदूषित करेगा।
निजी
निजी निर्देशिका में स्थिर फाइलें होती हैं जो केवल वेब सर्वर पर उपलब्ध होनी चाहिए।
जनता
सार्वजनिक निर्देशिका में स्थिर फ़ाइलें हैं जो केवल एप्लिकेशन क्लाइंट पर उपलब्ध हैं। इसमें ब्रांडिंग एसेट्स आदि शामिल हो सकते हैं।
सर्वर
सर्वर निर्देशिका में सर्वर-साइड संपत्ति होती है। इसमें प्रमाणीकरण तर्क, विधियाँ और अन्य कोड शामिल हो सकते हैं जिन्हें सुरक्षा पर विचार करने की आवश्यकता हो सकती है।
परीक्षण
जब आपके एप्लिकेशन को बंडल और तैनात किया जाता है, तो परीक्षण निर्देशिका डिफ़ॉल्ट रूप से छोड़ी जाती है।
जैसा कि रिचर्ड सिल्वरटन ने सुझाव दिया था कि न केवल उल्का परियोजना निर्देशिका को संस्करण नियंत्रण में रखा जाना चाहिए, बल्कि इसकी मूल निर्देशिका भी।
इस तरह आप इससे निपटने के लिए उल्का के बिना संस्करण नियंत्रण के तहत फाइलें रख सकते हैं।
क्लासिक निर्देशिका संरचना
आपके ऐप्स को संरचित करते समय आपको सबसे पहले यह जानना होगा कि उल्का उपकरण में कुछ निर्देशिकाएं हैं जो विशिष्ट तर्क के साथ हार्ड-कोडेड हैं। एक बहुत ही बुनियादी स्तर पर, निम्नलिखित निर्देशिकाओं को उल्का बंडल में "बेक किया गया" है।
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports/ # for lazy loading feature
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
संदर्भ पृष्ठ: उल्का गाइड> विशेष निर्देशिका
पैकेज-केवल निर्देशिका संरचना
बहुत से लोग खुद को अंततः कई अनुप्रयोगों का समर्थन करते हैं, और ऐप्स के बीच कोड साझा करने की इच्छा रखते हैं। यह माइक्रोसैस आर्किटेक्चर, और ऑल-पैकेज ऐप्स की अवधारणा की ओर जाता है। अनिवार्य रूप से, संपूर्ण क्लासिक डायरेक्टरी संरचना से कोड को पैकेज में दर्शाया गया है।
भले ही पैकेजों में निर्देशिकाओं के लिए कोई हार्ड-कोडेड तर्क नहीं है, हम पाते हैं कि संकुल बनाते समय क्लासिक निर्देशिका संरचना का उपयोग करना एक अच्छा अभ्यास है। यह एक प्राकृतिक परावर्तक पथ बनाता है जैसा कि एप्लिकेशन में सुविधाओं को प्रोटोटाइप किया जाता है, और फिर प्रकाशित और साझा किए जाने वाले पैकेजों में निकाला जाता है। निर्देशिका नाम साझा किए जाते हैं, इसलिए टीम के सदस्यों के बीच भ्रम कम होता है।
client/ # client application code
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
server/ # server code
आयात / मॉड्यूल निर्देशिका संरचना
के लिए समर्थन के साथ उल्का जहाज के नवीनतम संस्करणों की ecmascript , ES6 या ES2015 उर्फ। पैकेज के बजाय, जावास्क्रिप्ट अब import विवरण और मॉड्यूल का समर्थन करता है, जो पैकेज-केवल अनुप्रयोगों की आवश्यकता को प्रतिस्थापित करता है। नवीनतम निर्देशिका संरचना पैकेज-केवल संरचना के समान है, लेकिन /packages बजाय /imports निर्देशिका का उपयोग करती /packages ।
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
मिश्रित-मोड निर्देशिका संरचना
और, ज़ाहिर है, आप इन दृष्टिकोणों को मिला सकते हैं, और अपने आवेदन विशिष्ट कोड के साथ दोनों पैकेज और आयात का उपयोग कर सकते हैं। मिक्स-मोड संरचना तीन स्थितियों में सबसे आम है: एक फ्रैंक-ऐप, जो किसी भी समग्र रणनीति के बिना यहां-और-वहां से थोड़ा खींचने का एक प्रकार है; एक ऐसा ऐप जिसे क्लासिक या पैकेज-ओनली स्ट्रक्चर से इंपोर्ट्स / मोड्यूल स्ट्रक्चर में सक्रिय रूप से रिफ्लेक्ट किया जा रहा है।
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
डायरेक्टरी लोड ऑर्डर
HTML टेम्प्लेट फाइलें हमेशा सब कुछ से पहले लोड की जाती हैं
मुख्य के साथ शुरू होने वाली फाइलें । पिछले लोड किए गए हैं
किसी भी परिवाद / निर्देशिका के अंदर की फाइलें अगले लोड की जाती हैं
गहरे रास्तों वाली फाइलें आगे लोड की जाती हैं
फ़ाइलों को पूरे पथ के वर्णानुक्रम में लोड किया जाता है
संदर्भ पृष्ठ: उल्का गाइड> अनुप्रयोग संरचना> डिफ़ॉल्ट फ़ाइल लोड क्रम
