Каковы лучшие практики для структурирования большого приложения Meteor с большим количеством файлов шаблонов HTML? [закрыто]

165

Во всех примерах (таблица лидеров, игра слов и т. Д.) У них есть один файл шаблона HTML. Есть ли какой-нибудь крупный проект с открытым исходным кодом Meteor с множеством различных файлов HTML-шаблонов, который мы можем использовать в качестве примера лучшей практики? Не кажется практичным поместить все, что нужно большому приложению, в один файл шаблона.

meteor Эндрю Стрелка
источник
Метеор - это новый материал, я не нашел ничего, связанного с этой передовой практикой. Я также ожидаю некоторой гильдии об этом
newlife
10
Читали ли вы часть о структурировании вашего приложения в руководстве? Существует некоторое объяснение о сканировании и объединении файлов HTML.
zwippie
1
Официальное руководство Meteor предлагает очень классную файловую структуру. Проверьте здесь: guide.meteor.com/structure.html#javascript-structure
Вакас

Ответы:

16

Все это вместе! Из документов:

> 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
источник
29
Это забота автора, хотя. Лампинг в порядке, но вы можете видеть, что происходит с Asana - для этого требуется экран загрузки, пока он загружает> 1 МБ клиентского кода. Это не приемлемо для многих сайтов. Мы посмотрим, не сможем ли мы выполнить часть загрузки после загрузки основного экрана, но сейчас я настроен скептически. Я думаю, что это будет особенность, чтобы немного расколоть вещи.
Дейв Сандерс
36
Этот ответ - результат № 1 в Google, но он значительно устарел. Другие, будущие посетители, как я; Смотри ниже!
Kloar
Начиная с 1.1.0.2, простое приложение todo, которое они демонстрируют, передает 1,7 МБ файлов, когда вы перезагружаете компьютер без удаленного кэша браузера. Это неприемлемо для многих случаев использования. : / Вещи значительно улучшаются после кэширования ресурсов, но при первой загрузке это довольно жестоко.
Джейсон Ким
Идея: использовать веб-пакеты, делать пакеты для вещей, лениво загружать их при необходимости.
trusktr
да Асана загружается некоторое время. Асана также невероятно хорошо сделанное, реагирующее приложение, в котором пользователи создали 175 миллионов задач в 2014 году. Приложения, которые загружаются быстрее, не всегда лучше. Запуск приложений на вашем телефоне также занимает некоторое время. Люди привыкнут к этому.
Макс Ходжес
274

Как и в неофициальном часто задаваемом вопросе о метеоре, я думаю, что это в значительной степени объясняет, как структурировать большое приложение:

Где я должен положить мои файлы?

Примеры приложений в meteor очень просты и не дают много понимания. Вот мое текущее мнение о лучшем способе сделать это: (любые предложения / улучшения очень приветствуются!)

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)

Для более крупных приложений дискретная функциональность может быть разбита на подкаталоги, которые сами организованы с использованием одного и того же шаблона. Идея заключается в том, что в конечном итоге функциональный модуль может быть выделен в отдельный интеллектуальный пакет и в идеале может использоваться совместно.

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

Узнайте больше: неофициальный метеор FAQ

yagooar
источник
12
ИМХО это лучше, чем принятый ответ. Я попробую это сейчас.
Хакан
17
Начиная с версии 0.6.0, вам гораздо лучше избегать этого беспорядка и полностью запускать свое приложение из интеллектуальных пакетов. Я немного подробнее расскажу об
matb33
1
кто-нибудь есть ключ, где поставить mobile-config.js?
Чувак
1
Спасибо за ответ и ссылку на неофициальный FAQ (я новичок в мире метеоров), что они имеют в виду под «общим кодом от кого-то еще»? Спасибо!
Cohars
3
Что касается метеора 1.3, я бы сказал, что он устарел из-за импорта модуля ES6. См. Статью метеорологического
Самуил
36

Я согласен с yagooar, но вместо:

клиент / application.js

Использование:

клиент / main.js

Файлы main. * загружаются последними. Это поможет вам избежать проблем с порядком загрузки. См. Документацию по Meteor, http://docs.meteor.com/#structuringyourapp , для получения более подробной информации.

pwcremin
источник
26

Meteor был разработан так, чтобы вы структурировали свое приложение практически так, как вам хочется. Так что, если вам не нравится ваша структура, вы можете просто переместить файл в новый каталог или даже разбить один файл на несколько частей, и в Meteor он практически одинаковый. Просто обратите внимание на особую обработку клиентских, серверных и общедоступных каталогов, как указано на главной странице документации: http://docs.meteor.com/ .

Простое объединение всего в одну HTML-заливку, безусловно, не станет лучшей практикой.

Вот пример одной из возможных структур: в одном из моих приложений, на дискуссионном форуме, я организовываю по модулю или «типу страницы» (домашняя страница, форум, тема, комментарий), помещая файлы .css, .html и .js для каждого Тип страницы вместе в одном каталоге. У меня также есть «базовый» модуль, который содержит общий код .css и .js и главный шаблон, который использует {{renderPage}} для визуализации одного из других модулей в зависимости от маршрутизатора.

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

Вы также можете организовать по функциям

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

Я надеюсь, что появятся некоторые более конкретные структуры наилучшей практики и соглашения об именах.

Джонатан Уорден
источник
2
Это мой любимый ответ. Одна из моих любимых вещей в Meteor - это то, что вы можете структурировать свои файлы так, как вам удобно.
CaptSaltyJack
Мне нравится этот ответ. Я делал это первым способом.
Сон Чо
связанные вещи должны быть в непосредственной близости друг от друга. Мой ответ как твой, но задом наперед.
Макс Ходжес
1.3 зарезервирован lib в пользу импорта guide.meteor.com/structure.html#example-app-structure
Джереми Иглхарт
Я не вижу смысла в названии нескольких файлов с именем функции, например, «тема». Теперь, если вы хотите изменить имя функции на «категорию», вам нужно изменить несколько имен файлов. Просто организуйте их в одну папку с именем "topic" и присвойте им общее название: events.js, views.html, styles, css, rout.js и т. Д., См. Мой ответ для получения дополнительной информации.
Макс Ходжес
14

Для всех, кто гуглит на эту тему:

Инструмент emкомандной строки (от EventedMind, парни из Iron Router) очень полезен при установке нового приложения Meteor. Это создаст хорошую структуру файлов / папок. Если вы уже работаете над приложением и хотите реорганизовать его, просто создайте новый проект emи вы можете использовать его для вдохновения.

Смотрите: https://github.com/EventedMind/em

И здесь: /programming/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

Микаэль Лирбанк
источник
4
Примечание: это было заменено Iron-Cli (тот же автор). Смотрите: github.com/iron-meteor/iron-cli
j0e
Да, 'em' был переименован в iron-cli, тот же инструмент.
Микаэль Лирбанк
11

Я думаю, что файловая структура из Книги Обнаружения Метеора действительно хороша и хорошее начало. 

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • Код в каталоге / server работает только на сервере.
  • Код в каталоге / client работает только на клиенте.
  • Все остальное работает как на клиенте, так и на сервере.
  • Файлы в / lib загружаются раньше всего.
  • Любой основной. * Файл загружается после всего остального.
  • Ваши статические ресурсы (шрифты, изображения и т. Д.) Помещаются в каталог / public.
Альмог Корен
источник
10

Создавать пакеты

Конечно, не все подходит для этого подхода, но в больших приложениях у вас будет много функций, которые можно изолировать. Все, что можно разделить и использовать повторно, помещается в пакеты, остальное идет в обычной структуре каталогов, как упоминалось в других ответах. Даже если вы не создаете пакеты, чтобы избежать накладных расходов, хорошая идея структурировать код модульным способом (см. Эти предложения ).

Meteor позволяет детально контролировать то, как вы загружаете свои файлы (порядок загрузки, где: клиент / сервер / оба) и что экспортирует пакет.

Я особенно нахожу очень удобным простой способ разделить логику между соответствующими файлами. Скажем, например, вы хотите сделать некоторую функцию утилит и использовать ее в разных файлах. Вы просто делаете его «глобальным» (без var), и Meteor обернет его в пространство имен пакета, чтобы он не загрязнил глобальное пространство имен.

Вот официальный документ

Богдан Д
источник
6

Через некоторое время после кодирования метеоритов, я рад, что у меня есть свободное время, чтобы посвятить себя созданию довольно сложной онлайн-игры. Структура приложения была одной из моих первых проблем, и похоже, что несколько очень хороших программистов отстаивали метод структурирования приложения, основанный только на пакетах, который позволяет вам свободно объединять функционально разные пакеты. У этого подхода есть и другие преимущества, и здесь можно найти 2 очень хорошие статьи, объясняющие подход:

http://www.matb33.me/2013/09/05/meteor-project-structure.html http://www.manuel-schoebel.com/blog/meteorjs-package-only-app-structure-with-mediator -шаблон

lukenofurther
источник
6

У нас есть крупный проект (возможно, один из крупнейших проектов Метеор, который когда-либо создавался на тот момент, так как он был в полной разработке в течение 1,5 лет). Мы используем один и тот же набор имен файлов в каждом представлении. Он очень последовательный и помогает нам быстро перейти к тому, что мы ищем:

  • events.js
  • helpers.js
  • templates.html
  • routes.js
  • styles.less
  • и т.п.

Выглядит так в проекте:

       Consolid── консолидацияЗапросы
       │ ├── events.js
       │ ├── helpers.js
       Rou ├── routers.js
       │ └── templates.html
       Customer── customerSpoof
       Rou └── routers.js
       ├── приборная панель
       │ ├── events.js
       │ ├── helpers.js
       On ├── onDestroyed.js
       On ├── onRendered.js
       Rou ├── routers.js
       │ └── templates.html
       Email── emailVerification
       │ ├── events.js
       │ ├── helpers.js
       Rou ├── routers.js
       │ └── templates.html
       Loading── загрузка
       │ ├── styles.css
       │ └── templates.html
       Mail── почтовый ящик
       Aut ├── autoform.js
       Consolid ├── консолидацияЗапросПодтверждение
       │ │ ├── events.js
       │ │ ├── helpers.js
       On │ ├── onCreated.js
       On │ ├── onRendered.js
       │ │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js

Связанные шаблоны просто хранятся вместе в одном файле. Содержание view/order/checkout/templates.htmlпоказанного здесь свернуто:

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

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

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

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

Мы используем подпапки, когда представления становятся сложными с большим количеством частей:

       Cart── корзина
       Add ├── addItem
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       On │ ├── onRendered.js
       │ │ ├── routers.js
       Styles │ ├── styles.less
       │ │ └── templates.html
       │ ├── оформить заказ
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       On │ ├── onRendered.js
       │ │ ├── routers.js
       │ │ └── templates.html
       View └── вид
       Aut ├── autoform.js
       Delete ├── deleteItem
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ └── templates.html
       │ ├── editItem
       │ │ ├── autoform.js
       │ │ ├── events.js
       │ │ ├── helpers.js
       │ │ └── templates.html
       │ ├── events.js
       │ ├── helpers.js
       On ├── onDestroyed.js
       On ├── onRendered.js
       Rou ├── routers.js
       Styles ├── styles.less
       │ └── templates.html

Мы также разрабатываем с помощью WebStorm, чрезвычайно мощного и гибкого редактора для разработки Meteor. Мы находим это чрезвычайно полезным при поиске и организации нашего кода и продуктивной работе. Веб-шторм вид

Рады поделиться деталями по запросу.

Макс Ходжес
источник
3
Пожалуйста, рассмотрите возможность добавления комментария, если считаете, что этот ответ можно улучшить.
Макс Ходжес
Отличный пост. Вопрос: После всего этого времени с метеором, вы все еще рекомендуете его для больших проектов, таких как электронная коммерция? Или подумайте об использовании фреймворка, который может дать вам больше «автономии», как LoopBack или даже Happi.
Liko
Мы любим Метеор и делаем все новое в нем. К сожалению, я недостаточно знаком с LoopBack или Happi, чтобы иметь мнение.
Макс Ходжес
1
LoopBacks фокусируется на сквозных интерфейсах API отдыха, что делает его похожим на традиционную среду веб-разработки (например, RoR). RoR правильно понял REST API, но мы чувствуем, что Meteor работает правильно в реальном времени.
Макс Ходжес
Спасибо за ответ. Вы тоже организовали серверную часть для функций?
Liko
5

Используйте железо-CLI леса CLI. Делает вещи очень легко.

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

после установки. использовать iron create my-appдля создания нового проекта. Это создаст следующую структуру для вас. Вы также можете использовать это в существующих проектах. использовать iron migrateв каталоге проекта.

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
источник
Хотя эта ссылка может ответить на вопрос, лучше включить сюда основные части ответа и предоставить ссылку для справки. Ответы, содержащие только ссылки, могут стать недействительными, если связанная страница изменится.
user2314737
@ user2314737 Крик, чтобы сказать, что ответчик действительно отредактировал свой пост. Теперь он включает в себя основные данные, необходимые для решения проблемы.
Кайл
4

Я следую стандартному формату Mattdeom, который уже включает в себя железный маршрутизатор и модель (Collection2). Увидеть ниже :

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
источник
3

Существует много разных подходов к структурированию вашего приложения. Например, если у вас есть маршрутизатор и разные шаблоны страниц, и внутри каждого шаблона страницы есть много частей страницы и т. Д., Я бы структурировал его в зависимости от семантики от более высокого> более низкого уровня.

Например:

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

Конечно, вы можете поместить свои шаблоны новостей в общую папку, так как вы можете использовать свой шаблон новостей на разных страницах.

Я думаю, что лучше всего вы структурируете свое приложение так, как вам удобно.

Я написал небольшое приложение здесь: http://gold.meteor.com И оно настолько маленькое, что я использую только один HTML-файл и только один файл template.js .. :)

Я надеюсь, что это немного помогает

Борис Котов
источник
Я не вижу смысла в именовании нескольких файлов с именем функции, например «статьи». Теперь, если вы хотите изменить имя функции на «сообщения», вы должны изменить имена файлов. Просто сгруппируйте их в одну папку под названием «статьи» и назовите их «events.js», views.html, styles, css и т. Д., См. Мой ответ для получения дополнительной информации.
Макс Ходжес
3

В Evented Mind появился новый класс под названием « Настройка метеорных проектов», который решает эту проблему, а также рассказывает о конфигурации проекта и настройке среды разработки.

Из видео « Структура приложения» в классе: «Метеор» не имеет четкого мнения о том, как следует структурировать ваше приложение, но вот некоторые правила:

1) Порядок загрузки - Метеор сначала идет в самое глубокое место в каталоге файлов и обрабатывает файлы в алфавитном порядке.

2) клиент и сервер - это специальные папки, которые Meteor распознает

Наша структура выглядит так:

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 расширяет RouteController, то, что поставляется с Iron Router.

emИнструмент упоминалось выше , также получает большое обновление прямо сейчас , и должно быть намного лучше и доступны по адресу: https://github.com/EventedMind/em

katogeaver
источник
какие виды внутри / сервер / виды /?
stefcud
я не вижу смысла в названии нескольких файлов с именем функции, например "todos". Теперь, если вы хотите изменить имя функции на «задачи», вам нужно изменить 5 имен файлов. Просто организуйте их в одну папку с именем "todos" и назовите их "events.js", views.html, styles, css и т. Д., Смотрите мой ответ для получения дополнительной информации.
Макс Ходжес
1

Я также ищу лучшие практики для улучшения и масштабирования моих приложений с помощью хорошо продуманной архитектуры. Все вышеперечисленные методы работают для приложений малого и среднего размера, но потерпят неудачу, когда вы работаете в большой команде. Есть несколько способов, которые я попробовал:

1) Я придерживался этой стратегии: https://github.com/aldeed/meteor-autoform для масштабирования и повторного использования шаблонов. У автора есть очень хорошая идея по проектированию компонентов и полей. В настоящее время я внедряю его, потому что сообщество разработало 36 пакетов, которые охватывают почти каждый случай, и я могу использовать TypeScript для обеспечения безопасности типов на этапе разработки.

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

Вот хороший пост в блоге о том, как это сделать: http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/, а также здесь: http: // meteorpedia .com / чтения / Blaze_Notes

2) Это выглядит так многообещающе, но в последнее время не обновлялось. Это пакет, написанный на кофейной надписи. Компоненты Blaze ( https://github.com/peerlibrary/meteor-blaze-components ) для Meteor представляют собой систему для простой разработки сложных элементов пользовательского интерфейса, которые необходимо повторно использовать в приложении Meteor. Вы можете использовать их в CoffeeScript, ванильном JavaScript и ES6. Лучше всего, компоненты ООП. Вот один из их примеров:

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) Мне нравятся типы и транспортер, которые говорят мне, где и когда что-то пойдет не так. Я использую TypeScript для работы с Meteor и нашел следующий репозиторий: https://github.com/dataflows/meteor-typescript-utils кажется, что создатель пытался реализовать подход 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>

К сожалению, этот проект не поддерживается или активно развивается.

4) и я думаю, что уже упоминалось, вы можете масштабировать с помощью пакетов. Это требует хорошего абстрактного мышления. Кажется, работает для телескопа: https://github.com/TelescopeJS/Telescope

5) расширение-метеор-шаблон - предоставляет различные способы копирования помощников шаблонов, обработчиков событий и перехватов между шаблонами, что позволяет повторно использовать код; недостатком является то, что все копирование должно осуществляться разработчиком, часто снова и снова, что становится проблематичным по мере роста кодовой базы; Более того, без четко определенного API-сообщества сообщество не может создавать и совместно использовать компоненты.

6) Компоненты потока - Компоненты потока ближе к React в дизайне API, в то время как компоненты Blaze хранят знакомые понятия, такие как контексты данных и помощники шаблонов; Компоненты Flow, с другой стороны, все еще используют обработчики событий на основе шаблонов, в то время как Компоненты Blaze делают их методами классов, чтобы их было проще расширять или переопределять с помощью наследования; в общем, компоненты Blaze более ориентированы на ООП; Компоненты потока еще не выпущены официально ( текстовые сообщения для № 5 и № 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )

К номерам 2 и 3 тоже нужно привыкнуть, но со временем вы получите скорость разработки. Номер четыре позволяет вам создавать и тестировать компоненты, чтобы сделать ваш код более стабильным. Номер три обладает преимуществом полной безопасности типов Typescript, что является огромным плюсом, когда вы разрабатываете в команде с плохой документацией. Однако в настоящее время я переношу номер два на TypeScript, потому что мне очень удобно с ним работать, и мне не нужно настраивать пакет компилятора, чтобы он работал с Meteor, когда я не использую Gulp.

Все еще трудно найти правильный способ работы с Метеором. Вы должны понять это сами, в противном случае вы получите хорошо организованную структуру папок, но у вас нет понятия, где все находится. Удачного кодирования.

MichelH
источник