मैं टाइपस्क्रिप्ट बाहरी मॉड्यूल के साथ नामस्थान का उपयोग कैसे करूं?

Question

मेरे पास कुछ कोड हैं:

baseTypes.ts

export namespace Living.Things {
  export class Animal {
    move() { /* ... */ }
  }
  export class Plant {
    photosynthesize() { /* ... */ }
  }
}

dog.ts

import b = require('./baseTypes');

export namespace Living.Things {
  // Error, can't find name 'Animal', ??
  export class Dog extends Animal {
    woof() { }
  }
}

tree.ts

// Error, can't use the same name twice, ??
import b = require('./baseTypes');
import b = require('./dogs');

namespace Living.Things {
  // Why do I have to write b.Living.Things.Plant instead of b.Plant??
  class Tree extends b.Living.Things.Plant {

  }
}

यह सब बहुत भ्रामक है। मैं बाहरी मॉड्यूल का एक समूह बनाना चाहता हूं जो सभी समान नामस्थान पर योगदान करते हैं Living.Things। ऐसा नहीं है कि यह सब पर काम नहीं करता है लगता है - मैं नहीं देख सकते हैं Animalमें dogs.ts। मुझे पूरा नाम स्थान का नाम लिखना b.Living.Things.Plantहै tree.ts। यह फ़ाइल में समान नामस्थान में कई ऑब्जेक्ट्स को संयोजित करने के लिए काम नहीं करता है। मैं यह कैसे करु?

Answer 1

कैंडी कप सादृश्य

संस्करण 1: हर कैंडी के लिए एक कप

मान लीजिए कि आपने कुछ कोड इस तरह लिखे हैं:

Mod1.ts

export namespace A {
    export class Twix { ... }
}

Mod2.ts

export namespace A {
    export class PeanutButterCup { ... }
}

Mod3.ts

export namespace A {
     export class KitKat { ... }
}

आपने यह सेटअप बनाया है:

प्रत्येक मॉड्यूल (कागज की शीट) को अपने स्वयं के कप का नाम दिया जाता है A। यह बेकार है - आप वास्तव में यहां अपनी कैंडी का आयोजन नहीं कर रहे हैं, आप सिर्फ एक अतिरिक्त कदम जोड़ रहे हैं (इसे कप से बाहर ले जा रहे हैं) और व्यवहार के बीच।

---

संस्करण 2: वैश्विक दायरे में एक कप

यदि आप मॉड्यूल का उपयोग नहीं कर रहे थे, तो आप इस तरह कोड लिख सकते हैं ( exportघोषणाओं की कमी पर ध्यान दें ):

global1.ts

namespace A {
    export class Twix { ... }
}

global2.ts

namespace A {
    export class PeanutButterCup { ... }
}

global3.ts

namespace A {
     export class KitKat { ... }
}

यह कोड Aवैश्विक दायरे में एक विलय नाम स्थान बनाता है :

यह सेटअप उपयोगी है, लेकिन मॉड्यूल के मामले में लागू नहीं होता है (क्योंकि मॉड्यूल वैश्विक दायरे को प्रदूषित नहीं करते हैं)।

---

संस्करण 3: कपलेस होकर जाना

मूल उदाहरण के लिए वापस जा, कप A, Aऔर Aआप किसी भी पक्ष में नहीं कर रहे हैं। इसके बजाय, आप इस रूप में कोड लिख सकते हैं:

Mod1.ts

export class Twix { ... }

Mod2.ts

export class PeanutButterCup { ... }

Mod3.ts

export class KitKat { ... }

एक चित्र बनाने के लिए जो इस तरह दिखता है:

काफी बेहतर!

अब, यदि आप अभी भी इस बारे में सोच रहे हैं कि आप वास्तव में अपने मॉड्यूल के साथ नाम स्थान का उपयोग कैसे करना चाहते हैं, तो पढ़ें ...

---

ये अवधारणाएँ नहीं हैं जिन्हें आप खोज रहे हैं

हमें यह जानने की आवश्यकता है कि नाम स्थान पहले स्थान पर क्यों हैं और यह जाँच करें कि क्या वे कारण बाहरी मॉड्यूल के लिए समझ में आते हैं।

संगठन : नाम स्थान तार्किक रूप से संबंधित वस्तुओं और प्रकारों को एक साथ समूहीकृत करने के लिए आसान हैं। उदाहरण के लिए, C # में, आप सभी संग्रह प्रकार खोजने जा रहे हैं System.Collections। हमारे प्रकारों को पदानुक्रमित नामस्थान में व्यवस्थित करके, हम उन प्रकार के उपयोगकर्ताओं के लिए एक अच्छा "खोज" अनुभव प्रदान करते हैं।

नाम संघर्ष : नामकरण टकराव से बचने के लिए नाम स्थान महत्वपूर्ण हैं। उदाहरण के लिए, आपके पास My.Application.Customer.AddFormऔर My.Application.Order.AddForm- एक ही नाम के दो प्रकार हो सकते हैं , लेकिन एक अलग नामस्थान। ऐसी भाषा में जहां सभी पहचानकर्ता एक ही मूल दायरे में मौजूद हैं और सभी विधानसभाएं सभी प्रकारों को लोड करती हैं, सब कुछ एक नाम स्थान में होना महत्वपूर्ण है।

क्या उन कारणों से बाहरी मॉड्यूल में कोई फर्क पड़ता है?

संगठन : बाहरी मॉड्यूल पहले से ही एक फाइल सिस्टम में मौजूद हैं, जरूरी है। हमें उन्हें पथ और फ़ाइल नाम से हल करना होगा, इसलिए हमारे लिए उपयोग करने के लिए एक तार्किक संगठन योजना है। हमारे पास /collections/generic/इसमें एक listमॉड्यूल वाला एक फ़ोल्डर हो सकता है ।

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

---

यहां तक ​​कि अगर आपको विश्वास नहीं है कि उन कारणों को पर्याप्त रूप से संबोधित किया जाता है कि मॉड्यूल कैसे काम करते हैं, तो बाहरी मॉड्यूल में नाम स्थान का उपयोग करने की कोशिश करने का "समाधान" भी काम नहीं करता है।

बक्से में बक्से में बक्से

एक कहानी:

आपका दोस्त बॉब आपको कॉल करता है। "मेरे घर में एक महान संगठन योजना है", वह कहते हैं, "इसकी जांच करें!"। नीट, चलो देखते हैं कि बॉब क्या लेकर आया है।

आप रसोई में शुरू करते हैं और पेंट्री खोलते हैं। 60 अलग-अलग बक्से हैं, प्रत्येक "पेंट्री" लेबल हैं। आप यादृच्छिक पर एक बॉक्स चुनें और इसे खोलें। अंदर एक एकल बॉक्स "लेबल" है। आप "अनाज" बॉक्स खोलते हैं और "पास्ता" नामक एक एकल बॉक्स पाते हैं। आप "पास्ता" बॉक्स खोलें और "पेनी" नामक एक एकल बॉक्स ढूंढें। आप इस बॉक्स को खोलते हैं और पाते हैं, जैसा कि आप उम्मीद करते हैं, पेनी पास्ता का एक बैग।

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

"यह बहुत अच्छा है!" बॉब कहते हैं। "सब कुछ एक नाम स्थान में है!"।

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

"आप नहीं समझते हैं - मुझे यह सुनिश्चित करने की ज़रूरत है कि कोई और ऐसा कुछ नहीं डालता है जो 'पेंट्री' नामस्थान से संबंधित नहीं है। और मैंने अपने सभी पास्ता को Pantry.Grains.Pastaनामस्थान में सुरक्षित रूप से व्यवस्थित किया है ताकि मैं इसे आसानी से पा सकूं"

बॉब बहुत उलझा हुआ इंसान है।

मॉड्यूल उनके अपने बॉक्स हैं

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

बॉक्स एनालॉग के साथ जा रहे हैं, मुख्य अवलोकन यह है कि बाहरी मॉड्यूल अपने स्वयं के बॉक्स हैं । यह बहुत अधिक कार्यक्षमता के साथ एक बहुत ही जटिल आइटम हो सकता है, लेकिन किसी भी बाहरी मॉड्यूल का अपना बॉक्स है।

---

बाहरी मॉड्यूल के लिए मार्गदर्शन

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

यथासंभव शीर्ष स्तर के करीब निर्यात करें

• यदि आप केवल एकल वर्ग या फ़ंक्शन का उपयोग कर रहे हैं, तो उपयोग करें export default:

MyClass.ts

export default class SomeType {
  constructor() { ... }
}

MyFunc.ts

function getThing() { return 'thing'; }
export default getThing;

सेवन

import t from './MyClass';
import f from './MyFunc';
var x = new t();
console.log(f());

यह उपभोक्ताओं के लिए इष्टतम है। वे आपके प्रकार का नाम दे सकते हैं जो वे चाहते हैं ( tइस मामले में) और आपकी वस्तुओं को खोजने के लिए किसी भी बाहरी डॉटिंग को करने की ज़रूरत नहीं है।

• यदि आप कई वस्तुओं का निर्यात कर रहे हैं, तो उन सभी को शीर्ष-स्तर पर रखें:

MyThings.ts

export class SomeType { ... }
export function someFunc() { ... }

सेवन

import * as m from './MyThings';
var x = new m.SomeType();
var y = m.someFunc();

• यदि आप बड़ी संख्या में चीजों का निर्यात कर रहे हैं, तो केवल आपको module/ namespaceकीवर्ड का उपयोग करना चाहिए :

MyLargeModule.ts

export namespace Animals {
  export class Dog { ... }
  export class Cat { ... }
}
export namespace Plants {
  export class Tree { ... }
}

सेवन

import { Animals, Plants} from './MyLargeModule';
var x = new Animals.Dog();

---

लाल झंडा

मॉड्यूल संरचना के लिए निम्नलिखित सभी लाल झंडे हैं। यदि आप इनमें से कोई भी अपनी फ़ाइलों पर लागू करते हैं, तो अपने बाहरी मॉड्यूल को नामांकित करने का प्रयास नहीं कर रहे हैं:

• एक फ़ाइल जिसकी केवल शीर्ष-स्तरीय घोषणा है export module Foo { ... }( Fooएक स्तर पर 'सब कुछ हटा दें और हटा दें ')
• एक फ़ाइल जिसमें एक एकल export classया export functionवह नहीं हैexport default
• कई फाइलें जो export module Foo {शीर्ष-स्तर पर समान हैं (ऐसा मत सोचो कि ये एक में संयोजन करने जा रहे हैं Foo!)

Comments

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

— Albinofrenchy

चाहे कोई कितना भी चाहे, यह अभी भी संभव नहीं है ।

— रयान कैवानुआघ

मुझे समझ नहीं आ रहा है, हम अब पास्कल नहीं लिख रहे हैं। फ़ाइल सिस्टम का उपयोग करने का तरीका कब से आयोजित किया जा रहा है?

— डेविड

आपके पास "रैपर" मॉड्यूल हो सकता है जो आपके पुस्तकालय के उपभोक्ताओं के लिए ब्याज की हर चीज का आयात और पुन: निर्यात करता है। लेकिन फिर से, "नेमस्पेस" का उपयोग करते हुए, किसी भी कोड का उपयोग करने वाले किसी अन्य व्यक्ति के लिए अप्रत्यक्ष स्तर को मजबूर करने के अलावा कोई भी मूल्य प्रदान करने वाला नहीं है।

— रयान कैवानुघ

शानदार लेखन, धन्यवाद। मुझे ऐसा लगता है कि आपको www.typescriptlang.org/docs/handbook/namespaces.html से इसे लिंक करना चाहिए। मैंने पढ़ा होगा कि typecriptlang.org लिंक 3 या 4 बार और सी # देव के रूप में, मैं स्वाभाविक रूप से सब कुछ एक नेमस्पेस में रखना चाहता हूं। मैंने कुछ सुझाव यह कहते हुए पढ़े हैं, लेकिन इस बारे में कोई स्पष्टीकरण नहीं है कि क्यों और कुछ भी निश्चित नहीं है (और अच्छी तरह से वर्णित)। टाइपस्क्रिप्ट डॉक्स में प्लस कुछ भी इस AFAIK का उल्लेख नहीं करता है

— एडम प्लोचर

Answer 2

रयान के जवाब में कुछ भी गलत नहीं है, लेकिन जो लोग यहां आए थे, वे ईएस 6 नामस्थानों का सही ढंग से उपयोग करते हुए एक-वर्ग-प्रति-फ़ाइल संरचना को बनाए रखने के लिए देख रहे थे, कृपया Microsoft से इस सहायक संसाधन को देखें ।

एक बात है कि दस्तावेज़ को पढ़ने के बाद मेरे लिए स्पष्ट नहीं है कि है: पूरे आयात करने का तरीका एक साथ (विलय) मॉड्यूल एकल import ।

संपादित चक्कर क्या यह उत्तर अद्यतन करने के लिए वापस। नामस्थान के कुछ दृष्टिकोण टीएस में उभरते हैं।

एक फ़ाइल में सभी मॉड्यूल कक्षाएं।

export namespace Shapes {
    export class Triangle {}
    export class Square {}      
}

नाम स्थान, और पुन: असाइन में फ़ाइलें आयात करें

import { Triangle as _Triangle } from './triangle';
import { Square as _Square } from './square';

export namespace Shapes {
  export const Triangle = _Triangle;
  export const Square = _Square;
}

बैरल

// ./shapes/index.ts
export { Triangle } from './triangle';
export { Square } from './square';

// in importing file:
import * as Shapes from './shapes/index.ts';
// by node module convention, you can ignore '/index.ts':
import * as Shapes from './shapes';
let myTriangle = new Shapes.Triangle();

एक अंतिम विचार। आप प्रत्येक फ़ाइल को नाम स्थान दे सकते हैं

// triangle.ts
export namespace Shapes {
    export class Triangle {}
}

// square.ts
export namespace Shapes {
    export class Square {}
}

लेकिन जैसा कि एक ही नाम स्थान से दो वर्ग आयात करते हैं, TS शिकायत करेगा कि एक डुप्लिकेट पहचानकर्ता है। इस समय के रूप में एकमात्र समाधान तो नाम स्थान का नाम है।

import { Shapes } from './square';
import { Shapes as _Shapes } from './triangle';

// ugh
let myTriangle = new _Shapes.Shapes.Triangle();

यह अलियासिंग बिल्कुल घिनौना है, इसलिए ऐसा न करें। आप ऊपर दिए गए दृष्टिकोण के साथ बेहतर हैं। व्यक्तिगत रूप से, मैं 'बैरल' पसंद करता हूं।

Comments

"ईएस 6 नामस्थान" क्या हैं?

— अलुआन हदद

@AluanHaddad जब es2015 + आयात कर रहे हैं, तो आयात की गई चीजें या तो डिफ़ॉल्ट हैं, विनाशकारी हैं या नाम स्थान पर हैं। const fs = require('fs'), fsनाम स्थान है। import * as moment from 'moment', momentनाम स्थान है। यह ऑन्कोलॉजी है, विनिर्देश नहीं है।

— जेफटॉपिया

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

— अलुआन हदाद

मैं अनुसरण नहीं करता, क्योंकि आयातित चीज़ कॉल करने योग्य है या नहीं, यह अभी भी एक नाम स्थान के रूप में तार्किक रूप से कार्य करता है । मुझे नहीं लगता कि कैवेट ऊपर मेरे उत्तर के लिए सामग्री है।

— जेफटॉपिया

Answer 3

फ़ोल्डर द्वारा व्यवस्थित करने का प्रयास करें:

baseTypes.ts

export class Animal {
    move() { /* ... */ }
}

export class Plant {
    photosynthesize() { /* ... */ }
}

dog.ts

import b = require('./baseTypes');

export class Dog extends b.Animal {
    woof() { }
}   

tree.ts

import b = require('./baseTypes');

class Tree extends b.Plant {
}

LivingThings.ts

import dog = require('./dog')
import tree = require('./tree')

export = {
    dog: dog,
    tree: tree
}

main.ts

import LivingThings = require('./LivingThings');
console.log(LivingThings.Tree)
console.log(LivingThings.Dog)

विचार यह है कि आपके मॉड्यूल को खुद की परवाह नहीं करनी चाहिए / जानते हैं कि वे एक नेमस्पेस में भाग ले रहे हैं, लेकिन यह आपके एपीआई को एक कॉम्पैक्ट, समझदार तरीके से उपभोक्ता के लिए उजागर करता है, जो इस बात के लिए अज्ञेय है कि आप प्रोजेक्ट के लिए किस प्रकार के मॉड्यूल सिस्टम का उपयोग कर रहे हैं।

Comments

LivingThings.dog.Dog आपके यहाँ क्या है।

— कोरी एलिक्स

मैं पत्र मामले को सुसंगत रखने की सलाह देता हूं, यदि आप "ट्री" निर्यात करते हैं, तो "ट्री" आयात करें, न कि "ट्री"।

— डेमक्स

इसके अलावा, tree.tsजब आप इसका कोई निर्यात सदस्य नहीं है , तो आप कुछ भी कैसे आयात कर सकते हैं ?

— डेमक्स

मैन टीएस सुनिश्चित है कि कुछ मूर्खतापूर्ण पुराने वाक्यविन्यास हैं, जैसे importऔर requireएक बयान में एक साथ।

— एंडी

Answer 4

अल्बिनोफ्रेन्सी उत्तर के छोटे आवेग:

base.ts

export class Animal {
move() { /* ... */ }
}

export class Plant {
  photosynthesize() { /* ... */ }
}

dog.ts

import * as b from './base';

export class Dog extends b.Animal {
   woof() { }
} 

things.ts

import { Dog } from './dog'

namespace things {
  export const dog = Dog;
}

export = things;

main.ts

import * as things from './things';

console.log(things.dog);

Comments

इसके लिए धन्यवाद! केवल यह कहना चाहता था कि मौजूदा उत्तर में परिवर्तन को अधिमानतः नए उत्तर के रूप में पोस्ट नहीं किया जाना चाहिए: उन्हें या तो मौजूदा उत्तर के लिए एक टिप्पणी के रूप में जोड़ा जाना चाहिए, या (बेहतर) उस उत्तर को संपादित करके सुझाव दिया जाना चाहिए जिसे आप चाहते हैं सुधारें।

— a3nm

Answer 5

ओपी मैं तुम्हारे साथ हूँ यार। फिर भी, 300+ अप वोट के साथ उस उत्तर में कुछ भी गलत नहीं है, लेकिन मेरी राय है:

1. व्यक्तिगत रूप से अपनी मधुर गर्म फाइलों में कक्षाएं लगाने में क्या गलत है? मेरा मतलब है कि इससे चीजें बहुत बेहतर लगेंगी? (या किसी को सभी मॉडलों के लिए 1000 लाइन फाइल की तरह)

2. इसलिए, अगर पहले एक हासिल किया जाएगा, तो हमें आयात आयात आयात करना होगा ... आदमी, सरसरी तौर पर, प्रत्येक मॉडल फ़ाइल में आयात करें, एक मॉडल फ़ाइल, .d.ts फ़ाइल, क्यों बहुत सारे हैं * वहाँ है? यह सिर्फ सरल, सुव्यवस्थित होना चाहिए, और यह बात है। मुझे वहां आयात की आवश्यकता क्यों है? क्यों? C # को एक कारण से नाम स्थान मिला।

3. और तब तक, आप सचमुच पहचानकर्ता के रूप में "फ़ाइलनाम" का उपयोग कर रहे हैं। पहचानकर्ता के रूप में ... अब इसके 2017 पर आते हैं और हम अभी भी ऐसा करते हैं? इमा मंगल पर वापस जाती हैं और अगले 1000 वर्षों तक सोती हैं।

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

export namespace(or module) boxInBox {} .

उन्हें लपेटो ताकि वे एक ही नाम के साथ अन्य वर्गों का उपयोग करने की कोशिश न करें, जब वे बस उन के शीर्ष पर कक्षा के बैठने का संदर्भ प्राप्त करने की कोशिश कर रहे हों।

Answer 6

इस विषय ध्वनि के इर्द-गिर्द मेरे द्वारा देखे गए कई प्रश्न / टिप्पणियाँ जैसे कि वह व्यक्ति उपयोग कर रहा है Namespaceजहाँ उनका अर्थ है 'मॉड्यूल उपनाम'। जैसा कि रयान कैवानुआघ ने अपनी एक टिप्पणी में उल्लेख किया है कि आप एक 'रैपर' मॉड्यूल कई मॉड्यूलों को फिर से निर्यात कर सकते हैं।

यदि आप वास्तव में एक ही मॉड्यूल नाम / उपनाम से यह सब आयात करना चाहते हैं, तो अपने पथ के मानचित्रण के साथ एक आवरण मॉड्यूल को संयोजित करें tsconfig.json।

उदाहरण:

./path/to/CompanyName.Products/Foo.ts

export class Foo {
    ...
}

./path/to/CompanyName.Products/Bar.ts

export class Bar {
    ...
}

./path/to/CompanyName.Products/index.ts

export { Foo } from './Foo';
export { Bar } from './Bar';

tsconfig.json

{
    "compilerOptions": {
        ...
        paths: {
            ...
            "CompanyName.Products": ["./path/to/CompanyName.Products/index"],
            ...
        }
        ...
    }
    ...
}

main.ts

import { Foo, Bar } from 'CompanyName.Products'

नोट : आउटपुट .js फ़ाइलों में मॉड्यूल रिज़ॉल्यूशन को किसी भी तरह संभाला जाना होगा, जैसे कि इस https://github.com/tleunen/babel-plugin-module-resolver के साथ।

.babelrcउर्फ रिज़ॉल्यूशन को संभालने के लिए उदाहरण :

{
    "plugins": [
        [ "module-resolver", {
            "cwd": "babelrc",
            "alias": {
                "CompanyName.Products": "./path/to/typescript/build/output/CompanyName.Products/index.js"
            }
        }],
        ... other plugins ...
    ]
}

Answer 7

इस नाम स्थान मॉड्यूल का प्रयास करें

namespaceModuleFile.ts

export namespace Bookname{
export class Snows{
    name:any;
    constructor(bookname){
        console.log(bookname);
    }
}
export class Adventure{
    name:any;
    constructor(bookname){
        console.log(bookname);
    }
}
}





export namespace TreeList{
export class MangoTree{
    name:any;
    constructor(treeName){
        console.log(treeName);
    }
}
export class GuvavaTree{
    name:any;
    constructor(treeName){
        console.log(treeName);
    }
}
}

bookTreeCombine.ts

--- संकलन भाग ---

import {Bookname , TreeList} from './namespaceModule';
import b = require('./namespaceModule');
let BooknameLists = new Bookname.Adventure('Pirate treasure');
BooknameLists = new Bookname.Snows('ways to write a book'); 
const TreeLis = new TreeList.MangoTree('trees present in nature');
const TreeLists = new TreeList.GuvavaTree('trees are the celebraties');

Answer 8

dog.ts

import b = require('./baseTypes');

export module Living.Things {
    // Error, can't find name 'Animal', ??
    // Solved: can find, if properly referenced; exporting modules is useless, anyhow
    export class Dog extends b.Living.Things.Animal {
        public woof(): void {
            return;
        }
    }
}

tree.ts

// Error, can't use the same name twice, ??
// Solved: cannot declare let or const variable twice in same scope either: just use a different name
import b = require('./baseTypes');
import d = require('./dog');

module Living.Things {
    // Why do I have to write b.Living.Things.Plant instead of b.Plant??
    class Tree extends b.Living.Things.Plant {
    }
}

Answer 9

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

// index.ts
import * as greeter from './greeter';
import * as somethingElse from './somethingElse';

export {greeter, somethingElse};

// greeter/index.ts
export * from './greetings.js';
...

// greeter/greetings.ts
export const helloWorld = "Hello World";

फिर आप इसे इस तरह उपयोग करेंगे:

import { greeter } from 'your-package'; //Import it like normal, be it from an NPM module or from a directory.
// You can also use the following syntax, if you prefer:
import * as package from 'your-package';

console.log(greeter.helloWorld);

Comments

यह भ्रामक और बिल्कुल गलत है। यह नहीं है कि कैसे नामस्थान काम करते हैं। साथ ही यह ऑप्स प्रश्न का उत्तर नहीं देता है।

— एंड्रयूमैक्गन