Szukaj…
Wprowadzenie
Przed wydaniem Meteor 1.3 programiści Meteor byli sfrustrowani obsługą przez Meteor.js zależności plików i zmiennych globalnych. W odpowiedzi Meteor ustanowił nowe standardy dla struktur projektu, aby usprawnić system zależności projektu. W tym temacie wyjaśniono znormalizowaną strukturę projektu i związane z nią zasady.
Uwagi
klient
Cały kod w katalogu klienta jest uruchamiany tylko po stronie klienta lub w przeglądarce internetowej.
klient / kompatybilność
Katalog zgodności zawiera starsze lub zewnętrzne kody, takie jak biblioteki jQuery itp.
lib
Katalog lib jest ładowany przed innymi katalogami w projekcie Meteor i jest ładowany zarówno na serwerze, jak i kliencie. Jest to preferowane miejsce do definiowania modeli danych, bibliotek izomorficznych i logiki biznesowej.
import
Katalog importu jest katalogiem na serwerze, który jest dostępny zarówno dla serwera, jak i klienta, ale tylko przed dostarczeniem pakietu klienta do klienta.
paczki
Katalog pakietów jest miejscem, w którym niestandardowe pakiety są przechowywane podczas programowania lokalnego. Podczas korzystania ze standardowego polecenia meteor add package:name aby dodać pakiet, Meteor zajrzy najpierw do tego katalogu, jeśli pakiet lokalny ma odpowiednią nazwę opisu w swoim pliku package.js . Jeśli nie, sonduje atmosferę jak zwykle.
prywatny
Prywatny katalog zawiera pliki statyczne, które powinny być dostępne tylko na serwerze WWW.
publiczny
Katalog publiczny zawiera pliki statyczne, które są dostępne tylko w kliencie aplikacji. Może to obejmować zasoby marki itp.
serwer
Katalog serwera zawiera zasoby po stronie serwera. Może to obejmować logikę uwierzytelniania, metody i inny kod, który może wymagać rozważenia ze względów bezpieczeństwa.
testy
Katalog testów jest domyślnie pomijany, gdy aplikacja jest pakowana i wdrażana.
Jak zasugerował Richard Silverton , wygodnym pomysłem jest poddanie katalogu kontroli projektu meteor nie tylko kontroli wersji, ale także katalogu nadrzędnego.
W ten sposób możesz utrzymywać pliki pod kontrolą wersji bez konieczności radzenia sobie z meteor.
Klasyczne struktury katalogów
Pierwszą rzeczą, którą musisz wiedzieć, konstruując swoje aplikacje, jest to, że narzędzie Meteor ma kilka katalogów, które są zakodowane na sztywno z określoną logiką. Na bardzo podstawowym poziomie następujące katalogi są „upieczone” w pakiecie Meteor.
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)
Strona referencyjna: Przewodnik Meteor> Katalogi specjalne
Struktura katalogów tylko dla pakietów
Wiele osób ostatecznie obsługuje wiele aplikacji i chce udostępniać kod między aplikacjami. Prowadzi to do koncepcji architektury mikrousług i wszystkich pakietów aplikacji. Zasadniczo kod z całej klasycznej struktury katalogów jest przekształcany w pakiety.
Chociaż nie ma sztywno zakodowanej logiki dla katalogów w paczkach, uważamy, że dobrą praktyką jest używanie klasycznej struktury katalogów podczas tworzenia pakietów. Tworzy to naturalną ścieżkę refaktora, ponieważ funkcje są prototypowane w aplikacji, a następnie rozpakowywane w pakiety do opublikowania i udostępnienia. Nazwy katalogów są wspólne, więc członkowie zespołu są mniej zamieszani.
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
Struktura katalogu importów / modułów
Najnowsze wersje Meteora są dostarczane z obsługą ecmascript , czyli ES6 lub ES2015. Zamiast pakietów JavaScript obsługuje teraz instrukcje i moduły import , co zastępuje potrzebę aplikacji tylko dla pakietów. Najnowsza struktura katalogów jest podobna do struktury zawierającej tylko pakiet, ale używa katalogu /imports zamiast /packages .
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
Struktura katalogów trybu mieszanego
Oczywiście możesz łączyć te podejścia i używać zarówno pakietów, jak i importów wraz z kodem aplikacji. Struktura trybu mieszanego jest najbardziej powszechna w trzech sytuacjach: aplikacja franken, która po prostu wyciąga trochę tu i tam bez ogólnej strategii; aplikacja, która jest aktywnie refaktoryzowana ze struktur klasycznych lub tylko pakietowych do struktury importów / modułów.
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)
Kolejność ładowania katalogu
Pliki szablonów HTML są zawsze ładowane przed wszystkim innym
Pliki zaczynające się od main. są ładowane jako ostatnie
Pliki w dowolnym katalogu lib / są ładowane w następnej kolejności
Pliki z głębszymi ścieżkami są ładowane w następnej kolejności
Pliki są następnie ładowane w kolejności alfabetycznej całej ścieżki
Strona referencyjna: Meteor Guide> Struktura aplikacji> Domyślna kolejność ładowania plików
