Sök…
Introduktion
Innan Meteor 1.3 släpptes var Meteor-utvecklare frustrerade över Meteor.js 'hantering av filberoenden och globala variabler. Som svar satte Meteor nya standarder för projektstrukturer för att göra projektberoende-systemet mer strömlinjeformat. Detta ämne förklarar den standardiserade projektstrukturen och principerna bakom det.
Anmärkningar
klient
All kod i klientkatalogen körs endast i klientsidan eller webbläsaren.
klient / kompatibilitet
Kompatibilitetskatalogen innehåller äldre eller tredje parts kod, till exempel jQuery-bibliotek, etc.
lib
Lib-katalogen laddas före andra kataloger i ditt Meteor-projekt och laddas både på servern och klienten. Detta är den föredragna platsen att definiera datamodeller, isomorfa bibliotek och affärslogik.
import
Importkatalogen är en katalog på servern som är tillgänglig för både servern och klienten, men först innan klientpaketet skickas till klienten.
paket
Paketkatalogen är där anpassade paket lagras under lokal utveckling. När du använder standardkommandot meteor add package:name att lägga till ett paket, kommer Meteor att titta först i den här katalogen om ett lokalt paket har motsvarande beskrivningsnamn i sin package.js fil. Om inte, kommer det att pollera Atmosphere som vanligt.
privat
Den privata katalogen innehåller statiska filer som bara ska vara tillgängliga på webbservern.
offentlig
Den offentliga katalogen innehåller statiska filer som endast är tillgängliga på programklienten. Detta kan inkludera brandingtillgångar etc.
server
Serverkatalogen innehåller tillgångar på serversidan. Detta kan inkludera autentiseringslogik, metoder och annan kod som kan behöva övervägas av säkerheten.
tester
Testkatalogen utelämnas som standard när din applikation är buntad och distribuerad.
Som föreslagits av Richard Silverton är det en bekväm idé att inte bara sätta meteorprojektkatalogen under versionskontroll, utan också dess moderkatalog.
På så sätt kan du hålla filer under versionskontroll utan att ha meteor att hantera det.
Klassiska katalogstrukturer
Det första du behöver veta när du strukturerar dina appar är att Meteor-verktyget har några kataloger som är hårdkodade med specifik logik. På en mycket grundläggande nivå är följande kataloger "bakade" i Meteor-paketet.
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)
Referenssida: Meteorguide> Specialkataloger
Paket-endast katalogstruktur
Många befinner sig så småningom stödja flera applikationer och önskar dela kod mellan appar. Detta leder till begreppet mikroservicearkitektur och alla paketappar. I huvudsak reforteras koden från hela den klassiska katalogstrukturen till paket.
Även om det inte finns någon hårkodad logik för kataloger i paket, finner vi att det är en bra praxis att använda den klassiska katalogstrukturen när du skapar paket. Detta skapar en naturlig refaktorväg eftersom funktioner prototyper i appen och extraheras sedan i paket som ska publiceras och delas. Katalognamnen delas, så det är mindre förvirring bland teammedlemmarna.
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
Import / moduler Katalogstruktur
De senaste versionerna av Meteor fartyg med stöd för ecmascript , alias ES6 eller ES2015. Istället för paket stöder Javascript nu import och moduler, som ersätter behovet av paket-endast applikationer. Den senaste katalogstrukturen liknar endast paketstrukturen, men använder katalogen /imports istället för /packages .
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
Katalogstruktur för blandat läge
Och naturligtvis kan du blanda dessa tillvägagångssätt och använda både paket och import längs med din applikationsspecifika kod. En mix-mode-struktur är vanligast i tre situationer: en franken-app, som bara är lite att dra lite här-och-där utan någon övergripande strategi; en app som aktivt refactored från antingen klassiska eller paket-endast strukturer till importer / moduler strukturen.
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)
Katalogbelastningsordning
HTML-mallfiler laddas alltid före allt annat
Filer som börjar med main. laddas senast
Filer inuti varje lib / katalog laddas nästa
Filer med djupare sökvägar laddas nästa
Filer laddas sedan i alfabetisk ordning för hela banan
Referenssida: Meteorguide> Applikationsstruktur> Standardfilbelastningsordning