Jakie są najlepsze praktyki tworzenia struktury dużej aplikacji Meteor z wieloma plikami szablonów HTML? [Zamknięte]

165

We wszystkich przykładach (liderów, gry słowne itp.) Mają jeden plik szablonu HTML. Czy istnieje duży projekt Meteor typu open source z wieloma różnymi plikami szablonów HTML, których możemy użyć jako przykładu najlepszych praktyk? Umieszczenie wszystkiego, czego potrzebuje duża aplikacja, w jednym pliku szablonu nie wydaje się praktyczne.

meteor Andrew Arrow
źródło
meteor to nowość, nie znalazłem nic związanego z najlepszymi praktykami w tej sprawie. Spodziewam się też jakiejś gildii w tej sprawie
newlife.
10
Czy przeczytałeś część dotyczącą strukturyzacji aplikacji w podręczniku? Istnieje kilka wyjaśnień dotyczących skanowania i łączenia plików HTML.
zwippie
1
Oficjalny przewodnik Meteor sugeruje bardzo fajną strukturę plików. Sprawdź tutaj: guide.meteor.com/structure.html#javascript-structure
Waqas

Odpowiedzi:

16

Połącz to wszystko razem! Z dokumentów:

> 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
źródło
29
To jest jednak zmartwienie plakatu. Wrzucanie jest w porządku, ale możesz zobaczyć, co dzieje się z Asaną - wymaga ekranu ładowania, gdy pobiera> 1 MB kodu klienta. To nie do zaakceptowania w przypadku wielu witryn. Zobaczymy, czy może nie możemy wykonać częściowego ładowania po załadowaniu ekranu głównego, ale jestem teraz sceptyczny. Myślę, że będzie to funkcja, która trochę rozbije.
Dave Sanders
36
Ta odpowiedź jest numerem 1 w Google, ale jest prawdopodobnie nieaktualna. Inni przyszli goście, tacy jak ja; Zobacz poniżej!
Kloar,
Od wersji 1.1.0.2 prosta aplikacja do zrobienia, którą demonstruje, przenosi 1,7 MB plików po twardym przeładowaniu z usuniętą pamięcią podręczną przeglądarki. Jest to niedopuszczalne w wielu przypadkach użycia. : / Rzeczy ulegają znacznej poprawie, gdy zasoby są buforowane, ale przy pierwszym ładowaniu jest to dość brutalne.
Jason Kim
Pomysł: użyj webpacka, twórz paczki na rzeczy, leniwie ładuj je w razie potrzeby.
trusktr
tak Asana ładuje się trochę czasu. Asana to także niesamowicie dobrze wykonana, reaktywna aplikacja, w której użytkownicy utworzyli 175 milionów zadań w 2014 roku. Aplikacje, które ładują się szybciej, nie zawsze są lepsze. Uruchomienie aplikacji również na telefonie może chwilę potrwać. Ludzie się do tego przyzwyczają.
Max Hodges
274

Podobnie jak w nieoficjalnym FAQ dotyczącym meteorytów, myślę, że wyjaśnia on, jak zbudować dużą aplikację:

Gdzie mam umieścić swoje pliki?

Przykładowe aplikacje w meteor są bardzo proste i nie zapewniają zbyt wielu informacji. Oto moje obecne przemyślenia na temat najlepszego sposobu, aby to zrobić: (wszelkie sugestie / ulepszenia są mile widziane!)

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)

W przypadku większych aplikacji funkcje dyskretne można podzielić na podkatalogi, które są zorganizowane według tego samego wzorca. Chodzi o to, że ostatecznie moduł funkcjonalności mógłby zostać uwzględniony w oddzielnym inteligentnym pakiecie i najlepiej udostępniony.

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

Dowiedz się więcej: Nieoficjalne FAQ Meteor

yagooar
źródło
12
IMHO to jest lepsze niż zaakceptowana odpowiedź. Spróbuję teraz.
hakan
17
Od wersji 0.6.0 znacznie lepiej jest unikać tego bałaganu i uruchamiać aplikację całkowicie z inteligentnych pakietów. Bardziej szczegółowo omawiam
matb33
1
ktoś ma wskazówkę, gdzie umieścić mobile-config.js?
Koleś
1
Dzięki za odpowiedź i link do nieoficjalnego-faq (jestem nowy w świecie Meteor), co oznaczają „wspólny kod od kogoś innego”? Dzięki!
Cohars
3
Jeśli chodzi o meteor 1.3, powiedziałbym, że jest on przestarzały ze względu na import modułu ES6. Zobacz artykuł w przewodniku meteorologicznym dotyczący struktury aplikacji: guide.meteor.com/structure.html
Samuel
36

Zgadzam się z yagooar, ale zamiast:

client / application.js

Posługiwać się:

klient / main.js

main. * pliki 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 , aby uzyskać więcej informacji.

pwcremin
źródło
26

Meteor został zaprojektowany w taki sposób, aby ustrukturyzować 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 do Meteor jest prawie tak samo. Zwróć uwagę na specjalne traktowanie katalogów klienta, serwera i katalogów publicznych, jak określono na głównej stronie dokumentacji: http://docs.meteor.com/ .

Samo zgrupowanie wszystkiego razem w jednym wypełnieniu HTML z pewnością nie okaże się najlepszą praktyką.

Oto przykład jednej możliwej struktury: w jednej z moich aplikacji, na forum dyskusyjnym, organizuję według modułu lub „typu strony” (strona główna, forum, temat, komentarz), umieszczając pliki .css, .html i .js dla każdego strony razem w jednym katalogu. Mam również 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.

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

Możesz również organizować według funkcji

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

Mam nadzieję, że pojawią się bardziej szczegółowe struktury najlepszych praktyk i konwencje nazewnictwa.

Jonathan Warden
źródło
2
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 Ci odpowiada.
CaptSaltyJack
Podoba mi się ta odpowiedź. Robiłem to w pierwszy sposób.
Sung Cho,
powiązane rzeczy powinny znajdować się blisko siebie. Moja odpowiedź jest jak twoja, ale wsteczna.
Max Hodges
1.3 zapped lib na korzyść importu guide.meteor.com/structure.html#example-app-structure
Jeremy Iglehart
nie widzę wartości w nazywaniu wielu plików nazwą funkcji, taką jak „temat”. Teraz, jeśli chcesz zmienić nazwę funkcji na „kategorię”, musisz zmienić wiele nazw plików. Po prostu umieść je w jednym folderze o nazwie „topic” i nazwij je ogólnie: events.js, views.html, styles, css, tours.js, itp. Zobacz moją odpowiedź, aby uzyskać więcej informacji.
Max Hodges
14

Dla wszystkich, którzy szukają w Google na ten temat:

emNarzędzie wiersza polecenia (przez EventedMind, faceci za routerem żelaza) jest bardzo pomocne przy takielunku nowy Meteor App. Stworzy ładną strukturę plików / folderów. Jeśli już pracujesz nad aplikacją i chcesz ją zmienić, po prostu skonfiguruj nowy projekt emi możesz wykorzystać go jako inspirację.

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

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

Mikael Lirbank
źródło
4
Uwaga: zostało to zastąpione przez iron-cli (ten sam autor). Zobacz: github.com/iron-meteor/iron-cli
j0e
Tak, nazwa „em” została przemianowana na iron-cli, to samo narzędzie.
Mikael Lirbank
11

Myślę, że struktura plików z Discover Meteor Book jest naprawdę dobra i solidna. 

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • 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 plik main. * Jest ładowany po wszystkim innym.
  • Twoje zasoby statyczne (czcionki, obrazy itp.) Trafiają do katalogu / public.
Almog Koren
źródło
10

Utwórz pakiety

Oczywiście nie wszystko pasuje do tego podejścia, ale w dużych aplikacjach będziesz mieć wiele funkcji, które można izolować. Wszystko, co można oddzielić i wykorzystać ponownie, mieści się w pakietach, reszta przechodzi do zwykłej struktury katalogów, jak wspomniano w innych odpowiedziach. Nawet jeśli nie tworzysz pakietów, aby uniknąć narzutów, struktura kodu w sposób modułowy jest dobrym pomysłem (zobacz te sugestie )

Meteor umożliwia precyzyjną kontrolę nad sposobem ładowania plików (kolejność ładowania, gdzie: klient / serwer / oba) i tym, co pakiet eksportuje.

Szczególnie przydatny jest dla mnie łatwy sposób udostępniania logiki między powiązanymi plikami. Załóżmy na przykład, że chcesz wykonać jakąś funkcję użytkową i używać jej w różnych plikach. Po prostu ustawiasz go jako „globalny” (bez var) i Meteor umieści go w przestrzeni nazw pakietu, więc nie będzie zanieczyszczał globalnej przestrzeni nazw

Oto oficjalny dokument

Bogdan D.
źródło
6

Po chwili oderwania się od kodowania meteorjs, cieszę się, że mam trochę wolnego czasu na stworzenie dość złożonej gry online. Struktura aplikacji była jedną z moich pierwszych zmartwień i wygląda na to, że kilku bardzo dobrych programistów poparło metodę struktury aplikacji obejmującą tylko pakiet, która pozwala na luźne łączenie funkcjonalnie odrębnych pakietów. To 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 -wzór

lukenof dalsze
źródło
6

Mamy duży projekt (prawdopodobnie jeden z największych projektów Meteor, jakie ktokolwiek zbudował do tej pory, ponieważ był rozwijany w pełnym wymiarze przez 1,5 roku). Używamy tego samego zestawu nazw plików w każdym widoku. Jest bardzo spójny i pomaga nam szybko znaleźć dokładnie to, czego szukamy:

  • events.js
  • helpers.js
  • szablony.html
  • route.js
  • style.less
  • itp.

W projekcie wygląda to tak:

       ├── ConsolidationRequests
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routerers.js
       │ └── templates.html
       ├── customerSpoof
       │ └── routerers.js
       ├── deska rozdzielcza
       │ ├── events.js
       │ ├── helpers.js
       │ ├── onDestroyed.js
       │ ├── onRendered.js
       │ ├── routerers.js
       │ └── templates.html
       ├── emailVerification
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routerers.js
       │ └── templates.html
       ├── ładowanie
       │ ├── styles.css
       │ └── templates.html
       ├── skrzynka pocztowa
       │ ├── autoform.js
       │ ├── ConsolidationRequestConfirmation
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onCreated.js
       │ │ ├── onRendered.js
       │ │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js

Powiązane szablony są po prostu przechowywane razem w tym samym pliku. Zawartość view/order/checkout/templates.htmlpokazanego zwiniętego tutaj:

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

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

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

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

Używamy podfolderów, gdy widoki stają się złożone z wieloma częściami:

       ├── koszyk
       │ ├── addItem
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onRendered.js
       │ │ ├── routers.js
       │ │ ├── style.less
       │ │ └── templates.html
       │ ├── kasy
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onRendered.js
       │ │ ├── routers.js
       │ │ └── templates.html
       │ └── widok
       │ ├── 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
       │ ├── routerers.js
       │ ├── style.less
       │ └── templates.html

Tworzymy również za pomocą WebStorm, niezwykle wydajnego i elastycznego edytora do programowania Meteor. Uważamy, że jest to niezwykle pomocne podczas wyszukiwania i organizowania naszego kodu oraz produktywnej pracy. Widok burzy internetowej

Chętnie udostępnię szczegóły na życzenie.

Max Hodges
źródło
3
Jeśli uważasz, że tę odpowiedź można poprawić, rozważ dodanie komentarza.
Max Hodges
Wspaniały post. Pytanie: Po tylu latach spędzonych z meteor, nadal polecasz go do dużych projektów, takich jak e-commerce? Lub rozważ użycie frameworka, który może dać ci większą „autonomię”, jak LoopBack lub nawet Happi.
Liko
kochamy Meteor i rozwijamy w nim wszystkie nowości. Niestety nie jestem wystarczająco zaznajomiony z LoopBack lub Happi, aby mieć opinię.
Max Hodges
1
LoopBacks koncentruje się na kompleksowych interfejsach API reszt, dzięki czemu brzmi jak tradycyjna platforma do tworzenia stron internetowych (jak RoR). RoR ma REST API poprawnie, ale wydaje nam się, że Meteor działa poprawnie w czasie rzeczywistym.
Max Hodges
Dziękujemy za opinię. Zorganizowałeś też stronę serwera pod kątem funkcji?
Liko
5

Użyj interfejsu CLI rusztowania iron-cli. To bardzo ułatwia sprawę.

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

po zainstalowaniu. użyj, iron create my-appaby utworzyć nowy projekt. Stworzy dla Ciebie następującą strukturę. Możesz również użyć tego w istniejących projektach. użyj iron migratew katalogu projektu.

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
źródło
Chociaż ten link może odpowiedzieć na pytanie, lepiej jest zawrzeć tutaj zasadnicze części odpowiedzi i podać link do odniesienia. Odpowiedzi zawierające tylko łącze mogą stać się nieprawidłowe, jeśli połączona strona ulegnie zmianie.
user2314737
@ user2314737 Krzyknij, aby powiedzieć, że osoba odpowiadająca zredagowała swój post. Zawiera teraz podstawowe dane potrzebne do rozpatrzenia sprawy.
Kyll
4

Postępuję zgodnie z formatem mattdeom boilerplate, który zawiera już żelazny router i model (Collection2). Zobacz poniżej:

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
źródło
3

Istnieje wiele różnych podejść do tworzenia struktury aplikacji. Na przykład, jeśli masz router i różne szablony stron, a każdy szablon strony ma wiele części i tak dalej, ustrukturyzowałbym to na podstawie semantyki z wyższego> niższego poziomu.

Na przykład:

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

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

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

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

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

Boris Kotov
źródło
nie widzę wartości w nazywaniu wielu plików nazwami funkcji, takimi jak „artykuły”. Teraz, jeśli chcesz zmienić nazwę funkcji na „posty”, musisz zmienić nazwy plików. Po prostu umieść je w jednym folderze o nazwie „artykuły” i nazwij je „events.js”, views.html, styles, css, itp. Zobacz moją odpowiedź, aby uzyskać więcej informacji.
Max Hodges
3

W Evented Mind pojawiła się nowa klasa o nazwie Setting Up Meteor Projects, która dotyczy tego, ale także mówi o konfiguracji projektu i ustawianiu środowiska programistycznego.

Z filmu o strukturze aplikacji w klasie: Meteor nie ma zbyt mocnej opinii na temat struktury Twojej aplikacji, ale oto kilka reguł:

1) Kolejność ładowania - Meteor najpierw udaje się do najgłębszej lokalizacji 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 następująco:

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/

Todos_controller rozszerza RouteController, coś, co jest dostarczane z Iron Router.

emNarzędzie wspomniano powyżej jest również uzyskanie dużego aktualizację już teraz, a powinno być o wiele lepiej i dostępna pod adresem: https://github.com/EventedMind/em

katogeaver
źródło
jakie są widoki wewnątrz / server / views /?
stefcud
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ć nazwy 5 plików. Po prostu umieść je w jednym folderze o nazwie „todos” i nazwij je „events.js”, views.html, styles, css, itd. Zobacz moją odpowiedź, aby uzyskać więcej informacji.
Max Hodges
1

Szukam również najlepszych praktyk, aby ulepszyć i skalować moje aplikacje za pomocą dobrze przemyślanej architektury. Wszystkie powyższe praktyki sprawdzają się w przypadku małych i średnich aplikacji, ale zawodzą, gdy pracujesz w większym zespole. Próbowałem na kilka sposobów:

1) Postępowałem zgodnie z tą strategią: https://github.com/aldeed/meteor-autoform, aby skalować i ponownie wykorzystywać szablony. Autor ma bardzo dobry pomysł na projektowanie komponentów i terenów. Obecnie wdrażam go, ponieważ społeczność opracowała 36 pakietów, które obejmują prawie każdy przypadek i mogę używać TypeScript, aby zachować bezpieczeństwo pisania na etapie 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/ oraz tutaj: http: // meteorpedia .com / read / Blaze_Notes

2) Ten wygląda tak obiecująco, ale ostatnio nie był aktualizowany. Jest to pakiet napisany w skrypcie kawowym o nazwie. Komponenty Blaze ( https://github.com/peerlibrary/meteor-blaze-components ) dla Meteor to system do łatwego tworzenia złożonych elementów UI, które muszą być ponownie użyte w Twojej 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 wygląda na to, ż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. To wymaga dobrego abstrakcyjnego sposobu myślenia. Wydaje się, że działa dla Telescope: https://github.com/TelescopeJS/Telescope

5) rozszerzenie meteor-template - zapewnia różne sposoby kopiowania pomocników szablonów, programów obsługi zdarzeń i hooków między szablonami, umożliwiając ponowne użycie kodu; Wadą jest to, że wszelkie kopiowanie musi być wykonywane przez programistę, często w kółko, co staje się problematyczne wraz ze wzrostem bazy kodu; ponadto bez jasno zdefiniowanej społeczności API nie można tworzyć i udostępniać komponentów

6) Komponenty Flow - Komponenty Flow są bliżej Reacta w projekcie API, podczas gdy Komponenty Blaze zachowują znane pojęcia, takie jak konteksty danych i pomoce szablonów; Z drugiej strony, komponenty Flow nadal używają programów obsługi zdarzeń opartych na szablonach, podczas gdy składniki Blaze sprawiają, że są one metodami klasowymi, dzięki czemu łatwiej jest je rozszerzać lub zastępować poprzez dziedziczenie; generalnie komponenty Blaze wydają się być bardziej zorientowane na OOP; Komponenty Flow nie zostały jeszcze oficjalnie wydane ( kredyty tekstowe dla nr 5 i nr 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )

Numery 2 i 3 również wymagają przyzwyczajenia, ale z czasem przyspieszysz rozwój. Numer cztery pozwala budować i testować komponenty, aby uczynić kod bardziej stabilnym. Numer trzy ma tę zaletę, że typescript zapewnia pełne bezpieczeństwo typów, co jest ogromnym plusem, gdy tworzysz w zespole ze słabą dokumentacją. Jednak obecnie przenoszę numer dwa na TypeScript, ponieważ czuję się bardzo komfortowo z nim pracować i nie muszę dostosowywać pakietu kompilatora, aby działał z Meteor, gdy nie używam Gulp.

Wciąż ciężko jest znaleźć właściwy sposób pracy z Meteor. Musisz sam to rozgryźć, w przeciwnym razie otrzymasz ładnie ułożoną strukturę folderów, ale nie masz pojęcia, gdzie wszystko jest. Miłego kodowania.

MichelH
źródło