Ricerca…


introduzione

Prima del rilascio di Meteor 1.3, gli sviluppatori di Meteor erano frustrati dalla gestione di dipendenze di file e variabili globali da parte di Meteor.js. In risposta, Meteor ha stabilito nuovi standard per le strutture di progetto al fine di rendere più snello il sistema di dipendenza del progetto. Questo argomento spiega la struttura standardizzata del progetto e i principi alla base.

Osservazioni

cliente
Tutto il codice nella directory del client viene eseguito solo sul lato client o sul browser web.

client / compatibilità
La directory di compatibilità contiene codice legacy o di terze parti, come librerie jQuery, ecc.

lib
La directory lib viene caricata prima di altre directory nel progetto Meteor e viene caricata sia sul server che sul client. Questo è il posto preferito per definire modelli di dati, librerie isomorfe e business logic.

importazioni
La directory imports è una directory sul server disponibile sia per il server che per il client, ma solo prima che il bundle del client venga spedito al client.

pacchi
La directory dei pacchetti è dove vengono memorizzati i pacchetti personalizzati durante lo sviluppo locale. Quando si utilizza il comando standard meteor add package:name per aggiungere un pacchetto, Meteor cercherà prima in questa directory se un pacchetto locale ha il nome della descrizione corrispondente nel suo file package.js . Altrimenti, sonderà Atmosphere come al solito.

privato
La directory privata contiene file statici che dovrebbero essere disponibili solo sul server web.

pubblico
La directory pubblica contiene file statici che sono disponibili solo sul client dell'applicazione. Ciò potrebbe includere le risorse di branding, ecc.

server
La directory del server contiene risorse sul lato server. Questo può includere logica di autenticazione, metodi e altro codice che potrebbe richiedere considerazioni sulla sicurezza.

test
La directory dei test viene omessa per impostazione predefinita quando l'applicazione è in bundle e distribuita.

Come suggerito da Richard Silverton , è una buona idea mettere non solo la directory del progetto meteor sotto il controllo della versione, ma anche la sua directory genitore.

In questo modo è possibile mantenere i file sotto controllo di versione senza avere meteore per affrontarlo.

Classiche strutture di directory

La prima cosa che devi sapere quando si strutturano le tue app è che lo strumento Meteor ha alcune directory che sono hard-coded con una logica specifica. Ad un livello molto semplice, le seguenti directory sono "imbustate" nel pacchetto 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)

Pagina di riferimento: Meteor Guide> Directory speciali

Struttura di directory solo pacchetti

Molte persone finiscono per supportare più applicazioni e desiderano condividere il codice tra le app. Questo porta al concetto di architettura microservice e app all-package. In sostanza, il codice dell'intera struttura di directory classica viene rielaborato in pacchetti.

Anche se non esiste una logica hard-coded per le directory nei pacchetti, troviamo che è una buona pratica usare la classica struttura di directory quando si creano i pacchetti. Questo crea un percorso refactor naturale in quanto le funzionalità vengono prototipate nell'app e quindi estratte in pacchetti da pubblicare e condividere. I nomi delle directory sono condivisi, quindi c'è meno confusione tra i membri del team.

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

Struttura delle directory Imports / Modules

Le versioni più recenti di Meteor sono supportate da ecmascript , ES6 o ES2015. Invece di pacchetti, Javascript ora supporta istruzioni e moduli di import , che sostituisce la necessità di applicazioni solo pacchetto. L'ultima struttura di directory è simile alla struttura del solo pacchetto, ma usa la directory /imports invece di /packages .

imports                                 #
imports/api                             # isomorphic methods 
imports/lib                             # any common code for client/server
imports/client                          # client application code
imports/server                          # server code

Struttura di directory in modalità mista

E, naturalmente, puoi combinare questi approcci e utilizzare entrambi i pacchetti e le importazioni insieme al codice specifico dell'applicazione. Una struttura mix-mode è la più comune in tre situazioni: una app-franken, che è una sorta di tirata da qua e da là senza una strategia generale; un'app che viene attivamente rifattorizzata da strutture classiche o solo pacchetti alla struttura 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)

Ordine di caricamento della directory

I file modello HTML vengono sempre caricati prima di ogni altra cosa

File che iniziano con main. sono caricati per ultimi

I file all'interno di ogni cartella lib / vengono caricati successivamente

I file con percorsi più profondi vengono caricati successivamente

I file vengono quindi caricati in ordine alfabetico dell'intero percorso

Link di riferimento

Pagina di riferimento: Meteor Guide> Struttura dell'applicazione> Ordine di caricamento file predefinito



Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow