04-collections.md.erb

---
title: Коллекции
slug: collections
date: 0004/01/01
number: 4
contents: Узнаете больше о ключевой технологии Meteor - коллекциях.|Поймете, как работает синхронизация данных в Meteor.|Подключите данные из коллекций к шаблонам.|Превратите простой прототип в полностью функциональное real-time приложение!
paragraphs: 72
---

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

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

Коллекция в Meteor - это особая структура данных, ответственная за хранение ваших данных в серверной БД Mongo, а после обеспечивает синхронизацию данных между браузерами подключенных пользователей в реальном времени.

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

Коллекции являются главным элементом любого приложения, и чтобы гарантировать их инициализацию в первую очередь мы положим их в директорию `lib`. Создайте поддиректорию ‘collections/‘ в `lib`, и внутри создайте файл ‘posts.js` со следующим содержанием:

~~~js
Posts = new Mongo.Collection('posts');
~~~
<%= caption "lib/collections/posts.js" %>

<%= commit "4-1", "Added a posts collection" %>

<% note do %>

### Var или не Var?

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

<% end %>

### Хранение данных

У веб-приложений есть три основных способов хранения данных, каждый из которых выполняет свою роль:

- **Память браузера:** типы данных такие, как JavaScript переменные хранятся в памяти браузера и означает, что они не *постоянны*: они локальны к текущей вкладке браузера, и исчезнут как только вы закроете ее.
- **Браузерное хранилище:** браузеры также могут хранить данные на более долгий срок используя cookies или [Локальное хранилище](http://diveintohtml5.info/storage.html). Несмотря на то что эти данные сохранятся от сессии к сессии, они *локальны* к текущему пользователю (но доступны всем вкладкам) и их не так легко совместно использовать с другими пользователями.
- **Серверная база данных**: старая добрая база данных - это лучшее место для хранения постоянных данных и возможностью подключения больше чем одного пользователя (MongoDB является БД по умолчанию для Meteor-приложений).

Meteor использует все перечисленные методы и иногда синхронизирует данные между ними (как мы увидим далее). Но база данных остается "каноническим" источником данных, в котором хранится главная копия ваших данных.

### Клиент и сервер

Код вне директорий `/server` и `/client` будет исполняться как на сервере, так и на клиенте, так что наша коллекция `Posts` будет доступна в *обоих* средах, хотя поведение коллекции на сервере и на клиенте во многом отличается.

На сервере, коллекции ответственны за коммуникации с MongoDB, чтение и запись любых изменений. В этом смысле можно сравнить коллекции с обычной библиотекой для работы с БД. 

Тогда как коллекция на клиенте - это копия *части* коллекции из базы данных. Коллекции на клиенте постоянно и (чаще всего) незаметно синхронизируются с коллекцией из MongoDB в реальном времени.

<% note do %>

### Консоль vs Консоль vs Консоль

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

#### Терминал

<%= screenshot "terminal", "The Terminal" %>

- Доступен в вашей оперативной системе.
- Данные, выведенные с помощью `console.log()` на **сервере**, отобразятся именно там.
- Prompt: `$`.
- Также многие называют его Shell или Bash.

#### Браузерная консоль

<%= screenshot "browser-console", "The Browser Console" %>

- Открывается в браузере и исполняет JavaScript.
- Данные, выведенные с помощью `console.log()` на **клиенте**, отобразятся именно там.
- Prompt: `❯`.
- Также называется: JavaScript консоль, DevTools консоль.

#### Mongo Shell

<%= screenshot "mongo-shell", "The Mongo Shell" %>

- Открывается в терминале командами `meteor mongo`.
- Позволяет напрямую проводить операции с базой данных.
- Prompt: `>`.
- Также ее называют консоль Mongo.

Заметьте, что вам не нужно вводить символ prompt (`$`, `❯`, или `>`) как часть команды. Как вы можете заметить, каждая строка, не начинающаяся с prompt - это вывод предыдущей команды.

<% end %>

### Коллекции на сервере

На сервере коллекции работают в качестве API для нашей базы MongoDB. Это позволяет нам на сервере выполнять команды вроде `Posts.insert()` или `Posts.update()`, которые вносят изменения в коллекцию `posts` в MongoDB.

Чтобы взглянуть непосредственно на нашу базу данных, откройте новую вкладку терминала (в то время как сам процесс `meteor` исполняется в первой вкладке), перейдите в директорию нашего приложения. Затем введите команду `meteor mongo` для запуска Mongo Shell, в которой мы сможем выполнять стандартные команды MongoDB (как обычно, выйти из консоли Mongo можно набрав `ctrl+c`). Для примера, давайте добавим новый пост:

~~~bash
meteor mongo

> db.posts.insert({title: "A new post"});

> db.posts.find();
{ "_id": ObjectId(".."), "title" : "A new post"};
~~~
<%= caption "The Mongo Shell" %>

<% note do %>

### Mongo на Meteor.com

Если вы опубликовали ваше приложение на *.meteor.com, вы также можете получить доступ к серверной базе данных командой `meteor mongo myApp`.

И также можно вывести логи набрав `meteor logs myApp`.

<% end %>

Синтаксис Mongo многим знаком, так как он использует JavaScript. Мы не будем дальше работать с нашей БД с помощью консоли Mongo, но иногда уместно туда зайти, чтобы проверить, в каком состоянии сейчас MongoDB.

### Коллекции на клиенте

Гораздо интереснее обстоят дела с коллекциями на клиенте. Когда вы пишете `Posts = new Mongo.Collection('posts');` на клиенте, вы создаете *локальную браузерную кэш-копию* настоящей коллекции Mongo. Говоря, что коллекция на клиенте - это «кэш», мы подразумеваем то, что она содержит копию *части* данных БД и позволяет получать к ним доступ очень *быстро*.

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

Также коллекции на клиенте хранятся *в памяти браузера*, а это значит, что мы можем получить к ним доступ практически мгновенно. Больше никаких медленных запросов на сервер, чтобы достать данные из БД, так как вызывая, скажем, метод `Posts.find()` на клиенте, мы работаем уже с предварительно загруженными данными.

<% note do %>

### Представляем MiniMongo

Версия Mongo на клиенте в Meteor называется MiniMongo. Пока технология еще не доведена до совершенства, и есть некоторые функции MongoDB, которые не будут работать в MiniMongo. Несмотря на это, все функции, которые мы затрагиваем в этой книге, работают как непосредственно в MongoDB, так и в MiniMongo.

<% end %>

### Коммуникации клиент-сервер

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

Вместо того чтобы объяснять все в деталях, давайте просто посмотрим, что произойдет.

Начнем с того, что откроем два окна браузера, и в каждом из них откроем JavaScript консоль. Далее, запускаем Mongo shell в терминале. 

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

~~~bash
> db.posts.find();
{title: "A new post", _id: ObjectId("..")};
~~~
<%= caption "The Mongo Shell" %>

~~~js
❯ Posts.findOne();
{title: "A new post", _id: LocalCollection._ObjectID};
~~~
<%= caption "First browser console" %>

Теперь, в одном из окон браузера, давайте создадим новый пост, набрав команду:

~~~js
❯ Posts.find().count();
1
❯ Posts.insert({title: "A second post"});
'xxx'
❯ Posts.find().count();
2
~~~
<%= caption "First browser console" %>

Пост появился в локальной коллекции на клиенте. Давайте проверим MongoDB:

~~~bash
❯ db.posts.find();
{title: "A new post", _id: ObjectId("..")};
{title: "A second post", _id: 'yyy'};
~~~
<%= caption "The Mongo Shell" %>

Как вы видите, пост также сохранился и в нашей MongoDB, при этом мы не написали и строчки кода для этого (ну если точнее, мы все же написали одну строчку: `new Mongo.Collection('posts')`). Но и это еще не все!

Введите в консоли другого окна браузера:

~~~js
❯ Posts.find().count();
2
~~~
<%= caption "Second browser console" %>

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

Коллекция на клиенте сообщила коллекции на сервере, что у нее появился новый пост, и коллекция на сервере в свою очередь, добавила новый пост непосредственно в базу данных Mongo, и отправила обратно ко всем остальным коллекциям `post` на клиент.

Получать документы через браузерную консоль - не особо полезное занятие. Мы научимся, как связывать данные с шаблонами, и превращать этим простой HTML прототип в полностью функциональное real-time приложение.

### Наполнение базы данных

Просто отображать коллекции через браузерную консоль, но это не совсем то, что нам нужно. То, что мы действительно хотим - это отображать данные и их изменения на экране. Этим мы превратим наше приложение из коллекции статичных *страничек* в real-time *приложение* с динамическими, постоянно меняющимися данными.

Первое, что мы сделаем - это создадим некоторые записи в нашей MongoDB. Для этого создадим fixture-файл, который загрузит структурированные данные в нашу коллекцию `Posts`, когда сервер впервые запустится.

Для начала давайте убедимся в том, что наша база данных пуста. Для этого используем команду `meteor reset`, которая сотрет нашу БД и перезапустит проект. Само собой, нужно быть осторожным с этой командой, как только вы начнете работать над реальным проектом.

Прервите процесс Meteor, набрав в терминале `ctrl-c`, и после, введите команду:

~~~bash
meteor reset
~~~

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

Давайте опять запустим наше Meteor-приложение:

~~~bash
meteor
~~~

Теперь, когда наша база пуста, мы можем добавить в наше приложение следующий код, который загрузит три поста в коллекцию `Posts` при запуске сервиса, в случае, если она пуста:

~~~js
if (Posts.find().count() === 0) {
  Posts.insert({
    title: 'Introducing Telescope',
    url: 'http://sachagreif.com/introducing-telescope/'
  });

  Posts.insert({
    title: 'Meteor',
    url: 'http://meteor.com'
  });

  Posts.insert({
    title: 'The Meteor Book',
    url: 'http://themeteorbook.com'
  });
}
~~~
<%= caption "server/fixtures.js" %>

<%= commit "4-2", "Added data to the posts collection." %>

Мы поместили этот файл в директорию `server/`, так что он никогда не будет загружен в браузер пользователя. Код исполнится сразу же после того, как сервер будет запущен, и методом `insert` добавит три простых поста в нашу коллекцию `Posts`. 

Теперь снова запустите сервер командой `meteor`, и эти три поста будут загружены в базу данных.

### Динамические данные

Теперь, открыв браузерную консоль, мы увидим, что все три поста загружены также и в MiniMongo:

~~~js
❯ Posts.find().fetch();
~~~
<%= caption "Browser console" %>

Чтобы добавить эти данные к нашим HTML шаблонам, мы будем использовать template helpers. 

В Главе 3 мы показали, каким образом Meteor позволяет привязывать *контекст данных* к шаблонам Spacebars, чтобы построить HTML представление, исходя из простых структур данных. Мы можем таким же образом привязать к представлениям данные из наших коллекций. Давайте заменим статичный объект JavaScript `postsData` на динамический из нашей коллекции.

Просто удалите код 'postsData', вот как теперь должен выглядеть файл `posts_list.js`:

~~~js
Template.postsList.helpers({
  posts: function() {
    return Posts.find();
  }
});
~~~
<%= caption "client/templates/posts/posts_list.js" %>
<%= highlight "2~4" %>

<%= commit "4-3", "Wired collection into `postsList` template." %>

<% note do %>

### Find и Fetch

В Meteor, метод `find()` возвращает *курсор*, который является [реактивным источником данных](http://docs.meteor.com/#find). Когда мы хотим вывести его содержимое, мы можем использовать на нем метод `fetch()`, который трансформирует его содержимое в массив.

На деле же, Meteor достаточно умен, чтобы знать, как обращаться с курсорами без нашего вмешательства, вроде трансформации курсора в массив. Поэтому вы не часто будете использовать `fetch()` в коде Meteor-приложения (в коде нашего Microscope в том числе).

<% end %>

Теперь, вместо того, чтобы доставать из курсора список постов в виде массива, мы просто возвращаем курсор в нашем helper’е 'posts'. И чего же мы добьемся таким образом? Если вернемся в браузер, то мы увидим:

<%= screenshot "4-3", "Using live data" %>

Отчетливо видно, что наш helper `{{#each}}` успешно пробежался по всем документам в коллекции Posts и вывел их на экран. Коллекция на сервере достала посты из MongoDB, передала их в коллекцию уже на клиенте, и далее наш helper передал эти данные в шаблон.

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

~~~js
❯ Posts.insert({
  title: 'Meteor Docs',
  author: 'Tom Coleman',
  url: 'http://docs.meteor.com'
});
~~~
<%= caption "Browser console" %>

Теперь вернемся в браузер, и увидим следующее:

<%= screenshot "4-4", "Adding posts via the console" %>

Вы только что увидели реактивность в действии. Когда мы сказали Spacebars пробежаться по курсору `Posts.find()`, он также автоматически начал следить за состоянием этого курсора, и в случае его изменения, будет обновлять наш HTML, отображая на экране актуальные данные.

<% note do %>

### Отслеживаем изменения DOM

В этом случае, самый простой способ внести изменения - просто добавить еще один `<div class="post">...</div>`. Если вы хотите убедиться, что Meteor действительно сделал именно это, то откройте DOM Inspector и выберите `<div>` соответствующий одному из постов.

Далее, добавьте с помощью консоли еще один пост. Когда вы вернетесь обратно в инспектор, то увидите еще один `<div>`, отражающий только что созданный пост, но при этом у вас останется выбранным *существующий* `<div>`. Это очень действенный способ проверить, какой элемент был обновлен, а какой остался нетронутым.

<% end %>

### Синхронизируем коллекции: публикации и подписки

До этого момента, у нас был включен пакет `autopublish`, который не предназначен для production-режима. Как и можно понять из его имени, этот пакет просто говорит приложению, что каждая серверная коллекция должна быть полностью синхронизирована с каждой коллекцией на клиенте. Это не совсем то, чего мы хотим, так что давайте его отключим.

Откройте новое окно терминала и введите:

~~~bash
$ meteor remove autopublish
~~~

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

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

Для этого мы создадим функцию `publish()`, которая возвращает курсор со ссылкой на все посты:
 
~~~js
Meteor.publish('posts', function() {
  return Posts.find();
});
~~~
<%= caption "server/publications.js" %>

На клиенте мы должны, в свою очередь, *подписаться* на эту публикацию. Просто добавьте следующую строку в файл `main.js`:

~~~js
Meteor.subscribe('posts');
~~~
<%= caption "client/main.js" %>

<%= commit "4-4", "Removed `autopublish` and set up a basic publication." %>

Если мы снова проверим браузер, то увидим, что наши посты вернулись. Ура!

### Заключение

Чего же мы в итоге добились? Хотя у нас пока нет пользовательского интерфейса, наше приложение уже полностью функционально. Мы уже можем опубликовать его в интернете, и (используя консоль браузера) начать добавлять новые посты, которые будут появляться в браузерах других пользователей по всему миру.