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

165

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

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

Ваш Ответ

14   ответов
1

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

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

<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/read/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) Метеор-шаблон-расширение & # X2013; предоставляет различные способы копирования помощников шаблонов, обработчиков событий и перехватов между шаблонами, что позволяет повторно использовать код; недостатком является то, что все копирование должно осуществляться разработчиком, часто снова и снова, что становится проблематичным по мере роста кодовой базы; Более того, без четко определенного API-сообщества сообщество не может создавать и совместно использовать компоненты.

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

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

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

15

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

5

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

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

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

Вот пример одной из возможных структур: в одном из моих приложений, на дискуссионном форуме, я организую по модулю или по «типу страницы». (home, forum, topic, comment), помещая файлы .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

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

1.3 зарезервировано в пользу импортаguide.meteor.com/structure.html#example-app-structure
связанные вещи должны быть в непосредственной близости друг от друга. Мой ответ как твой, но задом наперед.
я не вижу смысла в именовании нескольких файлов с именем функции, например "topic". Теперь, если вы хотите изменить имя функции на & quot; категорию & quot; Вы должны изменить несколько имен файлов. Просто организуйте их в одну папку под названием «тема» и назовите их обобщенно: events.js, views.html, styles, css, rout.js и т. д., см. мой ответ для получения дополнительной информации.
Это мой любимый ответ. Одна из моих любимых особенностей Meteor - это то, что вы можете структурировать свои файлы так, как вам удобно.
Мне нравится этот ответ. Я делал это первым способом.
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

я не вижу смысла в именовании нескольких файлов с именем функции, например "todos". Теперь, если вы хотите изменить имя функции на «Задачи» Вы должны изменить 5 имен файлов. Просто организуйте их в одну папку с именем & quot; todos & quot; и назовите их «events.js», views.html, styles, css и т. д., см. мой ответ для получения дополнительной информации.
какие виды внутри / server / views /?
273

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

Where should I put my files?

The example apps in meteor are very simple, and don’t provide much insight. Here’s my current thinking on the best way to do it: (any suggestions/improvements are very welcome!)

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)

For larger applications, discrete functionality can be broken up into sub-directories which are themselves organized using the same pattern. The idea here is that eventually module of functionality could be factored out into a separate smart package, and ideally, shared around.

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

Что касается метеора 1.3, я бы сказал, что он устарел из-за импорта модуля ES6. Смотрите метеорологическую статью о структуре приложения:guide.meteor.com/structure.html
кто-нибудь знает, где поставитьmobile-config.js?
Начиная с версии 0.6.0, вам гораздо лучше избегать этого беспорядка и полностью запускать свое приложение из интеллектуальных пакетов. Я немного подробнее расскажу об этом сообщении в блоге:matb33.me/2013/09/05/meteor-project-structure.html
Спасибо за ответ и ссылку на неофициальный раздел часто задаваемых вопросов (я новичок в мире метеоров), что они имеют в виду под "общим кодом от кого-то еще"? ?Спасибо!
ИМХО это лучше принятого ответа. Я попробую это сейчас.
4

который уже включает в себя железный маршрутизатор & amp; Модель (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 al,l views(*)
        common/         # General purpose html templates
model/                  # Model files, for each Meteor.Collection(*)
private/                # Private files
public/                 # Public files
routes/                 # All routes(*)
server/                 # Server folder
    fixtures/           # Meteor.Collection fixtures defined
    lib/                # Server side library folder
    publications/       # Collection publications(*)
    startup/            # On server startup
meteor-boilerplate      # Command line tool
3

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

Например:

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 и т. д., см. мой ответ для получения дополнительной информации.
6

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

events.js helpers.js templates.html routes.js styles.less etc.

Похоже на это в проекте:

       ├── consolidationRequests
       │   ├── events.js
       │   ├── helpers.js
       │   ├── routers.js
       │   └── templates.html
       ├── customerSpoof
       │   └── routers.js
       ├── dashboard
       │   ├── events.js
       │   ├── helpers.js
       │   ├── onDestroyed.js
       │   ├── onRendered.js
       │   ├── routers.js
       │   └── templates.html
       ├── emailVerification
       │   ├── events.js
       │   ├── helpers.js
       │   ├── routers.js
       │   └── templates.html
       ├── loading
       │   ├── styles.css
       │   └── templates.html
       ├── mailbox
       │   ├── autoform.js
       │   ├── consolidationRequestConfirmation
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onCreated.js
       │   │   ├── onRendered.js
       │   │   └── templates.html
       │   ├── events.js
       │   ├── helpers.js

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

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

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

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

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

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

       ├── cart
       │   ├── addItem
       │   │   ├── autoform.js
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onRendered.js
       │   │   ├── routers.js
       │   │   ├── styles.less
       │   │   └── templates.html
       │   ├── checkout
       │   │   ├── autoform.js
       │   │   ├── events.js
       │   │   ├── helpers.js
       │   │   ├── onRendered.js
       │   │   ├── routers.js
       │   │   └── templates.html
       │   └── view
       │       ├── autoform.js
       │       ├── deleteItem
       │       │   ├── events.js
       │       │   ├── helpers.js
       │       │   └── templates.html
       │       ├── editItem
       │       │   ├── autoform.js
       │       │   ├── events.js
       │       │   ├── helpers.js
       │       │   └── templates.html
       │       ├── events.js
       │       ├── helpers.js
       │       ├── onDestroyed.js
       │       ├── onRendered.js
       │       ├── routers.js
       │       ├── styles.less
       │       └── templates.html

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

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

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

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

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

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

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

14

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

Увидеть:https://github.com/EventedMind/em

И здесь:https://stackoverflow.com/questions/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

Примечание: это было заменено на iron-cli (тот же автор). Увидеть:github.com/iron-meteor/iron-cli
Да, 'em' был переименован в Iron-Cli, тот же инструмент.
36

client/application.js

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

client/main.js

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

11

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

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
Code in the /server directory only runs on the server. Code in the /client directory only runs on the client. Everything else runs on both the client and server. Files in /lib are loaded before anything else. Any main.* file is loaded after everything else. Your static assets (fonts, images, etc.) go in the /public directory.

Похожие вопросы