Suche…
Einführung
Vor der Veröffentlichung von Meteor 1.3 waren Meteor-Entwickler mit der Handhabung von Dateiabhängigkeiten und globalen Variablen durch Meteor.js frustriert. Als Reaktion darauf setzte Meteor neue Maßstäbe für Projektstrukturen, um das Projektabhängigkeitssystem schlanker zu gestalten. Dieses Thema erläutert die standardisierte Projektstruktur und die dahinter stehenden Prinzipien.
Bemerkungen
Klient
Der gesamte Code im Clientverzeichnis wird nur auf der Clientseite oder im Webbrowser ausgeführt.
Client / Kompatibilität
Das Kompatibilitätsverzeichnis enthält Legacy- oder Drittanbietercode, wie z. B. jQuery-Bibliotheken usw.
lib
Das lib-Verzeichnis wird vor anderen Verzeichnissen in Ihrem Meteor-Projekt geladen und sowohl auf dem Server als auch auf dem Client geladen. Dies ist der bevorzugte Ort, um Datenmodelle, isomorphe Bibliotheken und Geschäftslogik zu definieren.
Einfuhren
Das Importverzeichnis ist ein Verzeichnis auf dem Server, das sowohl für den Server als auch für den Client verfügbar ist, jedoch nur, bevor das Client-Paket an den Client gesendet wird.
Pakete
Im Paketverzeichnis werden während der lokalen Entwicklung benutzerdefinierte Pakete gespeichert. Wenn Sie den Standardbefehl meteor add package:name , um ein Paket hinzuzufügen, sucht Meteor zuerst in diesem Verzeichnis, ob ein lokales Paket in seiner package.js Datei den entsprechenden Beschreibungsnamen hat. Wenn nicht, wird Atmosphere wie üblich abgefragt.
Privatgelände
Das private Verzeichnis enthält statische Dateien, die nur auf dem Webserver verfügbar sein sollten.
Öffentlichkeit
Das öffentliche Verzeichnis enthält statische Dateien, die nur auf dem Anwendungsclient verfügbar sind. Dies kann Branding-Assets usw. umfassen.
Server
Das Serververzeichnis enthält serverseitige Assets. Dazu können Authentifizierungslogik, Methoden und anderer Code gehören, der möglicherweise Sicherheitsaspekte berücksichtigt.
Tests
Das Testverzeichnis wird standardmäßig ausgelassen, wenn Ihre Anwendung gebündelt und bereitgestellt wird.
Wie von Richard Silverton vorgeschlagen , ist es eine bequeme Idee, nicht nur das Meteor-Projektverzeichnis unter Versionskontrolle zu stellen, sondern auch das übergeordnete Verzeichnis.
Auf diese Weise können Sie Dateien unter Versionskontrolle halten, ohne sich mit einem Meteor auseinandersetzen zu müssen.
Klassische Verzeichnisstrukturen
Das Erste, was Sie beim Strukturieren Ihrer Apps wissen müssen, ist, dass das Meteor-Tool einige Verzeichnisse enthält, die mit einer bestimmten Logik hartcodiert sind. Grundsätzlich werden die folgenden Verzeichnisse im Meteor-Bundler "gebacken".
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)
Referenzseite: Meteor Guide> Spezielle Verzeichnisse
Verzeichnisstruktur nur für Pakete
Viele Menschen unterstützen schließlich mehrere Anwendungen und möchten Code zwischen Apps austauschen. Dies führt zum Konzept der Microservice-Architektur und zu Apps für alle Pakete. Im Wesentlichen wird der Code aus der gesamten klassischen Verzeichnisstruktur in Pakete umgestaltet.
Obwohl es keine fest codierte Logik für Verzeichnisse in Paketen gibt, ist es ratsam, beim Erstellen von Paketen die klassische Verzeichnisstruktur zu verwenden. Dadurch wird ein natürlicher Refaktorpfad erstellt, da Features in der App prototypisiert und dann in Pakete extrahiert werden, die veröffentlicht und gemeinsam genutzt werden können. Die Verzeichnisnamen werden gemeinsam genutzt, sodass die Teammitglieder weniger verwirrt sind.
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
Verzeichnisstruktur der Imports / Module
Die neuesten Versionen von Meteor werden mit Unterstützung für ecmascript (ES6 oder ES2015) ausgeliefert. Anstelle von Paketen unterstützt Javascript jetzt import und -module, was die Notwendigkeit von Paketanwendungen ersetzt. Die neueste Verzeichnisstruktur ähnelt der Paketstruktur, verwendet jedoch das Verzeichnis /imports anstelle von /packages .
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
Verzeichnisstruktur im gemischten Modus
Natürlich können Sie diese Ansätze kombinieren und Pakete sowie Importe neben Ihrem anwendungsspezifischen Code verwenden. Eine Mix-Modus-Struktur kommt am häufigsten in drei Situationen vor: Eine Franken-App, die einfach ohne eine übergeordnete Strategie ein bisschen von hier und da abzieht; Eine App, die von Classic- oder Package-Only-Strukturen aktiv in die Imports / Modules-Struktur überarbeitet wird.
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)
Reihenfolge beim Laden des Verzeichnisses
HTML-Vorlagendateien werden immer vor allem anderen geladen
Dateien, die mit main beginnen. werden zuletzt geladen
Als nächstes werden Dateien in einem beliebigen lib / -Verzeichnis geladen
Als nächstes werden Dateien mit tieferen Pfaden geladen
Die Dateien werden dann in alphabetischer Reihenfolge des gesamten Pfads geladen
Referenzseite: Meteor-Handbuch> Anwendungsstruktur> Standardreihenfolge beim Laden von Dateien