Zoeken…
Invoering
Vóór de release van Meteor 1.3 waren Meteor-ontwikkelaars gefrustreerd over de afhandeling van bestandsafhankelijkheden en globale variabelen door Meteor.js. In reactie daarop heeft Meteor nieuwe normen vastgesteld voor projectstructuren om het projectafhankelijkheidssysteem gestroomlijnder te maken. In dit onderwerp worden de gestandaardiseerde projectstructuur en de principes erachter uitgelegd.
Opmerkingen
cliënt
Alle code in de clientmap wordt alleen uitgevoerd in de client of webbrowser.
client / compatibiliteit
De compatibiliteitsmap bevat verouderde of code van derden, zoals jQuery-bibliotheken, enz.
lib
De lib-directory wordt vóór andere mappen in uw Meteor-project geladen en op zowel de server als de client geladen. Dit is de aangewezen plek om datamodellen, isomorfe bibliotheken en bedrijfslogica te definiëren.
invoer
De importmap is een map op de server die beschikbaar is voor zowel de server als de client, maar alleen voordat de clientbundel naar de client wordt verzonden.
pakketjes
De pakkettenmap is waar aangepaste pakketten worden opgeslagen tijdens lokale ontwikkeling. Bij gebruik van de standaardopdracht meteor add package:name om een pakket toe te voegen, zal Meteor eerst in deze map kijken of een lokaal pakket de bijbehorende beschrijvingsnaam in het bestand package.js . Als dit niet het geval is, zal het zoals gewoonlijk de atmosfeer bevragen.
privaat
De privémap bevat statische bestanden die alleen beschikbaar moeten zijn op de webserver.
openbaar
De openbare map bevat statische bestanden die alleen beschikbaar zijn op de applicatieclient. Dit kan merkactiva, etc. omvatten
server
De servermap bevat activa aan de serverzijde. Dit kan verificatielogica, methoden en andere code zijn die mogelijk een beveiligingsoverweging vereist.
testen
De testmap wordt standaard weggelaten wanneer uw toepassing wordt gebundeld en geïmplementeerd.
Zoals voorgesteld door Richard Silverton is het een handig idee om niet alleen de meteor-projectmap onder versiebeheer te plaatsen, maar ook de bovenliggende map.
Op die manier kunt u bestanden onder versiebeheer houden zonder dat meteor er mee te maken heeft.
Klassieke directorystructuren
Het eerste dat u moet weten bij het structureren van uw apps, is dat de Meteor-tool een aantal mappen heeft die hard zijn gecodeerd met specifieke logica. Op een zeer basisniveau worden de volgende mappen "gebakken" in de Meteor-bundler.
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)
Referentiepagina: Meteor Guide> Speciale mappen
Directorystructuur met alleen pakketten
Veel mensen vinden uiteindelijk dat ze meerdere applicaties ondersteunen en willen code delen tussen apps. Dit leidt tot het concept van microservice-architectuur en apps voor alle pakketten. In wezen wordt de code van de hele klassieke mapstructuur opnieuw omgezet in pakketten.
Hoewel er geen hard gecodeerde logica is voor mappen in pakketten, vinden we dat het een goede gewoonte is om de klassieke mapstructuur te gebruiken bij het maken van pakketten. Dit creëert een natuurlijk refactorpad, omdat functies in de app worden geprototypeerd en vervolgens worden geëxtraheerd in pakketten die moeten worden gepubliceerd en gedeeld. De mapnamen worden gedeeld, dus er is minder verwarring tussen teamleden.
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 / Modules Directorystructuur
De meest recente versies van Meteor worden geleverd met ondersteuning voor ecmascript , ook bekend als ES6 of ES2015. In plaats van pakketten ondersteunt Javascript nu import en modules, waardoor de behoefte aan alleen-pakkettoepassingen wordt vervangen. De nieuwste mapstructuur is vergelijkbaar met de alleen-pakketstructuur, maar gebruikt de map /imports plaats van /packages .
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
Gemengde directorystructuur
En natuurlijk kunt u deze benaderingen combineren en zowel pakketten als import gebruiken naast uw applicatiespecifieke code. Een mix-modusstructuur komt het meest voor in drie situaties: een franken-app, die gewoon een beetje van hier en daar trekt zonder een algemene strategie; een app die actief wordt gerefacteerd van klassieke of alleen-pakketstructuren naar de structuur Imports / Modules.
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)
Directory-laadvolgorde
HTML-sjabloonbestanden worden altijd vóór al het andere geladen
Bestanden beginnend met main. worden als laatste geladen
Bestanden in elke lib / map worden vervolgens geladen
Bestanden met diepere paden worden vervolgens geladen
Bestanden worden vervolgens in alfabetische volgorde van het hele pad geladen
Referentiepagina: Meteoorgids> Toepassingsstructuur> Standaard laadvolgorde van bestanden