Meteor что это за программа

Meteor Documentation

Это руководство по использованию Meteor,полносборной платформы JavaScript для разработки современных веб и мобильных приложений.

Что такое Метеор?

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

• Meteor позволяет разрабатывать на одном языке , JavaScript, во всех средах: сервере приложений, веб-браузере и мобильном устройстве.
• Meteor использует данные по сети , то есть сервер отправляет данные, а не HTML, а клиент их отображает.
• Meteor охватывает экосистему , тщательно и продуманно предлагая вам лучшие части чрезвычайно активного JavaScript-сообщества.
• Meteor обеспечивает полную реактивность стека , позволяя вашему пользовательскому интерфейсу легко отражать истинное состояние мира с минимальными усилиями при разработке.

Quick start

На OS X или Linux? Установите последний официальный релиз Meteor из вашего терминала:

Meteor js на русском. 1. Установка и учебник

curl https://install.meteor.com/ | sh

Установщик Windows поддерживает Windows 7,Windows 8.1,Windows Server.
2008,и Windows Server 2012.Установщик командной строки поддерживает Mac OS X
10.7 (Lion)и выше,и Linux на архитектурах x86 и x86_64.

После установки Meteor создайте проект:

meteor create myapp

Запустите его на месте:

cd myapp meteor npm install meteor # Сервер Meteor работает на: http: // localhost: 3000 /

Meteor поставляется с пакетом npm, так что вы можете набрать meteor npm , не беспокоясь об установке его самостоятельно. Если хотите, вы также можете использовать глобально установленный npm для управления своими пакетами.

Meteor resources

1. Место для начала работы с Meteor — официальное руководство .
2. Stack Overflow — лучшее место, чтобы задать (и ответить!) Технические вопросы. Не забудьте добавить к своему вопросу метку.
3. Посетите дискуссионные форумы Meteor, чтобы объявить о проектах, получить помощь, поговорить о сообществе или обсудить изменения в ядре.
4. Документация Meteor — лучшее место, где можно найти основную документацию по API платформы.
5. Atmosphere — это хранилище пакетов сообщества, разработанных специально для Meteor.
6. Awesome Meteor — это список пакетов и ресурсов, созданный сообществом .

Что такое «Метеоритный гид»?

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

МЕТЕОР ЭТО ВАШ ДЕНЕЖНЫЙ ПОТОК!

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

API платформы Meteor доступны на сайте документации , и вы можете просматривать пакеты сообщества в атмосфере .

Target audience

Руководство предназначено для разработчиков среднего уровня, которые имеют некоторое представление о JavaScript, платформе Meteor и веб-разработке в целом. Если вы только начинаете работать с Meteor, мы рекомендуем начать с официального руководства .

Example app

Многие статьи ссылаются на пример приложения Todos. Этот код активно развивается вместе с руководством. Вы можете увидеть последний исходный код приложения и проблемы с файлами или внести предложения с помощью запроса на вытягивание в его репозитории GitHub .

Guide development

Contributing

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

Цели проекта

Принятые решения и методы, изложенные в руководстве, обязательно должны быть субъективными . Некоторые передовые методы будут выделены, а другие действительные подходы проигнорированы. Мы стремимся достичь консенсуса сообщества в отношении основных решений, но всегда будут другие способы решения проблем при разработке вашего приложения. Мы считаем, что важно знать «стандартный» способ решения проблемы, прежде чем переходить к другим вариантам. Если альтернативный подход окажется лучше, он должен быть включен в будущую версию руководства.

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

Точно так же пробелы в платформе, отмеченные в руководстве, часто могут быть заполнены пакетами сообщества ; мы надеемся, что если вы увидите возможность улучшить рабочий процесс Meteor, написав пакет, вы воспользуетесь ею! Если вы не знаете, как лучше спроектировать или спроектировать пакет, обратитесь на форумы и начните обсуждение.

Источник: runebook.dev

О пользе и вреде FullStack-фреймворков на примере Meteor.js

Привет! Меня зовут Саша, и я backend-разработчик на Node.js в компании МойОфис.

В последнее время появляется довольно много Fullstack-фреймворков, они становятся популярны, их обсуждают.

Если посмотреть на результаты The State of JS 2021 в разделе «Библиотеки — Бэкенд-фреймворки», то минимум 5 из них (возможно, и больше) будут как раз FullStack. Отсортировав бэкенд-фреймворки по заинтересованности, в самом верху списка мы увидим снова именно FullStack. Это понятно — они востребованы и лежат в основе разных проектов.

Однако на мой взгляд, область их применимости несколько ограничена, и в этой статье я расскажу, почему.

Пара слов о том, как я дошел до жизни такой

К разработке на Node.js я пришел не сразу. В начале пути, около 8 лет назад, я писал на C++, Ruby, немного на Python и еще нескольких языках. Конечно же, был в моей жизни и frontend. В JavaScript я заметил интересную особенность, которую до этого видел только у Qt — можно не опрашивать что-либо в цикле и не ждать выполнения системного вызова, а подписаться на событие и, когда оно произойдет, выполнить некоторые действия.

Чуть позже я услышу термин «реактивное программирование» и, спустя еще некоторое время, свяжу это с миром JS — мне покажется, что за этим будущее. Потом я узнаю о Node.js, перестану плеваться от асинхронных операций (в этом изрядно помогут промисы и async/await). И вот я здесь.

История повторяется

Термин «FullStack-фреймворк» появился довольно давно. Как мне кажется, это прямое следствие идеи «один код для frontend и backend», которая очень часто звучала в первые годы популярности Node.js.

Одним из ранних «больших» FullStack-фреймворков был Meteor.js. Он появился в начале 2012 года и довольно быстро стал востребованным.

Ниже я выделю аргументы, которые приводились в его пользу, и несколько их обобщу. А потом покажу, почему эти «плюсы» не всегда оказываются полезными в реальных проектах, а иногда и мешают им.

Плюсы FullStack-фреймворков

Быстрое начало разработки

В FullStack-фреймворке уже приняты основные решения. Особенно решения, касающиеся взаимодействия frontend и backend (иначе, это уже не похоже на FullStack). Т.е. скорее всего команде не придется договариваться о том, что она понимает под Rest и какой формат сообщений, посылаемый через WebSockets, правильный.

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

Команда МГУ выиграла чемпионат мира по программированию АСМ ICPC

В случае Meteor он еще и выберет за вас БД (это будет mongo).

Быстрый ввод новичков в команду

Нового человека в команде, не знакомого с фреймворком, можно посадить на денек-другой смотреть YouTube и читать StackOverflow. Материалов много, они поданы и рассказаны интересно, технология популярна.

После пары (ну, может, тройки) дней человек уже будет знать основные принципы и сможет приступить к выполнению тасок из Jira.

На примере Meteor.js: легко найти видео «создай свой чат за 20 минут», «напиши блог за 30 минут» и тому подобное.

Локальный запуск проекта

Часто бывает, что разработчик хочет запустить проект локально и поотлаживать то, что он написал.

В «традиционном» подходе сначала запускается база данных, потом разворачивается backend с livereload, потом frontend (тоже с автоматическим обновлением). Наверняка не обходится без пары компонентов в докере.

Для FullStack, как правило, есть одна команда, которая запускает весь проект с автоматическим обновлением при изменениях. И это правда довольно удобно.

Решения FullStack-задач из коробки

Некоторые задачи требуют тесного взаимодействия frontend и backend. В качестве примера можно привести переводы (i18n) и различные способы авторизации (кто пытался реализовать поддержку OAuth самостоятельно, меня поймет).

Для FullStack-фреймворков найти готовое решение таких задач обычно довольно легко. В случае же «традиционного» подхода придется разбираться.

В Meteor это реализовано его собственной системой пакетов.

Киллер-фича

Это собирательное название для того, чем «продают» фреймворк.

• Remix говорит, что его код можно исполнять на нодах Cloudflare
• SvelteKit и многие другие говорят о легкости реализации SSR
• В Meteor стали использовать довольно остроумное решение для избежания CallbackHell (напоминаю, 2012 год).

Минусы FullStack-фреймворков

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

Быстрое начало разработки

Со временем появятся новые ответы на старые вопросы. Или вы наткнетесь на протекающую абстракцию какого-либо из ответов.

Хорошим примером, мне кажется, служит развитие возможностей языка. Однажды я поставил на новый компьютер свежую Node.js и решил собрать React приложение. У меня ничего не вышло — это было вскоре после появления 17 версии Node.js, и React просто не успел её поддержать. С большой долей вероятности у FullStack-фреймворка время поддержки новых версий будет больше.

Если же вы попадете на проект, где используется старый фреймворк, то он может блокировать обновление версий. С Meteor, например, не получится использовать Node.js выше 14 версии.

Быстрый ввод новичков в команду

Быстрая адаптация новых сотрудников оборачивается тем, что когда фреймворк теряет популярность, люди не хотят с ним разбираться. Технология, утратившая актуальность, кажется не слишком перспективной для развития карьеры, и тратить на неё свое время не хочется. А тем более копаться в большом количестве легаси на «пещерных» технологиях.

Локальный запуск проекта

Это случится постепенно.

Время сборки проекта будет расти. Время пересборки при обновлении одной строчки будет расти. Время установки зависимостей будет расти. Время CI будет расти. Чужие изменения будут ломать код, который, казалось бы, никак к ним не относится.

И вам захочется собирать всё раздельно. И это станет проблемой, так как код уже настолько переплелся, что найти, где заканчивается одно и начинается другое, будет почти невозможно.

Решения FullStack-задач из коробки

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

Киллер-фича

Любая киллер-фича — это решение какой-либо проблемы. И у любой проблемы есть более одного решения.

• В Node.js был выбран другой подход к решению CallbackHell, нежели тот, что предлагал Meteor. Теперь код на нем кажется странным.
• Я верю в то, что рано или поздно можно будет отказаться от SSR ради SEO оптимизаций и решить проблему скорости загрузки страницы за счет более быстрого интернета и использования ServiceWorker.
• Про распределение вычислительных ресурсов географически за небольшие деньги и у меня пока нет идей, но это не значит, что они не появятся потом.

Подводя итог

Имеет ли смысл использовать FullStack-фреймворки? Безусловно, да. Быстрая разработка и заинтересованные специалисты — это просто подарок для любого проекта.

Можно ли как-то спасти себя от минусов FullStack-фреймворков? Конечно. На том этапе, когда проект перестанет быть MVP, и вы займетесь разбором техдолга, постарайтесь уделить больше внимания разделению проекта на независимые составляющие, выделите интерфейсы и проведите архитектурные границы. Разберитесь с «магией», которую делают сторонние компоненты — скорее всего, для вашего случая её можно реализовать более эффективно.

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

Источник: tproger.ru

О Meteor подробно: почему это будущее веб-разработки

2014-10-31 в 12:33, admin , рубрики: future of development, javascript, Meteor, Meteor.JS, node.js

Что такое Meteor?

Это не очередной javascript фреймворк. Ставить его в один ряд с derby, sails, angular или backbone некорректно. Meteor — это платформа для создания модульных высокоинтерактивных клиент-серверных приложений. Пусть это звучит слегка напыщенно и напоминает маркетинговый булщит слоган, но зато по сути очень точно отражает миссию и текущее состояние Meteor. Буквально несколько дней назад Meteor API выпустил первую стабильную версию (1.0).

Официальную информацию можете почитать на портале www.meteor.com, а я же хочу рассказать об особо горячо любимых мной фичах.

1. Пишем логику на одном языке — результат работает на всех платформах: сервер, браузер, cordova (Android, IOS). Естественно, без особенностей не обходится, но это — мелочи жизни. Apple и Google видят в cordov’е большой потенциал и занимаются развитием поддержки этой технологии: Apple allows hot code push in mobile apps; Новый Chromium WebView теперь обновляется через Google Play и поддерживает Web Components.
2. В руководстве проекта — умные и опытные разработчики, которые понимают ценность сообщества, работа с которым построена на твёрдую пятёрку. Ежемесячные devshop-события в штаб-квартире в SF, поддержка через stackoverflow, отличное и всегда актуальное описание API. Отдельно хочу отметить грандиозное событие — Worldwide Meteor Day, посвящённое выходу первой версии. В России, кстати, событие проводится в 2 городах: в Москве и Курске.
3. Удобное асинхронное серверное программирование благодаря встроенному Fibers. В 99% случаев при работе с Meteor вы пишете обычный синхронный код, и он работает асинхронно! Странно? Ничего странного: каждый вызов серверного метода работает в своём Fiber’e и не влияет на работу остальных вызовов. Это нереально упрощает структуру кода: любые обращения к БД и другим внешним ресурсам пишутся в синхронном стиле. Недавно смотрел на кусочек кода хорошо написанного обычного асинхронного node.js-приложения, — и у меня на глаза навернулись слёзы. Если кто-то ещё не знаком с Fibers, — настоятельнейшим образом рекомендую!
4. Отлично спроектированная абстракция для работы с данными через коллекции. Коллекции представляют одинаковый интерфейс на сервере и на клиенте, что позволяет реализовывать логику в одном стиле и даже расшаривать код между сервером и клиентом.
5. Не менее крутая абстракция для вызова серверных методов, выглядящая как вызов асинхронной функции с callback’ом. Забудьте про серверные пути, xhr и сложную структуру кода! В Meteor всё делается очень просто.
6. Удобный деплой приложений. Особенно если вы только начинаете свой проект: одной командой из консоли ваш проект публикуется на домене .meteor.com; после деплоя можете перенастроить на ваш_домен.com. Если проект вырос и его требуется перенести на профессиональный хостинг , то, опять же, одной командой проект собирается в node.js-приложение с единственной зависимостью — npm.
7. Все рутинные оптимизации (минификация кода, сборка в один файл) и перекомпиляции (less -> css, coffeescript -> js и проч.) производятся автоматически и практически без настройки (прощай новорождённый gulp и уродливый grunt). Для некоторых операций требуется установить пакет (package), что тоже достигается однократным вводом консольной команды.
8. Протокол DDP, призванный заменить REST API. Это очень простой но мощный протокол, основанный на EJSON (расширенный JSON). DDP поддерживает RPC и двустороннюю передачу данных (туда и оттуда), работает поверх WebSockets и SockJS. А ещё его легко читать, что может потребоваться в случае особо глубоких дебагов. Кстати, если нужен REST API, то никто не запрещает его использовать. Даже напротив, есть подходы на любой вкус. Просто уже не захочется шагать назад.
9. Best practices enforcement. Html, css, less и coffeescript должны быть валидными (иначе проект не скомпилируется), чёткое разделение между шаблонами (spacebars — наследник handlebars), css и js. Чёткое разделение между только серверным, только клиентским и расшаренным кодом. Система пакетов с явными зависимостями (Meteor, npm, cordova), явным экспортом API и полной изоляцией пакетов — мечта для node.js программистов!

И ещё много плюшек, реализованных без странных дизайнерских решений. В итоге получаем инструмент, который позволит решать задачи не отвлекаясь на рутину. Если вы сейчас выбираете node.js фреймворк для вашего будущего проекта, без колебаний останавливайтесь на Meteor — ваши мучения прекратятся, а волосы станут мягкими и шелковистыми.

Литература

• Всегда актуальная литература по Meteor (постоянно обновляется и пополняется): https://www.discovermeteor.com/
• Официальные документы: https://docs.meteor.com/#/full/
• Официальный туториал: https://www.meteor.com/install
• Google-группы: https://groups.google.com/forum/#!forum/meteor-core, https://groups.google.com/forum/#!forum/meteor-talk
• Блог Meteorhacks: https://meteorhacks.com/
• Хардкор-блог Eventedmind: https://www.eventedmind.com/
• Пара моих постов о Meteor: http://www.solidmeteor.com/
• Более полный список ресурсов для изучения: https://hackpad.com/Top-Resources-for-learning-MeteorJS-Nrpnr6CHiGs
• Совсем полный список (полнее просто некуда): https://github.com/ericdouglas/Meteor-Learning

Источник: www.pvsm.ru

Русские Блоги

Платформа для разработки полного стека — введение в Meteor.

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

Один,Платформа для разработки полного стека — больше, чем просто интерфейс

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

Как видно из рисунка, Meteor использует браузер как базовую операционную среду во внешнем интерфейсе, NodeJS как базовую операционную среду в серверной части и MongoDB в качестве системы сохранения данных.

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

Два, впервые встретил Метеор

По своему составу платформу разработки Meteor можно рассматривать как состоящую из двух частей:

Библиотека Meteor существует в виде пакета функций, инкапсулирующего основные функции, такие как связь в реальном времени и реактивное программирование. Когда приложение Meteor запускается, Meteor автоматически загружает эти библиотеки, обеспечивая базовую среду для приложения.

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

Теперь давайте воспользуемся инструментом командной строки Meteor, чтобы создать и запустить первое приложение Meteor.

1. Создайте приложение-метеор, создайте [проект]

Введите тест создания метеора в терминале и нажмите Enter:

~$ meteor create test

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

~$ cd test ~/test$ ls -al

Вы можете видеть, что Meteor создал 3 файла и 1 каталог.

• файл таблицы стилей test.css-front-end
• test.html-HTML файл для интерфейса пользователя
• test.js-файл JavaScript, общий для внешнего / внутреннего интерфейса.

Полный стек, верно? O (∩_∩) O ~

.meteor — это специальный подкаталог, необходимый для приложений Meteor и обслуживаемый платформой Meteor. Не будем двигаться
Сначала пропустите конкретное содержимое трех файлов, давайте запустим его и посмотрим.

2. Запускаем приложение-метеор, запускаем

Выполните команду meteor, чтобы запустить приложение, и введите в терминале метеор. Это эквивалентно запуску метеора:

~/test$ meteor

Когда вы увидите в терминале следующее сообщение:

. App running at: http://localhost:3000/

Поздравляю! Наше первое приложение Meteor запущено и работает!

3. Остановите работу приложения — Ctrl + C

Щелкните область терминала левой кнопкой мыши, чтобы убедиться, что он находится в фокусе ввода с клавиатуры (вы должны увидеть мигающий курсор), а затем одновременно нажмите клавиши Ctrl и C, чтобы остановить приложение:

^C ~/test$

4. Сброс данных приложения — сброс метеора

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

~/test$ meteor rest

Команда сброса метеора не влияет на файлы исходного кода.

Три, шаблон file-test.html

Откройте test.html, вы можете почувствовать небольшой дискомфорт:

Это не стандартный HTML-файл: там нет тега верхнего уровня html, странного символа hello>> . Однако такой файл в Metoer является легальным файлом — файлом шаблона.

1. Шаблон верхнего уровня label-head / body / template

Meteor оговаривает, что в файле шаблона могут отображаться только три тега верхнего уровня: head, body и template. Другими словами, файл шаблона может содержать только фрагменты HTML с этими тремя типами тегов в качестве тегов верхнего уровня.

Это связано с тем, что у Meteor есть процесс упаковки / бандлирования перед запуском приложения. В это время Meteor извлечет фрагменты головы, тела и шаблона во все файлы шаблонов (в приложении может быть несколько файлов шаблонов), объединит и скомпилирует их отдельно. Затем представили пользователю:

На приведенном выше рисунке фрагменты заголовка в a.html и b.html объединены в качестве окончательного содержимого заголовка, а фрагменты тела в b.html и c.html объединены в качестве окончательного содержимого тела. Что касается шаблона в c.html Content, он, наконец, заменил hello>> в b.html.

2. Язык шаблонов — пробелы.

Язык шаблонов Meteor — это проприетарный язык пробелов, который основан на популярных ручках и реализует шаблоны путем встраивания тегов шаблонов (ограниченных двумя парами скобок) во фрагменты HTML. Следовательно, шаблон Meteor на самом деле представляет собой смесь тегов HTML и тегов шаблона.

Тег шаблона hello>> используется для вызова подшаблона. Meteor будет использовать содержимое подшаблона hello, чтобы заменить его на место в документе HTML, который, наконец, представляется пользователю.

Специальный тег шаблона используется для определения подшаблона.

Тег шаблона > выполняет работу по интерполяции, и измеритель будет использовать значение, соответствующее счетчику идентификатора, чтобы заменить его на место в документе HTML, который, наконец, представляется пользователю.

В-четвертых, стиль file-test.css

Подобно файлам шаблонов, Meteor объединяет все файлы стилей в один большой файл стилей во время процесса упаковки, а затем ссылается на этот файл стилей в HTML-документе, представленном пользователю:

На приведенном выше рисунке содержимое a.css и b.css будет объединено в один файл, и на этот файл будет ссылаться с помощью тега ссылки в документе HTML, который, наконец, будет представлен пользователю.

Пятый, код file-test.js

test.js — самый интересный файл, и Meteor будет запускать этот файл как на клиентской, так и на внутренней стороне. Это можно понять так:

• Front-end-Meteor будет использовать тег script для ссылки на test.js в HTML-документе, который, наконец, будет представлен пользователю.
• Backend-Meteor будет читать и запускать test.js через NodeJS

Нет сомнений в том, что без какой-либо обработки никто не может гарантировать, что часть кода JS может работать в среде внешнего браузера или в серверной части NodeJS. В test.js нам нужно определить текущую конкретную операционную среду, чтобы выполнить соответствующий код.

1. Определите среду выполнения кода — Meteor.isClient / Meteor.isServer

Пусть один и тот же файл js запускается во внешнем или внутреннем интерфейсе (например, NodeJS). Уже существует много приложений. Вам нужно только оценить переменные, которые существуют в определенной среде (например, NodeJS имеет глобальные , И в браузере есть окошко). Meteor предоставляет более четкий набор API для достижения этого суждения:

• Meteor.isClient — если true, это означает, что текущая рабочая среда является интерфейсом
• Meteor.isServer: если true, это означает, что текущая рабочая среда является серверной.

Как видите, это тоже делается в test.js:

//test.js if(Meteor.isClient) < // Блок кода выполняется только во внешнем интерфейсе >if(Meteor.isServer) < // Блок кода выполняется только на бэкэнде >

2. Код выполняется как на передней, так и на задней стороне.

Очевидно, что в test.js код, который не оценивает среду выполнения, будет работать как на переднем, так и на заднем концах одновременно. Такие как:

//test.js console.log(«Hello,Meteor!»); if(Meteor.isClient) if(Meteor.isServer)

После запуска приложения вы увидите Hello, Meteor! В терминале в фоновом режиме и такой же вывод в консоли отладки на переднем плане.

Шесть, объект экземпляра интерфейсного кода-шаблона

Напомним, что в файле шаблона test.html мы определили шаблон:

Click Me

You’ve pressed the button > times.

Когда Meteor запускает это приложение, он автоматически создает соответствующий объект экземпляра шаблона: Template.hello. Привязка данных и привязка событий шаблона, которые обычно необходимо реализовать с помощью JavaScript, реализуются через этот объект:

В шаблоне приветствия значение идентификатора couter в теге шаблона > будет определяться возвращаемым значением функции счетчика соответствующего объекта экземпляра шаблона. Эта функция называется вспомогательной функцией шаблона, и используется метод helpers () экземпляра шаблона. Объявите вспомогательную функцию, соответствующую идентификатору в теге шаблона.

С помощью метода событий объекта экземпляра шаблона функция обработки прослушивателя событий щелчка подключается к элементу кнопки в шаблоне.

Семь, интерфейсный анализ идентификатора тега шаблона кода / помощник

Используйте метод Template.hello.helpers (helpers), чтобы объявить функцию синтаксического анализа идентификатора тега шаблона в шаблоне приветствия. Помощники параметров — это объект JS. Атрибут представляет идентификатор, используемый в теге шаблона. Значение обычно представляет собой функцию, называемую помощником, что примерно означает помощь Meteor в синтаксическом анализе значения идентификатора в шаблоне.

Например, в test.js мы объявляем соответствующую вспомогательную функцию для выражения счетчика, которое появляется в теге шаблона > в шаблоне hello:

//test.js Template.hello.helpers( < ‘counter’:function()< return Session.get(‘counter’); >>);

Каждый раз, когда Meteor нужно вычислить тег шаблона >, он будет вызывать вспомогательную функцию, соответствующую его идентификатору счетчика, для выполнения вычисления: он просто возвращает текущее значение счетчика переменной сеанса.

1. Задайте параметры для вспомогательной функции.

Вспомогательная функция может принимать параметры, такие как идентификатор displayName в шаблоне test:

Hello,>!

Объявите следующую вспомогательную функцию:

Template.test.helpers( < ‘displayName’ : function(name,title)< return title + ‘ ‘ + name; >>);

После рендеринга Meteor получит следующие HTML-результаты:

Hello,Mr. Jason!

2. Используйте постоянный помощник

Конечно, помощник также можно определить как константу:

Template.test.helpers(< displayName : «Mr. WHOAMI» >)

В настоящее время тег шаблона > всегда будет иметь фиксированное значение.

Источник: russianblogs.com