Wie verwende ich Namespaces mit externen TypeScript-Modulen?

Candy Cup Analogie

Version 1: Eine Tasse für jede candy

Lassen Sie uns sagen Sie, dass Sie schrieb einige code wie folgt:

Mod1.ts

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

Mod2.ts

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

Mod3 ein;.ts

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

Die Sie erstellt haben und dieses setup:

Jedes Modul (Blatt Papier) wird seine eigene Tasse namens A. Das ist sinnlos - du bist nicht wirklich die Organisation Ihre Süßigkeit hier, du bist nur das hinzufügen einer zusätzlichen Schritt (Entnahme aus der Tasse) sich zwischen Sie und die leckereien.

---

Version 2: Eine Tasse, die im globalen Gültigkeitsbereich

Wenn du nicht mit Modulen, könnten Sie code schreiben (beachten Sie das fehlen von export Erklärungen):

global1.ts

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

global2.ts

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

global3.ts

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

Diese code erstellt eine zusammengeführte namespace A im globalen Gültigkeitsbereich:

Diese Einstellung ist sinnvoll, aber nicht in dem Fall, daß die Module (da-Module verschmutzen nicht die Umwelt im globalen Gültigkeitsbereich).

---

Version 3: cupless

Geht zurück auf das ursprüngliche Beispiel, die Tassen A, A, und A nicht tun Sie keinen gefallen. Stattdessen könnte man den code schreiben als:

Mod1.ts

export class Twix { ... }

Mod2.ts

export class PeanutButterCup { ... }

Mod3 ein;.ts

export class KitKat { ... }

erstellen ein Bild, das aussieht wie dieses:

Viel besser!

Nun, wenn Sie denken immer noch darüber, wie viel Sie wirklich verwenden wollen-namespace mit Ihren Modulen, Lesen Sie weiter...

---

Diese Sind nicht die Konzepte, die Sie Suchen

Wir müssen zurück zu den Ursprüngen, warum namespaces existieren, an Erster Stelle und prüfen, ob diese Gründe machen Sinn für externe Module.

Organisation: Namespaces sind praktisch für die Gruppierung von logisch zusammengehörigen Objekten und Typen. Zum Beispiel in C#, du wirst finden, alle Sammlungen in System.Collections. Durch die Organisation unserer Arten in hierarchische Namensräume, wir bieten einen guten "discovery" - Erfahrung für die Nutzer dieser Typen.

Namenskonflikte: Namespaces sind wichtig, um zu vermeiden Namenskonflikte. Zum Beispiel, haben Sie vielleicht My.Application.Customer.AddForm und My.Application.Order.AddForm -- zwei Typen mit dem gleichen Namen, aber einem unterschiedlichen namespace. In einer Sprache, wo alle Bezeichner existieren in der gleichen root-scope und alle Assemblys laden alle Typen, es ist wichtig zu haben alles in einem namespace.

Diese Gründe machen Sinn in externen Modulen?

Organisation: Externe Module sind bereits in einem Dateisystem, unbedingt. Wir haben Sie zu lösen, indem Sie den Pfad und den Dateinamen, so dass es eine logische Organisation Schema für uns zu nutzen. Wir haben eine /collections/generic/ Ordner mit einem list module.

Namenskonflikte: Dies gilt nicht an alle, die in externen Modulen. Innerhalb ein Modul, es gibt keinen plausiblen Grund zu haben, zwei Objekte mit dem gleichen Namen. Von der Konsum-Seite, die Verbraucher von einem bestimmten Modul wird um die Namen, die Sie verwenden, um beziehen sich auf das Modul, so dass unbeabsichtigte Kollisionen sind unmöglich.

---

Selbst wenn Sie nicht glauben, dass diese Gründe ausreichend angesprochen werden, wie Module funktionieren, die "Lösung" zu versuchen, die Verwendung von namespaces in externe Module gar nicht funktionieren.

Kisten in Kisten in Kisten

Geschichte:

Ihrem Freund Bob ruft Sie. "Ich habe eine tolle neue Organisation Schema in meinem Haus", sagt er, "kommen check it out!". Ordentlich, lasst uns sehen, was Bob hat mit zu kommen.

Starten Sie in die Küche und öffnen Sie die Speisekammer. Es sind über 60 verschiedene Felder, die jeweils mit "Speisekammer". Wählen Sie ein Feld nach dem Zufallsprinzip und öffnen Sie es. Im inneren ist ein single-Feld mit der Aufschrift "Getreide". Öffnen Sie die "Körner" klicken und finden Sie ein einzelnes Feld mit der Aufschrift "Pasta". Öffnen Sie die "Pasta" - box und finden Sie ein einzelnes Feld mit der Aufschrift "Penne". Sie öffnen diese Kiste und finden, als Sie erwarten, eine Tüte penne.

Etwas verwirrt, Sie abholen ein angrenzendes Feld, auch mit der Aufschrift "Speisekammer". Im inneren ist eine einzelne box, wieder mit der Aufschrift "Getreide". Öffnen Sie die "Körner" - box und, wieder finden Sie ein einzelnes Feld mit der Aufschrift "Pasta". Öffnen Sie die "Pasta" - box und finden Sie einen Karton, dieser ist beschriftet mit "Rigatoni". Sie öffnen diese Kiste und finde... eine Tüte rigatoni pasta.

"Es ist großartig!", sagt Bob. "Alles ist in einem namespace!".

"Aber Bob...", Antworten Sie. "Ihre Organisation Schema ist nutzlos. Sie haben zu öffnen, eine Reihe von Boxen zu bekommen, um etwas, und es ist nicht wirklich komfortabler, etwas zu finden, als wenn Sie hatte gerade alles in eine box statt drei. In der Tat, da Ihre Speisekammer ist bereits sortiert-Regal-Regal müssen Sie nicht die Boxen überhaupt. Warum nicht einfach setzen Sie die Nudeln auf dem Regal und es abholen, wenn Sie es brauchen?"

"Du verstehst das nicht-ich brauche, um sicherzustellen, dass niemand anders steckt etwas, das gehört nicht in die 'Speisekammer' - namespace. Und ich habe sicher organisiert alle meine Nudeln in Pantry.Grains.Pasta - namespace, damit ich es leicht finden können"

Bob ist ein sehr verwirrter Mann.

Module Ihre Eigene Box

Haben Sie wahrscheinlich hatte etwas ähnliches passieren im wirklichen Leben: Sie bestellen ein paar Sachen auf Amazon, und jedes Element zeigt sich in seiner eigenen box, eine kleinere box im inneren, mit Ihrem Einzelteil eingewickelt in seiner eigenen Verpackung. Auch wenn die inneren Boxen sind ähnlich, die Sendungen sind nicht sinnvoll "kombiniert".

Gehen mit der box-Analogie, der Schlüssel ist die Beobachtung, dass externe Module sind eigene box. Es könnte sein, ein sehr Komplexes Element mit vielen Funktion, kann aber beliebige externe Modul ist eine eigene box.

---

Anleitung für Externe Module

Nun, dass wir herausgefunden haben, dass wir nicht brauchen, um verwenden 'namespaces', wie sollten wir uns organisieren, unsere Module? Einige Leitprinzipien und Beispiele Folgen.

Exportieren, als in der Nähe von top-level wie möglich

• Wenn Sie nur exportieren einer einzelnen Klasse oder Funktion, verwenden export default:

MyClass.ts

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

MyFunc.ts

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

Verbrauch

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

Ist dies optimal für den Verbraucher. Sie können den Namen Ihr geben, was Sie wollen (t in diesem Fall) und nicht zu tun haben, alle überflüssigen Punktierung, Ihre Objekte zu finden.

• Wenn Sie beim exportieren von mehreren Objekten, setzen Sie alle auf top-Niveau:

MyThings.ts

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

Verbrauch

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

• , Wenn Sie exportieren eine große Anzahl von Dingen, nur dann sollten Sie den module/namespace Stichwort:

MyLargeModule.ts

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

Verbrauch

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

---

Roten Fahnen

Alle der folgenden sind rote Fahnen für das Modul strukturieren. Überprüfen Sie, dass Sie nicht versuchen, um namespace-Ihre externe Module, wenn diese für Ihre Dateien:

• Eine Datei, deren nur top-level-Deklaration ist export module Foo { ... } (entfernen Foo und alles bewegen, was " up " eine Ebene)
• Eine Datei, die eine einzelne export class oder export function dass nicht export default
• Mehrere Dateien mit der gleichen export module Foo { im top-level (glaube nicht, dass diese gehen, um zu einem zu vereinen Foo!)

InformationsquelleAutor der Antwort Ryan Cavanaugh

Versuchen Sie zu organisieren, indem Sie Ordner:

baseTypes.ts

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

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

Hund.ts

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

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

Baum.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)

Die Idee ist, dass das Modul selbst sollte sich keine Gedanken /wissen, dass Sie beteiligt sind in einem namespace, aber dies macht Ihre API, um den Verbraucher in eine kompakte, sinnvolle Weise, die nicht wissen, welche Art von Modul-system, das Sie verwenden für das Projekt.

InformationsquelleAutor der Antwort Albinofrenchy

OP bin ich mit Ihnen der Mensch.
wieder zu, es ist nichts falsch mit, dass die Antwort mit 300+ up Stimmen, aber meine Meinung ist:

1. was ist falsch mit putting-Klassen in Ihrem gemütlichen, warmen eigene Dateien einzeln?
   Ich meine, das macht die Sache sieht viel besser aus, richtig? (oder jemand, den Sie einfach wie ein 1000-Linien-Datei für alle Modelle)

2. also dann, wenn der erste erreicht wird, müssen wir importieren, importieren, importieren, importieren... nur in jedem der Modell-Dateien, wie der Mensch, srsly, ein Modell-Datei, eine .d....ts-Datei, warum es so viele *s? es sollte einfach sein, einfach, sauber, und das ist es. Warum brauche ich den Einfuhren gibt es? warum? C# habe namespaces für einen Grund.

3. Dann sind Sie buchstäblich mit "Dateinamen.ts" als Bezeichner. Als Bezeichner... Kommen auf seinen 2017 jetzt, und wir das noch machen? Ima gehen Sie zurück zu Mars und schlafen für weitere 1000 Jahre.

So traurig, meine Antwort ist: nop, Sie nicht den "namespace" Ding funktionsfähig, wenn Sie nicht mit allen jenen, die Einfuhr oder die Verwendung dieser Dateinamen als id (die ich denke, ist wirklich dumm). Eine weitere option ist: alle diese Abhängigkeiten in einer box namens filenameasidentifier.ts und Einsatz

export namespace(or module) boxInBox {} .

wickeln Sie Sie, damit Sie nicht versuchen, auf anderen Klassen mit gleichen Namen, wenn Sie einfach nur versuchen, einen Verweis aus der Klasse sitzen direkt an der Oberseite von Ihnen.

InformationsquelleAutor der Antwort NO... Bugs...

Hund.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;
        }
    }
}

Baum.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 {
    }
}

InformationsquelleAutor der Antwort Alessandro Lendaro