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.) gibt es 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, alles, was eine große App benötigt, in einer Vorlagendatei zusammenzufassen.

meteor Andrew Arrow
quelle
Meteor ist neues Zeug, ich habe keine verwandten Best Practices dazu gefunden. Ich erwarte auch eine Gildenlinie darüber
Newlife
10
Haben Sie den Teil über die Strukturierung Ihrer Anwendung im Handbuch gelesen ? Es gibt einige Erklärungen zum Scannen und Verketten von HTML-Dateien.
Zwippie
1
Der offizielle Meteor-Leitfaden schlägt eine sehr coole Dateistruktur vor. Überprüfen Sie hier: guide.meteor.com/structure.html#javascript-structure
Waqas

Antworten:

16

Alles zusammen! Aus den Dokumenten:

> 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.
mdgrech
quelle
29
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 nach dem Laden des Hauptbildschirms möglicherweise einen Teil des Ladevorgangs nicht durchführen können, aber ich bin im Moment skeptisch. Ich denke, es muss eine Funktion sein, um die Dinge ein wenig aufzubrechen.
Dave Sanders
36
Diese Antwort ist das beste Ergebnis in Google, aber glaubwürdig veraltet. Andere, zukünftige Besucher wie ich; schau unten!
Kloar
Ab 1.1.0.2 überträgt die einfache ToDo-App, die sie vorführen, 1,7 MB Dateien, wenn Sie sie bei entferntem Browser-Cache neu laden. Dies ist für viele Anwendungsfälle nicht akzeptabel. : / Sobald die Assets zwischengespeichert sind, werden die Dinge erheblich verbessert, aber beim ersten Laden ist es ziemlich brutal.
Jason Kim
Idee: Verwenden Sie ein Webpack, erstellen Sie Bundles für Dinge und laden Sie sie bei Bedarf faul.
Trusktr
Ja, Asana braucht einige Zeit zum Laden. Asana ist auch eine unglaublich gut gemachte, reaktive App, in der Benutzer 2014 175 Millionen Aufgaben erstellt haben. Apps, die schneller geladen werden, sind nicht immer besser. Es dauert einen Moment, bis Apps auch auf Ihrem Telefon gestartet werden. Die Leute werden sich daran gewöhnen.
Max Hodges
274

Wie in der inoffiziellen Meteor-FAQ erklärt es meiner Meinung nach 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 nicht viel Einblick. Hier ist meine aktuelle Überlegung, wie ich es am besten machen kann: (Vorschläge / Verbesserungen sind sehr willkommen!)

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)

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

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

Erfahren Sie mehr: Inoffizielle Meteor-FAQ

yagooar
quelle
12
IMHO ist dies besser als akzeptierte Antwort. Ich werde es jetzt versuchen.
Hakan
17
Seit 0.6.0 ist es weitaus besser, dieses Durcheinander zu vermeiden und Ihre App vollständig aus intelligenten Paketen heraus auszuführen. Ich gehe in diesem Blog-Beitrag etwas detaillierter auf: matb33.me/2013/09/05/meteor-project-structure.html
matb33
1
Hat jemand eine Ahnung, wo er das hinstellen soll mobile-config.js?
Typ
1
Vielen Dank für die Antwort und den Link zur inoffiziellen FAQ (ich bin neu in der Meteoritenwelt). Was meinen sie mit "allgemeinem Code von jemand anderem"? Danke!
Cohars
3
Was Meteor 1.3 betrifft, würde ich sagen, dass dies aufgrund des Imports von ES6-Modulen veraltet ist. Siehe Meteor Guide Artikel über die Anwendungsstruktur: guide.meteor.com/structure.html
Samuel
36

Ich stimme yagooar zu, aber statt:

client / application.js

Verwenden:

client / main.js

main. * Dateien werden zuletzt geladen. Auf diese Weise stellen Sie sicher, dass Sie keine Probleme mit der Ladereihenfolge haben. Weitere Informationen finden Sie in der Meteor-Dokumentation unter http://docs.meteor.com/#structuringyourapp .

pwcremin
quelle
26

Meteor wurde so konzipiert, dass Sie Ihre App so strukturieren können, wie Sie möchten. 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 das so ziemlich alles. Beachten Sie einfach die spezielle Behandlung von Client-, Server- und öffentlichen Verzeichnissen, wie auf der Hauptdokumentationsseite angegeben: http://docs.meteor.com/ .

Nur alles in einer HTML-Füllung zusammenzufassen, wird sicherlich keine bewährte Methode sein.

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 setze jeweils CSS-, HTML- und JS-Dateien Seitentyp zusammen in einem Verzeichnis. Ich habe auch ein "Basismodul", das allgemeinen CSS- und JS-Code enthält, und die Master-Vorlage, die je nach Router {{renderPage}} verwendet, um eines der anderen Module zu rendern.

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

Sie können auch nach Funktionen organisieren

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

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

Jonathan Warden
quelle
2
Das ist meine Lieblingsantwort. Eine meiner Lieblingssachen bei Meteor ist, dass Sie Ihre Dateien so strukturieren können, wie es für Sie funktioniert.
CaptSaltyJack
Ich mag diese Antwort. Ich habe es auf die erste Weise gemacht.
Sung Cho
verwandte Dinge sollten nahe beieinander sein. Meine Antwort ist wie deine, aber rückwärts.
Max Hodges
1.3 zapped lib zugunsten von Importen guide.meteor.com/structure.html#example-app-structure
Jeremy Iglehart
Ich sehe keinen Wert darin, mehrere Dateien mit einem Feature-Namen wie "Thema" zu benennen. Wenn Sie nun den Funktionsnamen in "Kategorie" ändern möchten, müssen Sie mehrere Dateinamen ändern. Organisieren Sie sie einfach in einem einzigen Ordner namens "Thema" und benennen Sie sie generisch: events.js, views.html, Stile, CSS, Routen.js usw. Weitere Informationen finden Sie in meiner Antwort.
Max Hodges
14

Für alle, die zu diesem Thema googeln:

Das emKommandozeilen-Tool (von EventedMind, den Leuten hinter dem Iron Router) ist sehr hilfreich beim Riggen 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 ein emund Sie können es als Inspiration verwenden.

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

Und hier: /programming/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

Mikael Lirbank
quelle
4
Hinweis: Dies wurde durch iron-cli (gleicher Autor) ersetzt. Siehe: github.com/iron-meteor/iron-cli
j0e
Ja, 'em' wurde in iron-cli umbenannt, dasselbe Tool.
Mikael Lirbank
11

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

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • 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.
  • Jede Hauptdatei. * Wird nach allem anderen geladen.
  • Ihre statischen Assets (Schriftarten, Bilder usw.) befinden sich im Verzeichnis / public.
Almog Koren
quelle
10

Erstellen Sie Pakete

Natürlich passt nicht alles in diesen Ansatz, 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 eine modulare Strukturierung des Codes eine gute Idee (siehe diese Vorschläge) ).

Meteor ermöglicht eine detaillierte Kontrolle darüber, wie Sie Ihre Dateien laden (Ladereihenfolge, wo: Client / Server / beides) und was das Paket exportiert.

Ich finde es besonders praktisch, die Logik auf einfache Weise 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 das var) und Meteor wird es in den Namespace des Pakets einschließen, damit es den globalen Namespace nicht verschmutzt

Hier ist das offizielle Dokument

Bogdan D.
quelle
6

Nach einer Weile ohne Meteorjs-Codierung 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 mehrere sehr gute Programmierer für die reine Paketmethode zur Strukturierung einer App ausgesprochen, mit der Sie funktional unterschiedliche Pakete lose koppeln können. Der Ansatz bietet weitere Vorteile, und zwei 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 -Muster

lukenofurther
quelle
6

Wir haben ein großes Projekt (wahrscheinlich eines der größten Meteor-Projekte, die jemals gebaut wurden, da es 1,5 Jahre lang in Vollzeit entwickelt wurde). Wir verwenden in jeder Ansicht den gleichen Satz von Dateinamen. Es ist sehr konsistent und hilft uns, schnell zu genau dem zu navigieren, wonach wir suchen:

  • events.js
  • helpers.js
  • templates.html
  • route.js
  • Styles.less
  • etc.

Sieht in einem Projekt so aus:

       ├── Konsolidierungsanforderungen
       │ ├ events.js
       │ ├ helpers.js
       │ ├ routers.js
       │ └ templates.html
       ├── customerSpoof
       │ └ routers.js
       ├── Dashboard
       │ ├ events.js
       │ ├ helpers.js
       │ ├ onDestroyed.js
       │ ├ onRendered.js
       │ ├ routers.js
       │ └ templates.html
       ├── E-Mail-Überprüfung
       │ ├ events.js
       │ ├ helpers.js
       │ ├ routers.js
       │ └ templates.html
       ├── Laden
       │ ├ styles.css
       │ └ templates.html
       ├── Mailbox
       │ ├ autoform.js
       │ ├ KonsolidierungRequestConfirmation
       │ │ ├ events.js
       │ │ ├ help help helpers.js
       │ │ ├ onCreated.js
       │ │ ├── onRendered.js
       │ │ └ templates.html
       │ ├ events.js
       │ ├ helpers.js

Verwandte Vorlagen werden nur zusammen in derselben Datei gespeichert. Inhalt der view/order/checkout/templates.htmlgezeigten hier zusammengebrochen:

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

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

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

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

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

       ├── Wagen
       │ ├ addItem
       Oform │ ├ autoform.js
       │ │ ├ events.js
       │ │ ├ help help helpers.js
       │ │ ├── onRendered.js
       │ │ ├ routers.js
       │ │ ├─yles styles.less
       │ │ └ templates.html
       │ ├ Kasse
       Oform │ ├ autoform.js
       │ │ ├ events.js
       │ │ ├ help help helpers.js
       │ │ ├── onRendered.js
       │ │ ├ routers.js
       │ │ └ templates.html
       │ └ Ansicht
       │ ├ autoform.js
       │ ├ deleteItem
       │ │ ├ events.js
       │ │ ├ help help helpers.js
       │ │ └ templates.html
       │ ├ editItem
       Oform │ ├ autoform.js
       │ │ ├ events.js
       │ │ ├ help help helpers.js
       │ │ └ templates.html
       │ ├ events.js
       │ ├ helpers.js
       │ ├ onDestroyed.js
       │ ├ onRendered.js
       │ ├ routers.js
       │ ├ styles.less
       │ └ templates.html

Wir entwickeln auch mit WebStorm, einem äußerst leistungsstarken und flexiblen Editor für die Meteor-Entwicklung. Wir finden es sehr hilfreich, wenn wir unseren Code suchen, organisieren und produktiv arbeiten. Webstorm-Ansicht

Gerne teilen wir Ihnen Details auf Anfrage mit.

Max Hodges
quelle
3
Bitte fügen Sie einen Kommentar hinzu, wenn Sie der Meinung sind, dass diese Antwort verbessert werden kann.
Max Hodges
Guter Eintrag. Frage: Nach all der Zeit mit Meteor empfehlen Sie es immer noch für große Projekte wie einen E-Commerce? Oder verwenden Sie ein Framework, das Ihnen möglicherweise mehr "Autonomie" als LoopBack oder sogar Happi bietet.
Liko
Wir lieben Meteor und entwickeln alles neu darin. Leider bin ich mit LoopBack oder Happi nicht vertraut genug, um eine Meinung zu haben.
Max Hodges
1
LoopBacks konzentrieren sich auf End-to-End-Rest-APIs und lassen es wie ein traditionelles Webentwicklungs-Framework (wie RoR) klingen. RoR hat die REST-API richtig eingestellt, aber wir glauben, dass Meteor die Echtzeit richtig eingestellt hat.
Max Hodges
Danke für die Rückmeldung. Sie haben die Serverseite auch für Funktionen organisiert?
Liko
5

Verwenden Sie ein Eisen-Cli-Gerüst CLI. Macht die Dinge sehr einfach.

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

einmal installiert. Verwenden Sie iron create my-appdiese Option, um ein neues Projekt zu erstellen. Es wird die folgende Struktur für Sie erstellt. Sie können dies auch für vorhandene Projekte verwenden. Verwendung iron migrateim Projektverzeichnis.

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
ravish.hacker
quelle
Während dieser Link die Frage beantworten kann, ist es besser, die wesentlichen Teile der Antwort hier aufzunehmen und den Link als Referenz bereitzustellen. Nur-Link-Antworten können ungültig werden, wenn sich die verknüpfte Seite ändert.
user2314737
@ user2314737 Shoutout, um zu sagen, dass der Antwortende seinen Beitrag bearbeitet hat. Es enthält jetzt die wesentlichen Daten, die für das jeweilige Problem benötigt werden.
Kyll
4

Ich folge dem Mattdeom Boilerplate-Format, das bereits den Iron Router & Model (Collection2) enthält. Siehe unten :

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 all 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
Rudy
quelle
3

Es gibt viele verschiedene Ansätze zur Strukturierung Ihrer App. Wenn Sie zum Beispiel einen Router und verschiedene Seitenvorlagen haben und in jeder Seitenvorlage viele Seitenteile usw. vorhanden sind, würde ich dies abhängig von der Semantik von höherer> niedrigerer Ebene strukturieren.

Beispielsweise:

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

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

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

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

Ich hoffe es hilft ein bisschen

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

In Evented Mind gibt es eine neue Klasse namens Einrichten von Meteorprojekten , die sich mit diesem Thema befasst , aber auch über die Projektkonfiguration und das Einrichten Ihrer Entwicklungsumgebung spricht.

Aus dem Video zur Anwendungsstruktur in der Klasse: Meteor hat keine sehr starke Meinung darüber, wie Ihre Anwendung strukturiert sein sollte, 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 folgendermaßen aus:

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/

Der todos_controller erweitert den RouteController, der mit Iron Router geliefert wird.

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

Katogeaver
quelle
Was sind Ansichten in / server / views /?
Stefcud
Ich sehe keinen Wert darin, mehrere Dateien mit einem Funktionsnamen wie "todos" zu benennen. Wenn Sie nun den Funktionsnamen in "Aufgaben" ändern möchten, müssen Sie 5 Dateinamen ändern. Organisieren 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
1

Ich suche auch nach Best Practices, um meine Apps durch eine gut 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. Ich habe verschiedene Möglichkeiten ausprobiert:

1) Ich habe diese Strategie verfolgt: https://github.com/aldeed/meteor-autoform , um Vorlagen zu skalieren und wiederzuverwenden. Der Autor hat eine sehr gute Idee zum Komponenten- und Felddesign. Ich implementiere es derzeit, weil die Community 36 Pakete entwickelt hat, die fast jeden Fall abdecken, und ich TypeScript verwenden kann , um 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 zur einfachen Entwicklung komplexer Benutzeroberflächenelemente, 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 gehen wird. Ich verwende TypeScript für die Arbeit mit Meteor und habe das folgende Repository gefunden: https://github.com/dataflows/meteor-typescript-utils Es scheint, als hätte der Ersteller 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 schon erwähnt, man kann 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 Vorlagen-Helfern, Ereignishandlern und Hooks zwischen Vorlagen, um die Wiederverwendung von Code zu ermöglichen. Ein Nachteil ist, dass das Kopieren häufig von einem Entwickler durchgeführt werden muss, was immer wieder problematisch wird, wenn die Codebasis wächst. Darüber hinaus können ohne eine klar definierte API-Community keine Komponenten erstellt und gemeinsam genutzt werden

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

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

Es ist immer noch schwierig, den richtigen Weg zu finden, um mit Meteor zu arbeiten. Sie müssen es selbst herausfinden, sonst erhalten Sie eine übersichtliche Ordnerstruktur, aber Sie haben keine Ahnung, wo sich alles befindet. Viel Spaß beim Codieren.

MichelH
quelle