2016-10-30 3 views
2

Ich bin ein erfahrener Java-Entwickler, der eine Java-Anwendung für die Internetnutzung portieren muss, und ich habe darüber nachgedacht, Typescript zu verwenden. Für den Moment möchte ich den traditionellen Java-Stil von Paketen beibehalten, der eine Hierarchie von Ordnern und eine einzelne Klasse pro "Blatt" -Datei darstellt.TypeScript-Klasse in der traditionellen Ordnerhierarchie

Ich habe mir die Typoskript-Dokumente angesehen und sehe Dinge wie ../path/to/module. Sind alle so ähnlich? Gibt es eine Art Basisverzeichnis-Option, in der ich etwas Ähnliches wie import com.ancient.java.MyType; bekommen kann?

Erklärt auch eine package com.ancient.java; etwas in Typoskript getan werden?

Ich habe über die docs aussehen, aber ich finde sie nicht einfach mit all dem Gerede über interne und externe Namespaces und Export, usw.

Kann jemand kocht dies auf etwas zu lesen, fühlen wie Java für mich, um damit anzufangen? Ich bin mir sicher, dass ich später bei Bedarf in all die komplexen Dinge einsteigen werde. Wie sieht das im Code aus?

Antwort

4

Organisieren Sie Ihre Typoskript-Klassen in 1-Klasse pro Datei und eine organisierte Ordnerhierarchie ist vollkommen akzeptabel und sogar in Typoskript ermutigt.

Wenn Sie Typescript 2.0 oder höher verwenden, müssen Ihre Pfade nicht relativ sein. Sie können die baseUrl:-Eigenschaft verwenden, um anzugeben, wo nicht-relative (d. H. Keine . oder ..) Pfade verwurzelt sind. Zum Beispiel von Ihnen hatte:

tsconfig.json 
src/ 
    foo/ 
     foo.ts 
    bar/ 
     bar.ts 

Sie "baseUrl": "./src" einstellen könnte und dann konnte man import 'foo/foo' und import 'bar/bar' ohne relative Pfadnavigation zu verwenden.

Ich würde Sie davon abhalten, Pakete/Namespace/interne Module und dergleichen in Typoskripten zu deklarieren. Diese Art von Dingen sind meist Relikte der Vergangenheit, und nichts, was ich in einem neuen Projekt verwenden würde.

Ich würde empfehlen, bei dateibasierten Modulen zu bleiben, da dies der moderne empfohlene Ansatz zum Verfassen Ihrer Anwendung ist.

Eine Datei mit import oder export Anweisungen wird als "Dateimodul" betrachtet. Alles, was darin definiert ist, ist für die Datei privat und verschmutzt nicht den globalen Namensraum. Dinge, die geteilt werden sollen, müssen exportiert und aus anderen Dateien importiert werden.

Zum Beispiel könnten Sie die MyType Klasse in einer Dateistruktur wie folgt schreiben:

src/ 
    com/ 
     ancient/ 
      my-type.ts 

my-type.ts aussehen würde:

export class MyType{ 
    constructor(){ 
     console.log('Hello World'); 
    } 
} 

und dann könnte man es in anderen Dateien wie importieren:

import {MyType} from 'com/ancient/my-type' 

Sie sollten den Schlüssel nicht verwenden müssen Wörter namespace oder module. Dies sind meist Dinge, die nur in Datendeklarationsdateien zu finden sind.

+0

Ein paar kleine Punkte. Eine, externe Module 'sind genau ES2015-Module und sollten nicht entmutigt werden. Zwei, 'declare module' wird immer noch häufig in .d verwendet.ts-Dateien, nicht nur ältere. – Paarth

+0

Sie haben Recht, obwohl sie nicht mehr "externe Module" heißen. Während sie offiziell nur "Modul" sind, nenne ich sie gerne "Dateimodule", um zu betonen, dass die Datei selbst das Modul ist und keine Verwendung von "Decalre-Modul". Sie haben auch recht mit der möglichen Verwendung in modernen Deklarationsdateien. Ich habe über eine bestimmte Verwendung nachgedacht und nicht über andere, wie die Fähigkeit, ein Modul wieder zu öffnen und seine Typen zu erweitern. Ich habe die relevanten Änderungen vorgenommen, um jede Verwirrung zu vermeiden. – dtabuenc

Verwandte Themen