Pytanie w sprawie meteor – Jakie są najlepsze praktyki dotyczące strukturyzacji dużej aplikacji Meteor z wieloma plikami szablonów HTML? [Zamknięte]

165

We wszystkich przykładach (tablica wyników, gra słów itp.) Mają jeden plik szablonu HTML. Czy istnieje jakiś duży projekt Meteor o otwartym kodzie źródłowym z wieloma różnymi plikami szablonów HTML, których możemy użyć jako przykładu najlepszej praktyki? Nie wydaje się praktyczne umieszczanie wszystkiego, czego potrzebuje duża aplikacja, w jednym pliku szablonu.

Oficjalny przewodnik Meteor sugeruje bardzo fajną strukturę plików. Sprawdź tutaj:guide.meteor.com/structure.html#javascript-structure Waqas
Czytałeś część o tymStrukturyzowanie aplikacji w instrukcji? Istnieje pewne wyjaśnienie dotyczące skanowania i łączenia plików HTML. zwippie
meteor to nowe rzeczy, nie znalazłem w tym żadnej najlepszej praktyki. Spodziewam się również czegoś na ten temat newlife

Twoja odpowiedź

14   odpowiedzi
1

aby ulepszyć i skalować moje aplikacje poprzez dobrze przemyślaną architekturę. Wszystkie wyżej wymienione praktyki działają dla małych i średnich aplikacji, ale nie powiedzie się, gdy pracujesz w większym zespole. Próbowałem na kilka sposobów:

1) Przestrzegałem tej strategii:https://github.com/aldeed/meteor-autoform skalować i ponownie używać szablonów. Autor ma bardzo dobry pomysł na projektowanie komponentów i pól. Obecnie wdrażam go, ponieważ społeczność opracowała 36 pakietów, które obejmują prawie każdy przypadek i mogę z niego korzystaćMaszynopis być bezpiecznym typem w fazie rozwoju.

<template name="autoForm">
  {{#unless afDestroyUpdateForm this.id}}
  {{! afDestroyUpdateForm is a workaround for sticky input attributes}}
  {{! See https://github.com/meteor/meteor/issues/2431 }}
  <form {{atts}}>
    {{> Template.contentBlock ..}}
  </form>
  {{/unless}}
</template>

Oto dobry post na blogu, jak to zrobić:http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ jak również tutaj:http://meteorpedia.com/read/Blaze_Notes

2) Ten wygląda tak obiecująco, ale nie był ostatnio aktualizowany. Jest to pakiet napisany w skrypcie kawy o nazwie. Komponenty Blaze (https://github.com/peerlibrary/meteor-blaze-components) dla Meteor to system do łatwego opracowywania złożonych elementów interfejsu użytkownika, które muszą być ponownie użyte wokół aplikacji Meteor. Możesz ich używać w CoffeeScript, waniliowym JavaScript i ES6. Najlepsze jest to, że komponenty są OOP. Oto jeden z ich przykładów:

class ExampleComponent extends BlazeComponent {
  onCreated() {
    this.counter = new ReactiveVar(0);
  }

  events() {
    return [{
      'click .increment': this.onClick
    }];
  }

  onClick(event) {
    this.counter.set(this.counter.get() + 1);
  }

  customHelper() {
    if (this.counter.get() > 10) {
      return "Too many times";
    }
    else if (this.counter.get() === 10) {
      return "Just enough";
    }
    else {
      return "Click more";
    }
  }
}

ExampleComponent.register('ExampleComponent');

{{> ExampleComponent }}

3) Lubię typy i transpilery, które mówią mi gdzie i kiedy coś pójdzie nie tak. Używam TypeScript do pracy z Meteor i znalazłem następujące repozytorium:https://github.com/dataflows/meteor-typescript-utils wydaje się, że twórca próbował osiągnąć podejście MVC.

class MainTemplateContext extends MainTemplateData {
    @MeteorTemplate.event("click #heybutton")
    buttonClick(event: Meteor.Event, template: Blaze.Template): void {
        // ...
    }

    @MeteorTemplate.helper
    clicksCount(): number {
        // ...
    }
}

class MainTemplate extends MeteorTemplate.Base<MainTemplateData> {
    constructor() {
        super("MainTemplate", new MainTemplateContext());
    }

    rendered(): void {
        // ...
    }
}

MeteorTemplate.register(new MainTemplate());

<template name="MainTemplate">
    <p>
        <input type="text" placeholder="Say your name..." id="name">
        <input type="button" value="Hey!" id="heybutton">
    </p>
    <p>
        Clicks count: {{ clicksCount }}
    </p>

    <p>
        <ul>
            {{#each clicks }}
                <li> {{ name }} at <a href="{{pathFor 'SingleClick' clickId=_id}}">{{ time }}</a></li>
            {{/each}}
        </ul>
    </p>
</template>

Niestety ten projekt nie jest utrzymywany ani aktywnie rozwijany.

4) i myślę, że już o tym wspomniano, można skalować za pomocą pakietów. Wymaga to dobrego abstrakcyjnego sposobu myślenia. Wydaje się, że działa dla Telescope:https://github.com/TelescopeJS/Telescope

5)rozszerzenie meteor-szablon - zapewnia różne sposoby kopiowania pomocników szablonów, obsługi zdarzeń i haków między szablonami, umożliwiając ponowne wykorzystanie kodu; minusem jest to, że wszelkie kopiowanie musi być nadzorowane przez programistę, często raz po raz, co staje się problematyczne, ponieważ baza kodu rośnie; ponadto bez jasno zdefiniowanej społeczności API nie można budować i udostępniać komponentów

6)Składniki przepływu - Flow Components są bliższe React w projekcie API, podczas gdyKomponenty Blaze utrzymują znane pojęcia, takie jak konteksty danych i pomocniki szablonów; Komponenty Flow z drugiej strony nadal używają opartych na szablonach procedur obsługi zdarzeń, podczas gdy Komponenty Blaze czynią je metodami klasowymi, dzięki czemu łatwiej je rozszerzyć lub zastąpić poprzez dziedziczenie; ogólnie komponenty Blaze wydają się być bardziej zorientowane na OOP; Komponenty Flow nie są jeszcze oficjalnie wydane (kredyty tekstowe dla # 5 i # 6https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support)

Numer 2 i 3 też muszą być używane, ale z czasem zyskasz szybkość rozwoju. Numer cztery pozwala budować i testować komponenty, aby uczynić swój kod bardziej stabilnym. Numer trzy ma zaletę pełnego bezpieczeństwa typu Typescript, co jest ogromnym plusem, gdy rozwijasz się w zespole ze słabą dokumentacją. Jednak obecnie przenoszę numer dwa do TypeScript, ponieważ czuję się bardzo dobrze pracując z nim i nie muszę modyfikować pakietu kompilatora, aby działał z Meteorem, gdy nie używam Gulp.

Nadal trudno jest znaleźć właściwy sposób pracy z Meteor. Musisz sam to rozgryźć, inaczej skończysz z ładnie zaaranżowaną strukturą folderów, ale nie masz pojęcia, gdzie wszystko jest. Szczęśliwe kodowanie.

26

abyś projektował swoją aplikację w dowolny sposób. Więc jeśli nie podoba ci się twoja struktura, możesz po prostu przenieść plik do nowego katalogu, a nawet podzielić jeden plik na wiele części, a Meteorowi to prawie wszystko. Zwróć uwagę na specjalne traktowanie katalogów klientów, serwerów i publicznych, jak określono na głównej stronie dokumentacji:http://docs.meteor.com/.

Zebranie wszystkiego razem w jednym wypełnieniu HTML z pewnością nie stanie się najlepszą praktyką.

Oto przykład jednej z możliwych struktur: w jednej z moich aplikacji, forum dyskusyjnego, organizuję według modułu lub „typu strony” (strona główna, forum, temat, komentarz), wstawiając plik .css, .html i .js dla każdego typ strony razem w jednym katalogu. Mam także moduł „podstawowy”, który zawiera wspólny kod .css i .js oraz szablon główny, który używa {{renderPage}} do renderowania jednego z pozostałych modułów w zależności od routera.

<code>my_app/
    lib/
        router.js
    client/
        base/
            base.html
            base.js
            base.css
        home/
            home.html
            home.js
            home.css
        forum/
            forum.html
            forum.js
            forum.css
        topic/
            topic.html
            topic.js
            topic.css
        comment/
            comment.html
            comment.js
            comment.css
</code>

Możesz także organizować według funkcji

<code>my_app/
    lib/
        router.js
    templates/
        base.html
        home.html
        forum.html
        topic.html
        comment.html
    js/
        base.js
        home.js
        forum.js
        topic.js
        comment.js
    css/
        base.css
        home.css
        forum.css
        topic.css
        comment.css
</code>

Mam jednak nadzieję, że pojawią się bardziej konkretne struktury najlepszych praktyk i konwencje nazewnictwa.

To moja ulubiona odpowiedź. Jedną z moich ulubionych rzeczy w Meteor jest to, że możesz uporządkować swoje pliki w sposób, który działa dla Ciebie. CaptSaltyJack
1.3 zapchana liba na rzecz importuguide.meteor.com/structure.html#example-app-structure Jeremy Iglehart
Podoba mi się ta odpowiedź. Robiłem to w pierwszy sposób. Sung Cho
nie widzę wartości w nazywaniu wielu plików nazwą funkcji, np. „temat”. Jeśli chcesz zmienić nazwę funkcji na „kategorię”, musisz zmienić wiele nazw plików. Po prostu zorganizuj je w jednym folderze o nazwie „topic” i nazwij je ogólnie: events.js, views.html, styles, css, routes.js itd. Zobacz moją odpowiedź na więcej. Max Hodges
powiązane rzeczy powinny być blisko siebie. Moja odpowiedź jest jak twoja, ale wstecz. Max Hodges
15

Zlep to wszystko razem! Z dokumentów:

<code>> HTML files in a Meteor application are treated quite a bit differently
> from a server-side framework. Meteor scans all the HTML files in your
> directory for three top-level elements: <head>, <body>, and
> <template>. The head and body sections are seperately concatenated
> into a single head and body, which are transmitted to the client on
> initial page load.
> 
> Template sections, on the other hand, are converted into JavaScript
> functions, available under the Template namespace. It's a really
> convenient way to ship HTML templates to the client. See the templates
> section for more.
</code>
@ MaxHodges: Re: „Aplikacje, które ładują się szybciej, nie zawsze są lepsze”: Ceteris paribus, są. ruakh
tak Asana ładuje się trochę czasu. Asana to również niesamowicie dobrze wykonana, reaktywna aplikacja, w której użytkownicy stworzyli 175 milionów zadań w 2014 roku. Aplikacje ładujące się szybciej nie zawsze są lepsze. Uruchamianie aplikacji na telefonie zajmuje chwilę. Ludzie się do tego przyzwyczają. Max Hodges
@dudewad: Nie sądzę. Wydaje się mówić, że zwiększona prędkość nie zawsze jest poprawą; przynajmniej nie twierdzi, że siły Asany w jakikolwiek sposób zależą od jej względnej powolności. ruakh
To jednak dotyczy plakatu. Lumping jest w porządku, ale możesz zobaczyć, co dzieje się z Asaną - wymaga ekranu ładowania, podczas gdy pobiera> 1 MB kodu klienta. To nie do przyjęcia dla wielu witryn. Zobaczymy, czy po załadowaniu głównego ekranu nie uda nam się zrobić częściowego ładowania, ale teraz jestem sceptyczny. Myślę, że to będzie musiała być funkcja, która trochę się rozbije. Dave Sanders
6

cieszę się, że mam trochę wolnego czasu na zbudowanie dość skomplikowanej gry online. Struktura aplikacji była jedną z moich pierwszych obaw i wygląda na to, że kilku bardzo dobrych programistów opowiadało się za metodą tworzenia pakietów aplikacji, która pozwala na swobodne łączenie funkcjonalnie odrębnych pakietów. Podejście ma inne zalety, a 2 bardzo dobre artykuły wyjaśniające to podejście można znaleźć tutaj:

http://www.matb33.me/2013/09/05/meteor-project-structure.html http://www.manuel-schoebel.com/blog/meteorjs-package-only-app-structure-with-mediator-pattern

4

który zawiera już żelazny router i model (Kolekcja2). Zobacz poniżej:

<code>client/                 # Client folder
    compatibility/      # Libraries which create a global variable
    config/             # Configuration files (on the client)
    lib/                # Library files that get executed first
    startup/            # Javascript files on Meteor.startup()
    stylesheets         # LESS files
    modules/            # Meant for components, such as form and more(*)
    views/              # Contains al,l views(*)
        common/         # General purpose html templates
model/                  # Model files, for each Meteor.Collection(*)
private/                # Private files
public/                 # Public files
routes/                 # All routes(*)
server/                 # Server folder
    fixtures/           # Meteor.Collection fixtures defined
    lib/                # Server side library folder
    publications/       # Collection publications(*)
    startup/            # On server startup
meteor-boilerplate      # Command line tool
</code>
9
Utwórz pakiety

ale w dużych aplikacjach będziesz miał wiele funkcji, które można izolować. Wszystko, co można rozdzielić i wykorzystać ponownie w pakietach, reszta trafia do zwykłej struktury katalogów, jak wspomniano w innych odpowiedziach. Nawet jeśli nie tworzysz pakietów, aby uniknąć kosztów ogólnych, dobrym pomysłem jest uporządkowanie kodu w sposób modułowy (patrzte sugestie)

Meteor pozwala na precyzyjną kontrolę nad ładowaniem plików (kolejność ładowania, gdzie: klient / serwer / oba) oraz eksport pakietu.

Szczególnie przydatny jest prosty sposób udostępniania logiki między powiązanymi plikami. Powiedzmy na przykład, że chcesz sprawić, aby niektóre funkcje były używane i używane w różnych plikach. Po prostu sprawiasz, że jest „globalny” (bezvar) i Meteor zapakuje go w przestrzeń nazw pakietu, aby nie zanieczyszczał globalnej przestrzeni nazw

Tutajjest oficjalnym dokumentem

14

Theem narzędzie linii poleceń (wydane przez EventedMind, faceci za Żelaznym Ruterem) jest bardzo pomocne przy ustawianiu nowej aplikacji Meteor. Spowoduje to utworzenie ładnej struktury plików / folderów. Jeśli już pracujesz nad aplikacją i chcesz ją ponownie zorganizować, po prostu skonfiguruj nowy projektem i możesz go użyć do inspiracji.

Widzieć:https://github.com/EventedMind/em

I tu:https://stackover.com/questions/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

Uwaga: został zastąpiony przez iron-cli (ten sam autor). Widzieć:github.com/iron-meteor/iron-cli j0e
Tak, nazwa „em” została zmieniona na iron-cli, to samo narzędzie. Mikael Lirbank
5

https://github.com/iron-meteor/iron-cli

po zainstalowaniu. posługiwać sięiron create my-app stworzyć nowy projekt. Stworzy dla ciebie następującą strukturę. Możesz to również wykorzystać w istniejących projektach. posługiwać sięiron migrate w katalogu projektu.

<code>my-app/    
 .iron/    
   config.json    
 bin/    
 build/    
 config/    
   development/    
     env.sh    
     settings.json    
 app/    
   client/    
     collections/    
     lib/    
     stylesheets/    
     templates/    
     head.html    
   lib/    
     collections/    
     controllers/    
     methods.js    
     routes.js    
   packages/    
   private/    
   public/    
   server/    
     collections/    
     controllers/    
     lib/    
     methods.js    
     publish.js    
     bootstrap.js
</code>
Chociaż ten link może odpowiedzieć na pytanie, lepiej jest dołączyć tutaj istotne części odpowiedzi i podać link do odniesienia. Odpowiedzi tylko na link mogą stać się nieprawidłowe, jeśli zmieniona zostanie strona połączona. user2314737
@ user2314737 Nie mów, że odpowiadający edytował swój post. Zawiera teraz niezbędne dane potrzebne do rozwiązania problemu. Paul Stenne
36

client/application.js

Posługiwać się:

client/main.js

pliki główne. * są ładowane jako ostatnie. Pomoże to upewnić się, że nie masz żadnych problemów z kolejnością ładowania. Zobacz dokumentację Meteor,http://docs.meteor.com/#structuringyourapp, po więcej szczegółów.

11

że struktura plików z książki Discover Meteor Book jest naprawdę dobra i solidny.

<code>/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
</code>
Kod w katalogu / server działa tylko na serwerze.Kod w katalogu / client działa tylko na kliencie.Wszystko inne działa zarówno na kliencie, jak i na serwerze.Pliki w / lib są ładowane przed wszystkim innym.Każdy główny plik. * Jest ładowany po wszystkim.Twoje statyczne zasoby (czcionki, obrazy itp.) Znajdują się w katalogu / public.
3

d, jeśli masz router i różne szablony stron, a wewnętrzny szablon każdej strony ma wiele części strony i tak dalej, to bym nadał jej strukturę zależną od semantyki z wyższego> niższego poziomu.

Na przykład:

<code>client
  views
    common
      header
        header.html
        header.js
        header.css
      footer
        footer.html
        footer.js
        footer.css
    pages
      mainPage
        mainPage.html
        mainPage.js
        mainPage.css
        articles
          articles.html
          articles.js
          articles.css
        news
          news.html
          news.js
          news.css
     ...
</code>

Oczywiście możesz umieścić swoje szablony wiadomości we wspólnym folderze, ponieważ możesz użyć szablonu wiadomości na różnych stronach.

Myślę, że najlepiej jest ustrukturyzować swoją aplikację w sposób, który Ci odpowiada.

Napisałem małą aplikację tutaj:http://gold.meteor.com I jest tak mały, używam tylko jednego pliku html i tylko jednego pliku template.js .. :)

Mam nadzieję, że to trochę pomoże

nie widzę wartości w nazywaniu wielu plików nazwą funkcji, takich jak „artykuły”. Jeśli chcesz zmienić nazwę funkcji na „posty”, musisz zmienić nazwy plików. Po prostu zorganizuj je w jednym folderze o nazwie „artykuły” i nazwij je „events.js”, views.html, styles, css itp. Zobacz moją odpowiedź. Max Hodges
6

rowych, jaki zbudowali do tej pory wszyscy, ponieważ był w pełnym wymiarze godzin przez 1,5 roku). Używamy tego samego zestawu nazw plików w każdym widoku. Jest bardzo spójny i pomaga nam szybko przejść do dokładnie tego, czego szukamy:

events.jshelpers.jstemplates.htmlroutes.jsstyles.lessitp.

Tak wygląda w projekcie:

       ├── consolidationRequests
       │   ├── events.js
       │   ├── helpers.js
       │   ├── routers.js
       │   └── templates.html
       ├── customerSpoof
       │   └── routers.js
       ├── dashboard
       │   ├── events.js
       │   ├── helpers.js
       │   ├── onDestroyed.js
       │   ├── onRendered.js
       │   ├── routers.js
       │   └── templates.html
       ├── emailVerification
       │   ├── events.js
       │   ├── helpers.js
       │   ├── routers.js
       │   └── templates.html
       ├── loading
       │   ├── styles.css
       │   └── templates.html
       ├── mailbox
       │   ├── autoform.js
       │   ├── consolidationRequestConfirmation
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onCreated.js
       │   │   ├── onRendered.js
       │   │   └── templates.html
       │   ├── events.js
       │   ├── helpers.js

Powiązane szablony są przechowywane razem w tym samym pliku. Zawartośćview/order/checkout/templates.html pokazane tutaj zwinięte:

<code><template name="orderCheckout"></template>

<template name="paymentPanel"></template>

<template name="orderCheckoutSummary"></template>

<template name="paypalReturnOrderCheckout"></template>
</code>

Używamy podfolderów, gdy widoki są złożone z dużą ilością części:

       ├── cart
       │   ├── addItem
       │   │   ├── autoform.js
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onRendered.js
       │   │   ├── routers.js
       │   │   ├── styles.less
       │   │   └── templates.html
       │   ├── checkout
       │   │   ├── autoform.js
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onRendered.js
       │   │   ├── routers.js
       │   │   └── templates.html
       │   └── view
       │       ├── autoform.js
       │       ├── deleteItem
       │       │   ├── events.js
       │       │   ├── helpers.js
       │       │   └── templates.html
       │       ├── editItem
       │       │   ├── autoform.js
       │       │   ├── events.js
       │       │   ├── helpers.js
       │       │   └── templates.html
       │       ├── events.js
       │       ├── helpers.js
       │       ├── onDestroyed.js
       │       ├── onRendered.js
       │       ├── routers.js
       │       ├── styles.less
       │       └── templates.html

Rozwijamy się również z WebStorm, niezwykle potężnym i elastycznym edytorem do rozwoju Meteor. Uważamy, że niezwykle pomocne jest wyszukiwanie i porządkowanie naszego kodu oraz wydajna praca.

Z przyjemnością dzielę się szczegółami na życzenie.

Na rynku dostępnych jest wiele płyt grzewczych. Większość użytkowników wolała nosić własną drogę. Ktoś wykonał ciężką pracę:medium.com/things-i-did-and-learned-today/… Shivam Bajpai
kochamy Meteor i wszystko w nim się rozwija. Niestety nie jestem wystarczająco zaznajomiony z LoopBack lub Happi, aby mieć opinię. Max Hodges
LoopBacks koncentruje się na end-to-end odpoczynku API sprawiają, że brzmi jak tradycyjny framework do tworzenia stron internetowych (jak RoR). RoR ma prawo do REST API, ale uważamy, że Meteor miał rację w czasie rzeczywistym. Max Hodges
Rozważ dodanie komentarza, jeśli uważasz, że ta odpowiedź może zostać poprawiona. Max Hodges
3

Wiara umysłu nazywaKonfigurowanie projektów Meteor to rozwiązuje ten problem, ale mówi także o konfiguracji projektu i ustawieniu środowiska programistycznego.

OdStruktura aplikacji wideo w klasie: Meteor nie ma bardzo silnej opinii na temat struktury twojej aplikacji, ale oto kilka zasad:

1) Kolejność ładowania - Meteor najpierw przechodzi do najgłębszego miejsca w katalogu plików i przetwarza pliki w kolejności alfabetycznej

2) klient i serwer to specjalne foldery rozpoznawane przez Meteor

Nasza struktura wygląda tak:

<code>both/
    collections/
        todos.js
    controllers/
        todos_controller.js
    views/
        todos.css
        todos.html
        todos.js
    app.js - includes routes
client/
    collections/
    views/
        app.js
server/
    collections/
    views/
        app.js
packages/
public/
</code>

Todos_controller rozszerza RouteController, coś, co pochodzi z Iron Router.

Theem Narzędzie wspomniane powyżej również ma teraz dużą aktualizację i powinno być znacznie lepsze i dostępne pod adresem:https://github.com/EventedMind/em

nie widzę wartości w nazywaniu wielu plików nazwą funkcji, taką jak „todos”. Teraz, jeśli chcesz zmienić nazwę funkcji na „zadania”, musisz zmienić 5 nazw plików. Po prostu zorganizuj je w jednym folderze o nazwie „todos” i nazwij je „events.js”, views.html, styles, css itp. Zobacz moją odpowiedź. Max Hodges
co widzi wewnątrz / server / views /? StefanoCudini
273

myślę, że to wyjaśnia, jak zorganizować dużą aplikację:

Gdzie powinienem umieścić moje pliki?

Przykładowe aplikacje w meteor są bardzo proste i nie zapewniają wiele wglądu. Oto moje obecne myślenie o najlepszym sposobie zrobienia tego: (wszelkie sugestie / ulepszenia są bardzo mile widziane!)

<code>lib/                       # <- any common code for client/server.
lib/environment.js         # <- general configuration
lib/methods.js             # <- Meteor.method definitions
lib/external               # <- common code from someone else
## Note that js files in lib folders are loaded before other js files.

collections/               # <- definitions of collections and methods on them (could be models/)

client/lib                 # <- client specific libraries (also loaded first)
client/lib/environment.js  # <- configuration of any client side packages
client/lib/helpers         # <- any helpers (handlebars or otherwise) that are used often in view files

client/application.js      # <- subscriptions, basic Meteor.startup code.
client/index.html          # <- toplevel html
client/index.js            # <- and its JS
client/views/<page>.html   # <- the templates specific to a single page
client/views/<page>.js     # <- and the JS to hook it up
client/views/<type>/       # <- if you find you have a lot of views of the same object type
client/stylesheets/        # <- css / styl / less files

server/publications.js     # <- Meteor.publish definitions
server/lib/environment.js  # <- configuration of server side packages

public/                    # <- static files, such as images, that are served directly.

tests/                     # <- unit test files (won't be loaded on client or server)
</code>

W przypadku większych aplikacji dyskretna funkcjonalność może zostać podzielona na podkatalogi, które same są zorganizowane według tego samego wzorca. Chodzi o to, że w końcu moduł funkcjonalności może zostać uwzględniony w oddzielnym pakiecie inteligentnym, a najlepiej, aby był współdzielony.

<code>feature-foo/               # <- all functionality related to feature 'foo'
feature-foo/lib/           # <- common code
feature-foo/models/        # <- model definitions
feature-foo/client/        # <- files only sent to the client
feature-foo/server/        # <- files only available on the server
</code>

Dowiedz się więcej:Nieoficjalne FAQ Meteor

Jeśli chodzi o meteor 1.3, powiedziałbym, że jest on przestarzały ze względu na import modułu ES6. Zobacz artykuł przewodnika meteorytów na temat struktury aplikacji:guide.meteor.com/structure.html Samuel
gdzie powinniśmy umieścić Meteor.subscribe? dzięki :) hqt
każdy ma pojęcie, gdzie umieścićmobile-config.js? Dude
IMHO to jest lepsze niż zaakceptowana odpowiedź. Spróbuję tego teraz. hakan

Powiązane pytania