Quali sono le migliori pratiche per strutturare un'app Meteor di grandi dimensioni con molti file modello HTML? [chiuso]


165

In tutti gli esempi (classifica, gioco di parole, ecc.) Hanno un singolo file modello HTML. Esiste un grande progetto Meteor open source con molti file di template HTML diversi che possiamo usare come esempio di best practice? Non sembra pratico mettere tutto in un'app di grandi dimensioni in un unico file modello.


meteora è roba nuova, mi trovo havenot migliori pratiche relative nulla di questo .I si aspettano anche qualche guildline su questo
Newlife

10
Hai letto la parte relativa a Strutturare la tua applicazione nel manuale? C'è qualche spiegazione sulla scansione e la concatenazione di file HTML.
zwippie,

1
La guida ufficiale di Meteor suggerisce una struttura di file molto interessante. Controlla qui: guide.meteor.com/structure.html#javascript-structure
Waqas

Risposte:


16

Unisci tutto insieme! Dai documenti:

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

29
Questa è la preoccupazione del poster. Il rallentamento è ok, ma puoi vedere cosa succede con Asana: richiede una schermata di caricamento mentre scarica> 1 MB di codice client. Questo non è accettabile per molti siti. Vedremo se non riusciamo a fare un po 'di caricamento frammentario dopo il caricamento della schermata principale, ma al momento sono scettico. Penso che dovrà essere una caratteristica per rompere un po 'le cose.
Dave Sanders,

36
Questa risposta è il risultato numero 1 in Google, ma è credibilmente obsoleta. Altri futuri visitatori come me; guarda sotto!
Kloar il

A partire dalla versione 1.1.0.2, la semplice app todo che trasferiscono in demo trasferisce 1,7 MB di file quando si ricarica con la cache del browser rimossa. Questo è inaccettabile per molti casi d'uso là fuori. : / Le cose sono molto migliorate una volta che le risorse sono memorizzate nella cache, ma al primo caricamento è piuttosto brutale.
Jason Kim

Idea: usa il webpack, crea pacchetti per cose, pigri caricali quando necessario.
trusktr,

si Asana impiega del tempo per caricarsi. Asana è anche un'app incredibilmente ben fatta e reattiva in cui gli utenti hanno creato 175 milioni di attività nel 2014. Le app che si caricano più velocemente non sono sempre migliori. Ci vuole un momento anche per l'avvio delle app sul telefono. Le persone si abitueranno.
Max Hodges,

274

Come nella faq meteorica non ufficiale, penso che spieghi praticamente come strutturare una grande app:

Dove devo mettere i miei file?

Le app di esempio in Meteor sono molto semplici e non forniscono molte informazioni. Ecco il mio pensiero attuale sul modo migliore per farlo: (eventuali suggerimenti / miglioramenti sono i benvenuti!)

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)

Per applicazioni più grandi, la funzionalità discreta può essere suddivisa in sottodirectory che sono esse stesse organizzate utilizzando lo stesso modello. L'idea qui è che alla fine il modulo di funzionalità potrebbe essere inserito in un pacchetto intelligente separato e idealmente condiviso.

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

Per saperne di più: Domande frequenti sulle meteore non ufficiali


12
IMHO questo è meglio della risposta accettata. Lo proverò adesso.
Hakan,

17
Dalla 0.6.0, è molto meglio evitare quel casino e far funzionare la tua app completamente dai pacchetti intelligenti. Vado un po 'più in dettaglio in questo post del blog: matb33.me/2013/09/05/meteor-project-structure.html
matb33

1
qualcuno ha idea di dove mettere il mobile-config.js?
Amico,

1
Grazie per la risposta e il collegamento al non ufficiale-faq (sono nuovo nel mondo di meteoriti), cosa intendono per "codice comune di qualcun altro"? Grazie!
Cohars,

3
Per quanto riguarda meteor 1.3, direi che questo è obsoleto a causa dell'importazione del modulo ES6. Vedi l'articolo della guida meteorologica sulla struttura dell'applicazione: guide.meteor.com/structure.html
Samuel,

36

Sono d'accordo con yagooar, ma invece di:

client / application.js

Uso:

client / main.js

i file principali. * vengono caricati per ultimi. Ciò contribuirà a garantire che non si verifichino problemi con l'ordine di caricamento. Consulta la documentazione di Meteor, http://docs.meteor.com/#structuringyourapp , per maggiori dettagli.


26

Meteor è stato progettato in modo da strutturare la tua app praticamente come desideri. Quindi, se non ti piace la tua struttura, puoi semplicemente spostare un file in una nuova directory o persino dividere un file in molti pezzi, e Meteor è praticamente lo stesso. Basta notare il trattamento speciale di client, server e directory pubbliche come specificato nella pagina della documentazione principale: http://docs.meteor.com/ .

Raggruppare tutto insieme in un unico riempimento HTML non emergerà certamente come best practice.

Ecco un esempio di una possibile struttura: in una delle mie app, un forum di discussione, organizzo per modulo o "tipo di pagina" (home, forum, argomento, commento), inserendo i file .css, .html e .js per ciascuno tipo di pagina insieme in una directory. Ho anche un modulo "base", che contiene il codice .css e .js comune e il modello principale, che utilizza {{renderPage}} per eseguire il rendering di uno degli altri moduli a seconda del router.

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

Puoi anche organizzare per funzione

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

Spero tuttavia che emergano alcune strutture di best practice e convenzioni di denominazione più specifiche.


2
Questa è la mia risposta preferita Una delle mie cose preferite di Meteor è che puoi strutturare i tuoi file in un modo che funzioni per te.
CaptSaltyJack

Mi piace questa risposta. L'ho fatto nel primo modo.
Sung Cho,

le cose correlate dovrebbero essere vicine l'una all'altra. La mia risposta è come la tua ma al contrario.
Max Hodges,

1.3 zapped lib in favore delle importazioni guide.meteor.com/structure.html#example-app-structure
Jeremy Iglehart

non vedo valore nel nominare più file con un nome di funzionalità come "topic". Ora se vuoi cambiare il nome della funzione in "categoria" devi cambiare più nomi di file. Organizzali in un'unica cartella chiamata "topic" e chiamali genericamente: events.js, views.html, stili, css, route.js, ecc. Vedi la mia risposta per ulteriori informazioni.
Max Hodges,

14

Per tutti coloro che cercano su Google questo argomento:

Lo emstrumento da riga di comando (di EventedMind, i ragazzi dietro l'Iron Router) è molto utile per attrezzare una nuova app Meteor. Creerà una bella struttura di file / cartelle. Se lavori già su un'app e desideri riorganizzarla, crea un nuovo progetto eme puoi usarlo come fonte di ispirazione.

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

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


4
Nota: questo è stato sostituito con iron-cli (stesso autore). Vedi: github.com/iron-meteor/iron-cli
j0e

Sì, 'em' è stato ribattezzato iron-cli, stesso strumento.
Mikael Lirbank,

11

Penso che la struttura dei file dal Discover Meteor Book sia davvero buona e un buon inizio.

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • Il codice nella directory / server viene eseguito solo sul server.
  • Il codice nella directory / client viene eseguito solo sul client.
  • Tutto il resto funziona sia sul client che sul server.
  • I file in / lib vengono caricati prima di ogni altra cosa.
  • Qualsiasi file principale. * Viene caricato dopo tutto il resto.
  • Le risorse statiche (caratteri, immagini, ecc.) Vanno nella directory / public.

10

Crea pacchetti

Naturalmente non tutto si adatta a questo approccio, ma nelle grandi app avrai molte funzionalità che possono essere isolate. Qualsiasi cosa separabile e riutilizzabile si adatta ai pacchetti, il resto va nella solita struttura di directory, come menzionato in altre risposte. Anche se non crei pacchetti per evitare il sovraccarico, strutturare il codice in modo modulare è una buona idea (vedi questi suggerimenti )

Meteor consente un controllo approfondito su come caricare i file (ordine di caricamento, dove: client / server / entrambi) e su ciò che il pacchetto esporta.

Trovo particolarmente utile il modo semplice di condividere la logica tra i file correlati. Supponiamo, ad esempio, che tu voglia rendere alcune funzioni util e utilizzarle in file diversi. Lo rendi semplicemente "globale" (senza il var) e Meteor lo avvolgerà nello spazio dei nomi del pacchetto, quindi non inquinerà lo spazio dei nomi globale

Ecco il documento ufficiale


6

Dopo un po 'di tempo fuori dal codice meteorjs, sono felice di avere un po' di tempo libero da dedicare alla costruzione di un gioco online abbastanza complesso. La struttura delle app è stata una delle mie prime preoccupazioni e sembra che molti programmatori molto bravi abbiano sostenuto il metodo del solo pacchetto di strutturare un'app, che consente di accoppiare liberamente pacchetti distinti dal punto di vista funzionale. Ci sono altri vantaggi dell'approccio e qui puoi trovare 2 ottimi articoli che spiegano l'approccio:

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


6

Abbiamo un grande progetto (probabilmente uno dei più grandi progetti Meteor che qualcuno abbia mai realizzato finora, dato che era in sviluppo a tempo pieno per 1,5 anni). Usiamo lo stesso set di nomi di file in ogni vista. È molto coerente e ci aiuta a navigare rapidamente esattamente verso ciò che stiamo cercando:

  • events.js
  • helpers.js
  • templates.html
  • routes.js
  • styles.less
  • eccetera.

Sembra così in un progetto:

       ├── consolidamentoRequests
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routers.js
       │ └── modelli.html
       ├── customerSpoof
       │ └── routers.js
       ├── cruscotto
       │ ├── events.js
       │ ├── helpers.js
       │ ├── onDestroyed.js
       │ ├── onRendered.js
       │ ├── routers.js
       │ └── modelli.html
       ├── emailVerification
       │ ├── events.js
       │ ├── helpers.js
       │ ├── routers.js
       │ └── modelli.html
       ├── caricamento
       │ ├── styles.css
       │ └── modelli.html
       ├── cassetta postale
       │ ├── autoform.js
       │ ├── consolidationRequestConfirmation
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ ├── onCreated.js
       │ │ ├── onRendered.js
       │ │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js

I modelli correlati vengono archiviati insieme nello stesso file. Contenuto di view/order/checkout/templates.htmlmostrato collassato qui:

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

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

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

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

Usiamo le sottocartelle quando le viste diventano complesse con molte parti:

       ├── carrello
       │ ├── 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
       │ └── vista
       │ ├── 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
       │ └── modelli.html

Sviluppiamo anche con WebStorm, un editor estremamente potente e flessibile per lo sviluppo di Meteor. Lo troviamo estremamente utile quando si cerca e organizza il nostro codice e si lavora in modo produttivo. Vista Webstorm

Felice di condividere i dettagli su richiesta.


3
Ti preghiamo di considerare di aggiungere un commento se pensi che questa risposta possa essere migliorata.
Max Hodges,

Ottimo post. Domanda: dopo tutto questo tempo con meteor, lo consiglieresti comunque per grandi progetti, come un e-commerce? Oppure considera l'utilizzo di un framework che può darti più "autonomia" come LoopBack o Happi.
Liko,

adoriamo Meteor e facciamo tutto il nuovo sviluppo in esso. Sfortunatamente non ho abbastanza familiarità con LoopBack o Happi per avere un'opinione.
Max Hodges,

1
I loopback si concentrano sulle API di riposo end-to-end che lo fanno sembrare un framework di sviluppo web tradizionale (come RoR). RoR ha l'API REST corretta, ma riteniamo che Meteor sia in tempo reale.
Max Hodges,

Grazie per il feedback. Hai organizzato anche il lato server per le funzionalità?
Liko,

5

Utilizzare la CLI per ponteggi in ferro-cli. Rende le cose molto facili.

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

una volta installato. utilizzare iron create my-appper creare un nuovo progetto. Creerà la seguente struttura per te. Puoi anche usarlo su progetti esistenti. utilizzare iron migratenella directory del progetto.

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

Sebbene questo collegamento possa rispondere alla domanda, è meglio includere qui le parti essenziali della risposta e fornire il collegamento come riferimento. Le risposte di solo collegamento possono diventare non valide se la pagina collegata cambia.
user2314737

@ user2314737 Shoutout per dire che il risponditore ha modificato il suo post. Ora include i dati essenziali necessari per il problema in questione.
Kyll,

4

Sto seguendo il formato mattdeom boilerplate, che include già il router e il modello in ferro (Collection2). Vedi sotto :

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

3

Esistono molti approcci diversi per strutturare la tua app. Ad esempio, se si dispone di un router e di modelli di pagina diversi e all'interno di ciascun modello di pagina sono presenti molte parti di pagina e così via, la struttura dipende dalla semantica dal livello superiore> inferiore.

Per esempio:

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

Ovviamente, potresti mettere i tuoi modelli di notizie nella cartella comune, in quanto potresti usare il tuo modello di notizie su pagine diverse.

Penso che sia la migliore struttura per l'app in un modo a tuo agio.

Ho scritto una piccola app qui: http://gold.meteor.com Ed è così piccola che utilizzo solo un file html e solo un file template.js .. :)

Spero che aiuti un pochino


non vedo valore nel nominare più file con un nome di funzione come "articoli". Ora se vuoi cambiare il nome della funzione in "post" devi cambiare i nomi dei file. Basta organizzarli in un'unica cartella chiamata "articoli" e denominarli "eventi.js", views.html, stili, CSS, ecc. Vedere la mia risposta per ulteriori informazioni.
Max Hodges,

3

C'è una nuova classe su Evented Mind chiamata Setting Up Meteor Projects che affronta questo problema ma parla anche della configurazione del progetto e della configurazione del tuo ambiente di sviluppo.

Dal video della struttura dell'applicazione nella classe: Meteor non ha un'opinione molto forte su come dovrebbe essere strutturata l'applicazione ma ecco alcune regole:

1) Carica ordine: Meteor va prima nella posizione più profonda nella directory dei file ed elabora i file in ordine alfabetico

2) client e server sono cartelle speciali che Meteor riconosce

La nostra struttura si presenta così:

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 estende RouteController, qualcosa che viene fornito con Iron Router.

Lo emstrumento di cui sopra sta anche ottenendo un grande aggiornamento in questo momento e dovrebbe essere molto meglio e disponibile su: https://github.com/EventedMind/em


cosa sono le visualizzazioni all'interno di / server / views /?
stefcud,

non vedo valore nel nominare più file con un nome di funzionalità come "todos". Ora se vuoi cambiare il nome della funzione in "task" devi cambiare 5 nomi di file. Basta organizzarli in un'unica cartella chiamata "todos" e denominarli "events.js", views.html, stili, CSS, ecc. Vedere la mia risposta per ulteriori informazioni.
Max Hodges,

1

Sto anche cercando le migliori pratiche per migliorare e ridimensionare le mie app attraverso un'architettura ben concepita. Tutte le pratiche sopra menzionate funzionano per app di piccole e medie dimensioni ma falliranno quando lavori in un team più grande. Ci sono diversi modi in cui ho provato:

1) Ho seguito questa strategia: https://github.com/aldeed/meteor-autoform per ridimensionare e riutilizzare i modelli. L'autore ha un'ottima idea sulla progettazione di componenti e campi. Attualmente lo sto implementando perché la community ha sviluppato 36 pacchetti che coprono quasi tutti i casi e posso usare TypeScript per essere sicuro durante la fase di sviluppo.

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

Ecco un buon post sul blog su come farlo: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ e qui: http: // meteorpedia .com / lettura / Blaze_Notes

2) Questo sembra così promettente ma non è stato aggiornato di recente. È un pacchetto scritto in una sceneggiatura del caffè chiamato. I componenti Blaze ( https://github.com/peerlibrary/meteor-blaze-components ) per Meteor sono un sistema per sviluppare facilmente complessi elementi dell'interfaccia utente che devono essere riutilizzati attorno all'app Meteor. Puoi usarli in CoffeeScript, JavaScript vaniglia ed ES6. La cosa migliore è che i componenti sono OOP. Ecco uno dei loro esempi:

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) Mi piacciono i tipi e il transpiler che mi dicono dove e quando qualcosa andrà storto. Sto usando TypeScript per lavorare con Meteor e ho trovato il seguente repository: https://github.com/dataflows/meteor-typescript-utils sembra che il creatore abbia provato a realizzare un approccio 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>

Sfortunatamente, questo progetto non è mantenuto o sviluppato attivamente.

4) e penso che sia già stato menzionato, puoi ridimensionare usando i pacchetti. Ciò richiede un buon modo di pensare astratto. Sembra funzionare per Telescope: https://github.com/TelescopeJS/Telescope

5) meteor-template-extension - offre vari modi per copiare helper di template, gestori di eventi e hook tra template, permettendo il riutilizzo del codice; un aspetto negativo è che tutte le copie devono essere curate da uno sviluppatore, spesso ancora e ancora, il che diventa problematico man mano che cresce la base di codice; inoltre, senza una comunità API chiaramente definita non è possibile creare e condividere componenti

6) Componenti di flusso - I componenti di flusso sono più vicini a React nella progettazione dell'API mentre Blaze Components mantiene concetti familiari come contesti di dati e helper di template; D'altra parte, Flow Components utilizza ancora gestori di eventi basati su template mentre Blaze Components li rende metodi di classe in modo che sia più facile estenderli o sovrascriverli tramite l'ereditarietà; in generale Blaze Components sembra essere più orientato verso OOP; I componenti di flusso non sono ancora ufficialmente rilasciati ( crediti di testo per # 5 e # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )

Anche i numeri 2 e 3 richiedono un po 'di tempo per abituarsi, ma otterrai velocità di sviluppo nel tempo. Il numero quattro consente di creare e testare componenti per rendere il codice più stabile. Il numero tre offre il vantaggio della piena sicurezza del tipo di Typescript, che è un grande vantaggio quando si sviluppa in un team con scarsa documentazione. Tuttavia, sto attualmente eseguendo il porting del numero due su TypeScript perché mi sento molto a mio agio nel lavorarci e non devo modificare il pacchetto del compilatore per farlo funzionare con Meteor quando non sto usando Gulp.

È ancora difficile trovare il modo giusto di lavorare con Meteor. Devi capirlo da solo, altrimenti finisci con una struttura di cartelle ben organizzata, ma non hai idea di dove sia tutto. Buona codifica.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.