Frage an meteor – Was sind die Best Practices für die Strukturierung einer großen Meteor-App mit vielen HTML-Vorlagendateien? [geschlossen]

165

In allen Beispielen (Bestenliste, Wortspiel usw.) haben sie eine einzige HTML-Vorlagendatei. Gibt es ein großes Open-Source-Meteor-Projekt mit vielen verschiedenen HTML-Vorlagendateien, die wir als Best-Practice-Beispiel verwenden können? Es scheint nicht praktisch zu sein, alles, was eine große App benötigt, in eine Vorlagendatei zu packen.

Hast du den Teil über gelesen?Strukturierung Ihrer Anwendung im handbuch? Es gibt einige Erklärungen zum Scannen und Verketten von HTML-Dateien. zwippie
Der offizielle Leitfaden von Meteor schlägt eine sehr coole Dateistruktur vor. Überprüfe hier:guide.meteor.com/structure.html#javascript-structure Waqas
Meteor ist neu, ich habe keine verwandten Best Practices dazu gefunden. Ich erwarte auch eine Gildenlinie dazu newlife

Deine Antwort

14   die antwort
1

um meine Apps durch eine durchdachte Architektur zu verbessern und zu skalieren. Alle oben genannten Vorgehensweisen funktionieren für kleine bis mittlere Apps, schlagen jedoch fehl, wenn Sie in einem größeren Team arbeiten. Es gibt verschiedene Möglichkeiten, die ich ausprobiert habe:

1) Ich folgte dieser Strategie:https://github.com/aldeed/meteor-autoform Vorlagen skalieren und wiederverwenden. Der Autor hat eine sehr gute Vorstellung von Komponenten- und Felddesign. Ich implementiere es derzeit, weil die Community 36 Pakete entwickelt hat, die fast jeden Fall abdecken und die ich verwenden kannTyposkript während der Entwicklungsphase typsicher zu sein.

<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>

Hier ist ein guter Blog-Beitrag dazu:http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ sowie hier:http://meteorpedia.com/read/Blaze_Notes

2) Dieser sieht so vielversprechend aus, wurde aber in letzter Zeit nicht aktualisiert. Es ist ein in Kaffeeskript geschriebenes Paket namens. Blaze-Komponenten (https://github.com/peerlibrary/meteor-blaze-components) für Meteor sind ein System zum einfachen Entwickeln komplexer UI-Elemente, die rund um Ihre Meteor-App wiederverwendet werden müssen. Sie können sie in CoffeeScript, Vanilla JavaScript und ES6 verwenden. Das Beste ist, Komponenten sind OOP. Hier ist eines ihrer Beispiele:

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) Ich mag Typen und Transpiler, die mir sagen, wo und wann etwas schief geht. Ich verwende TypeScript für die Arbeit mit Meteor und habe folgendes Repository gefunden:https://github.com/dataflows/meteor-typescript-utils Es scheint, als hätte der Schöpfer versucht, einen MVC-Ansatz zu erreichen.

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>

Leider wird dieses Projekt nicht gepflegt oder aktiv weiterentwickelt.

4) und ich denke, das wurde bereits erwähnt, können Sie mit Paketen skalieren. Das erfordert eine gute abstrakte Denkweise. Es scheint für Telescope zu funktionieren:https://github.com/TelescopeJS/Telescope

5)Meteor-Template-Erweiterung - bietet verschiedene Möglichkeiten zum Kopieren von Vorlagenhelfern, Ereignishandlern und Hooks zwischen Vorlagen, um die Wiederverwendung von Code zu ermöglichen; Ein Nachteil ist, dass das Kopieren immer wieder von einem Entwickler durchgeführt werden muss, was mit zunehmender Codebasis problematisch wird. Darüber hinaus können ohne eine klar definierte API-Community keine Komponenten erstellt und gemeinsam genutzt werden

6)Durchflusskomponenten - Flow-Komponenten sind im API-Design während näher an ReagierenBlaze-Komponenten halten vertraute Konzepte wie Datenkontexte und Vorlagen-Helfer aufrecht; Flow-Komponenten verwenden weiterhin vorlagenbasierte Ereignishandler, während Blaze-Komponenten sie zu Klassenmethoden machen, damit sie durch Vererbung leichter erweitert oder überschrieben werden können. Im Allgemeinen scheint Blaze Components eher auf OOP ausgerichtet zu sein. Flow Components sind noch nicht offiziell freigegeben (Text Credits für # 5 und # 6https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support)

Nummer 2 und 3 müssen auch gewöhnungsbedürftig sein, aber Sie werden mit der Zeit an Entwicklungsgeschwindigkeit gewinnen. Mit Nummer vier können Sie Komponenten erstellen und testen, um den Code stabiler zu machen. Nummer drei bietet den Vorteil der vollständigen Typensicherheit von Typescript. Dies ist ein großes Plus, wenn Sie sich in einem Team mit unzureichender Dokumentation entwickeln. Momentan portiere ich jedoch die Nummer zwei nach TypeScript, da ich mich sehr wohl fühle, damit zu arbeiten, und ich das Compiler-Paket nicht zwinkern muss, damit es mit Meteor funktioniert, wenn ich Gulp nicht verwende.

Es ist immer noch schwierig, den richtigen Weg für die Arbeit mit Meteor zu finden. Sie müssen es selbst herausfinden, sonst erhalten Sie eine übersichtliche Ordnerstruktur, aber Sie haben keine Ahnung, wo sich alles befindet. Fröhliches Codieren.

26

dass Sie Ihre App so gut wie beliebig strukturieren können. Wenn Ihnen Ihre Struktur nicht gefällt, können Sie eine Datei einfach in ein neues Verzeichnis verschieben oder sogar eine Datei in mehrere Teile aufteilen, und für Meteor ist dies so ziemlich alles. Beachten Sie einfach die Sonderbehandlung von Client-, Server- und öffentlichen Verzeichnissen, wie auf der Hauptdokumentationsseite angegeben:http://docs.meteor.com/.

Nur alles in einer HTML-Füllung zusammenzufassen, wird sich sicherlich nicht als Best Practice herausstellen.

Hier ist ein Beispiel für eine mögliche Struktur: In einer meiner Apps, einem Diskussionsforum, organisiere ich nach Modul oder "Seitentyp" (Startseite, Forum, Thema, Kommentar) und füge für jede Datei eine CSS-, HTML- und JS-Datei ein Seitentyp zusammen in einem Verzeichnis. Ich habe auch ein "Basis" -Modul, das allgemeinen CSS- und JS-Code enthält, und das Master-Template, das je nach Router {{renderPage}} zum Rendern eines der anderen Module verwendet.

<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>

Sie könnten auch nach Funktion organisieren

<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>

Ich hoffe jedoch, dass es einige spezifischere Best-Practice-Strukturen und Namenskonventionen gibt.

Verwandte Dinge sollten in unmittelbarer Nähe zueinander sein. Meine Antwort ist wie deine, aber rückwärts. Max Hodges
Ich mag diese Antwort. Ich habe es auf die erste Art gemacht. Sung Cho
Ich sehe keinen Wert darin, mehrere Dateien mit einem Feature-Namen wie "topic" zu benennen. Wenn Sie nun den Feature-Namen in "Kategorie" ändern möchten, müssen Sie mehrere Dateinamen ändern. Ordnen Sie sie einfach in einem einzigen Ordner mit dem Namen "topic" und geben Sie ihnen einen generischen Namen: events.js, views.html, styles, css, routes.js usw. Weitere Informationen finden Sie in meiner Antwort. Max Hodges
1.3 zapped lib zugunsten von Importenguide.meteor.com/structure.html#example-app-structure Jeremy Iglehart
Das ist meine Lieblingsantwort. Eines meiner Lieblingssachen an Meteor ist, dass Sie Ihre Dateien so strukturieren können, wie es für Sie funktioniert. CaptSaltyJack
36

client/application.js

Benutzen:

client/main.js

main. * Dateien werden zuletzt geladen. Auf diese Weise stellen Sie sicher, dass Sie keine Probleme mit der Ladereihenfolge haben. Siehe die Meteor-Dokumentation,http://docs.meteor.com/#structuringyourapp, für mehr Details.

4

das bereits den Iron Router & Model (Collection2) enthält. Siehe unten :

<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>
15

Lump alles zusammen! Aus den Dokumenten:

<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>
Dies ist jedoch das Anliegen des Posters. Lumping ist in Ordnung, aber Sie können sehen, was mit Asana passiert - es erfordert einen Ladebildschirm, während> 1 MB Client-Code heruntergeladen werden. Das ist für viele Websites nicht akzeptabel. Wir werden sehen, ob wir den Ladevorgang nach dem Laden des Hauptbildschirms möglicherweise nicht stückweise durchführen können, aber ich bin im Moment skeptisch. Ich denke, es muss ein Feature sein, um die Dinge ein wenig aufzubrechen. Dave Sanders
Diese Antwort ist das erste Ergebnis in Google, aber es ist glaubwürdig veraltet. Andere, zukünftige Besucher mögen mich; schau unten! Kloar
@MaxHodges: Re: "Apps, die schneller geladen werden, sind nicht immer besser": Ceteris paribus, das sind sie. ruakh
@dudewad: Das glaube ich nicht. Er scheint zu sagen, dass erhöhte Geschwindigkeit nicht immer eine Verbesserung ist; Zumindest scheint er nicht zu behaupten, dass Asanas Stärken in irgendeiner Weise von seiner relativen Langsamkeit abhängen. ruakh
11

die Dateistruktur aus dem Discover Meteor Book ist wirklich gut und ein solider Anfang.

<code>/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
</code>
Code im Verzeichnis / server wird nur auf dem Server ausgeführt.Code im Verzeichnis / client wird nur auf dem Client ausgeführt.Alles andere läuft sowohl auf dem Client als auch auf dem Server.Dateien in / lib werden vor allem anderen geladen.Alle Hauptdateien (*) werden nach allen anderen geladen.Ihre statischen Elemente (Schriftarten, Bilder usw.) werden im Verzeichnis / public gespeichert.
9
Erstellen Sie Pakete

aber in großen Apps gibt es viele Funktionen, die isoliert werden können. Alles, was trennbar und wiederverwendbar ist, passt in Pakete, der Rest geht in die übliche Verzeichnisstruktur, wie in anderen Antworten erwähnt. Auch wenn Sie keine Pakete erstellen, um den Overhead zu vermeiden, ist es eine gute Idee, den Code modular zu strukturieren (siehediese Vorschläge)

Mit Meteor können Sie genau steuern, wie Sie Ihre Dateien laden (Ladereihenfolge, wo: Client / Server / beides) und was das Paket exportiert.

Besonders praktisch finde ich die einfache Möglichkeit, die Logik zwischen den zugehörigen Dateien zu teilen. Angenommen, Sie möchten eine Util-Funktion erstellen und in verschiedenen Dateien verwenden. Sie machen es einfach "global" (ohne dasvar) und Meteor wird es in den Namespace des Pakets einschließen, damit es den globalen Namespace nicht verschmutzt

Hierist der offizielle doc

273

erklärt es ziemlich genau, wie man eine große App strukturiert:

Wo soll ich meine Dateien ablegen?

Die Beispiel-Apps in meteor sind sehr einfach und bieten keinen großen Einblick. Hier ist meine derzeitige Überlegung, wie dies am besten gemacht werden kann: (Vorschläge / Verbesserungen sind sehr willkommen!)

<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>

Für größere Anwendungen kann die diskrete Funktionalität in Unterverzeichnisse aufgeteilt werden, die nach demselben Muster organisiert sind. Die Idee dabei ist, dass das Funktionsmodul schließlich in ein separates intelligentes Paket zerlegt und im Idealfall gemeinsam genutzt werden kann.

<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>

Finde mehr heraus:Inoffizielle Meteor FAQ

IMHO ist dies besser als akzeptierte Antwort. Ich werde es jetzt versuchen. hakan
@hqt meteor subscribe wird in das für die Vorlage erstellte Abonnement in template.js eingefügt. kpie
Seit Version 0.6.0 ist es weitaus besser, dieses Durcheinander zu vermeiden und Ihre App vollständig ohne intelligente Pakete auszuführen. Ich gehe in diesem Blog-Beitrag etwas genauer auf Folgendes ein:matb33.me/2013/09/05/meteor-project-structure.html matb33
@ Piedpiper Meteor Startup Server Zeug geht in environment.js kpie
14

Dasem Das Kommandozeilen-Tool (von EventedMind, den Jungs hinter dem Iron Router) ist sehr hilfreich beim Aufrüsten einer neuen Meteor-App. Es wird eine schöne Datei- / Ordnerstruktur erstellt. Wenn Sie bereits an einer App arbeiten und diese neu organisieren möchten, richten Sie einfach ein neues Projekt mit einem und Sie können es als Inspiration verwenden.

Sehen:https://github.com/EventedMind/em

Und hier:https://stackoverflow.com/questions/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

Hinweis: Dies wurde durch Iron-Cli (gleicher Autor) ersetzt. Sehen:github.com/iron-meteor/iron-cli j0e
Ja, 'em' wurde in iron-cli umbenannt, dasselbe Tool. Mikael Lirbank
6

die ich nicht mit Meteorjs Programmierung zu tun hatte, bin ich froh, etwas Zeit zu haben, um ein ziemlich komplexes Online-Spiel zu entwickeln. Die App-Struktur war eines meiner ersten Anliegen, und es sieht so aus, als hätten sich einige sehr gute Programmierer für die reine Paket-Strukturierung einer App aus, mit der Sie funktional unterschiedliche Pakete lose koppeln können. Der Ansatz bietet noch weitere Vorteile, und 2 sehr gute Artikel, die den Ansatz erläutern, finden Sie hier:

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

6

Projekte, die je gebaut wurden, da es sich seit 1,5 Jahren in Vollzeitentwicklung befindet). In jeder Ansicht wird derselbe Satz von Dateinamen verwendet. Es ist sehr konsistent und hilft uns, schnell zu genau dem zu navigieren, was wir suchen:

events.jshelpers.jstemplates.htmlroutes.jsstyles.lessusw.

In einem Projekt sieht das so aus:

       ├── 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

Verwandte Vorlagen werden nur zusammen in derselben Datei gespeichert. Inhalt vonview/order/checkout/templates.html hier kollabiert dargestellt:

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

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

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

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

Wir verwenden Unterordner, wenn Ansichten mit vielen Teilen komplex werden:

       ├── 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

Wir entwickeln auch mit WebStorm, einem extrem leistungsstarken und flexiblen Editor für die Meteor-Entwicklung. Wir finden es immens hilfreich, wenn wir unseren Code durchsuchen und organisieren und produktiv arbeiten.

Details teilen wir gerne auf Anfrage mit.

Auf dem Markt sind viele Kesselplatten erhältlich. Die meisten Benutzer zogen es vor, ihren eigenen Weg zu gehen. Jemand hat auch die harte Arbeit gemacht:medium.com/things-i-did-and-learned-today/… Shivam Bajpai
danke, ich schreibe über die Vorgehensweise, die wir gewählt haben! Ich denke, es ist besser, verwandte Dateien zusammen zu halten, so wie wir es tun und solche Ansätze nicht. Max Hodges
Bitte fügen Sie einen Kommentar hinzu, wenn Sie der Meinung sind, dass diese Antwort verbessert werden kann. Max Hodges
Danke für die Rückmeldung. Sie haben die Serverseite auch für Features organisiert? Liko
5

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

einmal installiert. benutzeniron create my-app um ein neues Projekt zu erstellen. Es wird die folgende Struktur für Sie erstellen. Sie können dies auch für vorhandene Projekte verwenden. benutzeniron migrate im Projektverzeichnis.

<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>
@ user2314737 Ruf an, dass der Antwortende seinen Beitrag bearbeitet hat. Es enthält jetzt die wesentlichen Daten, die für das vorliegende Problem benötigt werden. Paul Stenne
Während dieser Link die Frage beantworten kann, ist es besser, die wesentlichen Teile der Antwort hier einzuschließen und den Link als Referenz bereitzustellen. Nur-Link-Antworten können ungültig werden, wenn sich die verlinkte Seite ändert. user2314737
3

Sie zum Beispiel einen Router und verschiedene Seitenvorlagen haben und jede Seitenvorlage viele Seitenteile usw. enthält, würde ich die Struktur von der Semantik der höheren> niedrigeren Ebene abhängig machen.

Zum Beispiel:

<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>

Natürlich können Sie Ihre Nachrichtenvorlagen in den gemeinsamen Ordner stellen, da Sie Ihre Nachrichtenvorlage auch auf verschiedenen Seiten verwenden können.

Ich denke, es ist am besten, wenn Sie Ihre App so strukturieren, wie Sie es möchten.

Ich habe hier eine kleine App geschrieben:http://gold.meteor.com Und es ist so klein, ich verwende nur eine HTML-Datei und nur eine template.js-Datei .. :)

Ich hoffe es hilft ein bisschen

Ich sehe keinen Wert darin, mehrere Dateien mit einem Funktionsnamen wie "Artikel" zu benennen. Wenn Sie nun den Feature-Namen in "Beiträge" ändern möchten, müssen Sie die Dateinamen ändern. Ordnen Sie sie einfach in einem einzigen Ordner mit dem Namen "articles" und nennen Sie sie "events.js", views.html, styles, css usw. Weitere Informationen finden Sie in meiner Antwort. Max Hodges
3

Evented Mind namensEinrichten von Meteorprojekten Das befasst sich mit diesem Problem, spricht aber auch über die Projektkonfiguration und das Einrichten Ihrer Entwicklungsumgebung.

Von demAnwendungsstruktur Video in der Klasse: Meteor ist sich nicht sicher, wie Ihre Anwendung aufgebaut sein soll, aber hier sind einige Regeln:

1) Ladereihenfolge - Meteor wechselt zuerst zur tiefsten Stelle im Dateiverzeichnis und verarbeitet die Dateien in alphabetischer Reihenfolge

2) Client und Server sind spezielle Ordner, die Meteor erkennt

Unsere Struktur sieht so aus:

<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>

Der todos_controller erweitert RouteController, was im Lieferumfang von Iron Router enthalten ist.

Dasem Das oben erwähnte Tool wird derzeit ebenfalls umfassend aktualisiert und sollte viel besser und unter folgender Adresse verfügbar sein:https://github.com/EventedMind/em

Ich sehe keinen Wert darin, mehrere Dateien mit einem Feature-Namen wie "todos" zu benennen. Wenn Sie nun den Funktionsnamen in "Aufgaben" ändern möchten, müssen Sie 5 Dateinamen ändern. Ordnen Sie sie einfach in einem einzigen Ordner mit dem Namen "todos" und nennen Sie sie "events.js", views.html, styles, css usw. Weitere Informationen finden Sie in meiner Antwort. Max Hodges
Was sind die Ansichten in / server / views /? StefanoCudini

Verwandte Fragen