Во всех примерах (таблица лидеров, wordplay и т.д.) у них есть один шаблонный файл HTML. Есть ли большой проект Meteor с открытым исходным кодом со многими различными файлами шаблонов HTML, которые мы можем использовать в качестве примера лучшей практики? Кажется нецелесообразным размещать все, что требуется большому приложению, в одном файле шаблона.
Каковы наилучшие методы структурирования большого приложения Meteor со многими файлами шаблонов HTML?
Ответ 1
Убей все вместе! Из документов:
> 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 a really
> convenient way to ship HTML templates to the client. See the templates
> section for more.
Ответ 2
Как и в неофициальном meteor faq, я думаю, что это в значительной степени объясняет, как структурировать большое приложение:
Где мне поместить мои файлы?
Примеры приложений в метеоре очень просты и не дают большого понимания. Вот мой взгляд на лучший способ сделать это: (любые предложения и улучшения очень приветствуются!)
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 Meteor
Ответ 3
Я согласен с yagooar, но вместо:
client/application.js
Использование:
client/main.js
main. * файлы загружаются последними. Это поможет убедиться, что у вас нет проблем с загрузкой. Подробнее см. Документацию Meteor, http://docs.meteor.com/#structuringyourapp.
Ответ 4
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
Я надеюсь, что некоторые более конкретные структуры передовой практики и соглашения об именах появятся, хотя.
Ответ 5
Для всех, кто работает в этой теме:
Инструмент командной строки 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
Ответ 6
Я думаю, что файловая структура из Discover Meteor Book действительно хороша и прочная.
/app:
/client
main.html
main.js
/server
/public
/lib
/collections
- Код в каталоге /server работает только на сервере.
- Код в каталоге /client работает только на клиенте.
- Все остальное работает как на клиенте, так и на сервере.
- Файлы в /lib загружаются прежде всего.
- Любой основной. * файл загружается после всего остального.
- Ваши статические активы (шрифты, изображения и т.д.) входят в каталог /public.
Ответ 7
Создание пакетов
Конечно, не все подходит для этого подхода, но в больших приложениях у вас будет много функций, которые можно изолировать. Все, что отделимо и многократно используется в пакетах, остальное относится к обычной структуре каталогов, как упоминалось в других ответах. Даже если вы не делаете пакеты, чтобы избежать накладных расходов, структурирование кода модульным способом - это хорошая идея (см. эти предложения)
Meteor позволяет мелкомасштабный контроль над тем, как вы загружаете свои файлы (порядок загрузки, где: клиент/сервер/оба) и то, что экспортирует пакет.
Мне особенно удобно найти простой способ поделиться логикой между связанными файлами. Скажем, например, вы хотите сделать некоторые функции использования и использовать их в разных файлах. Вы просто делаете его "глобальным" (без var), а Meteor будет обертывать его в пространстве имен пакета, поэтому он не будет загрязнять глобальное пространство имен
Здесь официальный документ
Ответ 8
Через некоторое время из кодирования метеоритов я рад, что у меня есть свободное время, чтобы посвятить себя созданию довольно сложной онлайн-игры. Структура приложения была одной из моих первых проблем, и похоже, что несколько очень хороших программистов отстаивали только пакетный метод структурирования приложения, что позволяет вам свободно сочетать функционально разные пакеты. Есть другие преимущества подхода, и 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
Ответ 9
У нас есть большой проект (возможно, один из крупнейших проектов Метеор, который был построен на сегодняшний день, так как он был полностью занят в течение 1,5 лет). Мы используем один и тот же набор имен файлов в каждом представлении. Он очень последователен и помогает нам быстро ориентироваться именно на то, что мы ищем:
- events.js
- helpers.js
- templates.html
- routes.js
- styles.less
- и др.
Похоже, что в проекте:
├── 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. Мы находим это очень полезным при поиске и организации нашего кода и работе продуктивно.
С удовольствием сообщаем подробности по запросу.
Ответ 10
Я следую формату шаблона 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
Ответ 11
Используйте 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
Ответ 12
Существует множество различных подходов к структурированию вашего приложения. Например, если у вас есть маршрутизатор и разные шаблоны страниц, а внутренний шаблон каждой страницы имеет много частей страницы и т.д., Я бы структурировал его в зависимости от семантики от более высокого > нижнего уровня.
Пример:
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..:)
Я надеюсь, что это поможет немного
Ответ 13
В новом классе Evented Mind называется Настройка проектов Meteor, который обращается к этому, но также говорит о конфигурации проекта и настройке среды разработки.
Из Application Structure видео в классе: у Meteor нет очень сильного мнения о том, как ваше приложение должно быть структурировано, но здесь некоторые правила:
1) Порядок загрузки - Meteor отправляется в самое глубокое место в каталоге файлов и обрабатывает файлы в алфавитном порядке
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
Ответ 14
Я также ищу лучшие практики для улучшения и масштабирования приложений через хорошо продуманную архитектуру. Все вышеупомянутые практики работают для приложений малого и среднего размера, но не работают, когда вы работаете в более крупной команде. Есть несколько способов, которые я пробовал:
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/read/Blaze_Notes
2) Этот выглядит так многообещающе, но не обновлялся в последнее время. Это пакет, написанный на кофе script. Компоненты Blaze (https://github.com/peerlibrary/meteor-blaze-components) для Meteor - это система для легкого развития сложных элементов пользовательского интерфейса, которые необходимо повторно использовать вокруг вашего приложения Meteor. Вы можете использовать их в CoffeeScript, ванильном JavaScript и ES6. Лучше всего, компоненты OOP. Вот один из их примеров:
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) meteor-template-extension - предоставляет различные способы копирования помощников шаблонов, обработчиков событий и перехватов между шаблонами, позволяющих повторно использовать код; Недостатком является то, что все копирование необходимо заботиться разработчиком, часто снова и снова, что становится проблематичным по мере роста кодовой базы; кроме того, без четко определенного сообщества API не могут создавать и обмениваться компонентами
6) Компоненты потока - Компоненты потока ближе к React в дизайне API, а Компоненты Blaze поддерживают знакомые понятия, такие как контексты данных и помощники шаблонов; Компоненты потока, с другой стороны, по-прежнему используют обработчики событий на основе шаблонов, в то время как компоненты Blaze составляют их методы класса, поэтому проще расширить или переопределить их через наследование; в целом компоненты Blaze, похоже, больше ориентированы на ООП; Компоненты потока еще не официально выпущены (текстовые кредиты для # 5 и # 6 https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support)
Число 2 и 3 тоже нуждается в некотором использовании, но со временем вы получите скорость разработки. Номер четыре позволяет создавать и тестировать компоненты, чтобы сделать ваш код более стабильным. Номер три имеет преимущество полной безопасности Typescript, что является огромным плюсом, когда вы разрабатываете команду с плохой документацией. Однако в настоящее время я переношу номер два на TypeScript, потому что мне очень удобно работать с ним, и мне не нужно поддразнивать пакет компилятора, чтобы он работал с Meteor, когда я не использую Gulp.
До сих пор трудно найти правильный способ работы с Meteor. Вам нужно разобраться в этом сами, иначе вы получите красивую структуру папок, но вы не знаете, где все. Счастливое кодирование.