13-voting.md.erb

---
title: Голосование
slug: voting
date: 0013/01/01
number: 13
points: 10
photoUrl: http://www.flickr.com/photos/ikewinski/8561920811/
photoAuthor: Mike Lewinski
contents: Построим систему, чтобы пользователи могли голосовать за пост.|Расположим наши посты по количеству голосов на специальной странице "лучшее".|Научимся создавать глобальные handlebars helper'ы.|Узнаем больше о безопасности данных в Meteor.|Затронем некоторые интересные принципы производительности в MongoDB.
paragraphs: 49
---

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

Мы можем сделать сложную систему оценивания с кармой, уменьшающимися со временем очками, или еще каким-нибудь из многих способов (большинство которых уже сделаны в [Telescope](http://telesc.pe), старшем брате Microscope). Но для нашего приложения мы не будем городить что-то сложное, а просто оценим посты по количеству полученных за пост голосов.

Начнем с того, что дадим возможность пользователям голосовать за посты. 

### Модель Данных

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

<% note do %>

### Приватность Данных и Публикации

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

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

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

<% end %>

Мы так же денормализуем общее количество голосовавших за пост для того, чтобы было легче получать эти данные. Для этого мы добавим два дополнительных атрибута  к нашим 'постам' - 'проголосовавшие' (`upvoters`) и 'голоса' (`votes`). Давайте начнем с того, что добавим их в наш fixture-файл:

~~~js
// Fixture данные 
if (Posts.find().count() === 0) {
  var now = new Date().getTime();
  
  // создадим двух пользователей
  var tomId = Meteor.users.insert({
    profile: { name: 'Tom Coleman' }
  });
  var tom = Meteor.users.findOne(tomId);
  var sachaId = Meteor.users.insert({
    profile: { name: 'Sacha Greif' }
  });
  var sacha = Meteor.users.findOne(sachaId);
  
  var telescopeId = Posts.insert({
    title: 'Introducing Telescope',
    userId: sacha._id,
    author: sacha.profile.name,
    url: 'http://sachagreif.com/introducing-telescope/',
    submitted: now - 7 * 3600 * 1000,
    commentsCount: 2,
    upvoters: [], votes: 0
  });
  
  Comments.insert({
    postId: telescopeId,
    userId: tom._id,
    author: tom.profile.name,
    submitted: now - 5 * 3600 * 1000,
    body: 'Интересный проектик, Sacha, можно я тоже приму участие?'
  });
  
  Comments.insert({
    postId: telescopeId,
    userId: sacha._id,
    author: sacha.profile.name,
    submitted: now - 3 * 3600 * 1000,
    body: 'Разумеется можешь, Tom!'
  });
  
  Posts.insert({
    title: 'Meteor',
    userId: tom._id,
    author: tom.profile.name,
    url: 'http://meteor.com',
    submitted: now - 10 * 3600 * 1000,
    commentsCount: 0,
    upvoters: [], votes: 0
  });
  
  Posts.insert({
    title: 'The Meteor Book',
    userId: tom._id,
    author: tom.profile.name,
    url: 'http://themeteorbook.com',
    submitted: now - 12 * 3600 * 1000,
    commentsCount: 0,
    upvoters: [], votes: 0
  });
  
  for (var i = 0; i < 10; i++) {
    Posts.insert({
      title: 'Test post #' + i,
      author: sacha.profile.name,
      userId: sacha._id,
      url: 'http://google.com/?q=test-' + i,
      submitted: now - i * 3600 * 1000,
      commentsCount: 0,
      upvoters: [], votes: 0
    });
  }
}
~~~
<%= caption "server/fixtures.js" %>
<%= highlight "22, 48, 58, 69" %>

Как всегда, запустив `meteor reset` перезапустим приложение, и создадим нового пользователя. Так же давайте убедимся в том, что два новых атрибута инициализировались при создании нового поста:

~~~js
//...

// проверим не было ли уже постов с такой же ссылкой
if (postAttributes.url && postWithSameLink) {
  throw new Meteor.Error(302, 
    'Эта ссылка уже была опубликована', 
    postWithSameLink._id);
}

// возьмем только нужные (безопасные) поля
var post = _.extend(_.pick(postAttributes, 'url', 'title', 'message'), {
  userId: user._id, 
  author: user.username, 
  submitted: new Date().getTime(),
  commentsCount: 0,
  upvoters: [], 
  votes: 0
});

var postId = Posts.insert(post);

return postId;

//...
~~~
<%= caption "collections/posts.js" %>
<%= highlight "16~17" %>

### Создаем Шаблоны для Голосования

Сначала добавим кнопку для голосования в часть, отвечающую за посты:

~~~html
<template name="postItem">
  <div class="post">
    <a href="#" class="upvote btn">⬆</a>
    <div class="post-content">
      <h3><a href="{{url}}">{{title}}</a><span>{{domain}}</span></h3>
      <p>
        {{votes}} Votes,
        submitted by {{author}},
        <a href="{{pathFor 'postPage'}}">{{commentsCount}} comments</a>
        {{#if ownPost}}<a href="{{pathFor 'postEdit'}}">Edit</a>{{/if}}
      </p>
    </div>
    <a href="{{pathFor 'postPage'}}" class="discuss btn">Discuss</a>
  </div>
</template>
~~~
<%= caption "client/views/posts/post_item.html" %>
<%= highlight "3,7" %>

<%= screenshot "13-1", "Кнопка голосования" %>

Далее вызовем Метод, отвечающий за голосование, когда пользователь кликнет по кнопке:

~~~js
//...

Template.postItem.events({
  'click .upvote': function(e) {
    e.preventDefault();
    Meteor.call('upvote', this._id);
  }
});
~~~
<%= caption "client/views/posts/post_item.js" %>
<%= highlight "3~8" %>

И в конце, изменим наш `collections/posts.js` файл и добавим Метод на серверной стороне, который будет увеличивать голоса для поста:

~~~js
Meteor.methods({
  post: function(postAttributes) {
    //...
  },
  
  upvote: function(postId) {
    var user = Meteor.user();
    // удостоверимся, что пользователь залогинен
    if (!user)
      throw new Meteor.Error(401, "Надо залогиниться чтобы голосовать");
    
    var post = Posts.findOne(postId);
    if (!post)
      throw new Meteor.Error(422, 'Пост не найден');
    
    if (_.include(post.upvoters, user._id))
      throw new Meteor.Error(422, 'Вы уже голосовали за этот пост');
    
    Posts.update(post._id, {
      $addToSet: {upvoters: user._id},
      $inc: {votes: 1}
    });
  }
});
~~~
<%= caption "collections/posts.js" %>
<%= highlight "6~23" %>

<%= commit "13-1", "Добавили простой алгоритм голосования." %>

Этот Метод достаточно прямолинеен. Сначала мы делаем парочку проверок, чтобы удостовериться что пользователь залогинен, и что пост действительно существует. После этого проверяем, голосовал ли уже пользователь за этот пост. Если не голосовал, мы увеличиваем общее количество голосов за пост на один, и добавляем пользователя к полю "upvoters".

Заключительный шаг интересен тем, что мы использовали пару новых Mongo операторов. Существует множество других операторов, которые следует знать - но этот чудовищно полезен: `$addToSet` добавляет элемент к массиву только в том случае, если такового еще в нем нет, а оператор `$inc` попросту увеличивает на единицу цифровое поле.

### Прокачиваем Пользовательский Интерфейс

Если пользователь не залогинен, то он не сможет проголосовать. Чтобы отразить это в нашем дизайне, добавим helper, который по условию добавит `disabled` CSS класс к кнопке "Проголосовать".

~~~html
<template name="postItem">
  <div class="post">
    <a href="#" class="upvote btn {{upvotedClass}}">⬆</a>
    <div class="post-content">
      //...
  </div>
</template>
~~~
<%= caption "client/views/posts/post_item.html" %>
<%= highlight "3" %>

~~~js
Template.postItem.helpers({
  ownPost: function() {
    //...
  },
  domain: function() {
    //...
  },
  upvotedClass: function() {
    var userId = Meteor.userId();
    if (userId && !_.include(this.upvoters, userId)) {
      return 'btn-primary upvotable';
    } else {
      return 'disabled';
    }
  }
});

Template.postItem.events({
  'click .upvotable': function(e) {
    e.preventDefault();
    Meteor.call('upvote', this._id);
  }
});
~~~
<%= caption "client/views/posts/post_item.js" %>
<%= highlight "8~15, 19" %>

Мы меняем наш класс с `.upvote` на `.upvotable`, поэтому надо не забыть также изменить обработчик на клик.

<%= screenshot "13-2", "Обесцвечиваем кнопку голосования." %>

<%= commit "13-2", "Обесцветили кнопку голосования если пользователь незалогинен / уже голосовал." %>

Вы наверное заметили, что посты, у которых есть всего один голос, отмечены как "1 vote**s**". Пора нам сделать так, чтобы окончания ставились правильно. Делать множественную форму числа - это довольно сложный процесс, но мы пока сделаем все достаточно просто (*примечание*: в отличии от английского языка, в русском нам понадобилось бы немного доработать оригинальный helper, потому что нам понадобится еще одно условие когда количество голосов равно двум, а кроме того  окончания еще и будут зависеть от рода, но это все мы опустим, ибо наш сайт работает на английском). Мы создадим такой Handlebars helper, который мы сможем использовать повсюду:

~~~js
UI.registerHelper('pluralize', function(n, thing) {
  // простой как барабан pluralizer
  if (n === 1) {
    return '1 ' + thing;
  } else {
    return n + ' ' + thing + 's';
  }
});
~~~
<%= caption "client/helpers/handlebars.js" %>

Все helper'ы, которые мы создали до этого были привязаны к менеджеру и шаблону, к которым они применялись. Но если использовать `UI.registerHelper`, мы создадим *глобальный* helper, который мы сможем использовать с любым шаблоном:

~~~html
<template name="postItem">
//...
<p>
  {{pluralize votes "Vote"}},
  submitted by {{author}},
  <a href="{{pathFor 'postPage'}}">{{pluralize commentsCount "comment"}}</a>
  {{#if ownPost}}<a href="{{pathFor 'postEdit'}}">Edit</a>{{/if}}
</p>
//...
</template>
~~~
<%= caption "client/views/posts/post_item.html" %>
<%= highlight "4, 6" %>

<%= screenshot "13-3", "Совершенствуем омножествитель." %>

<%= commit "13-3", "Добавили helper для выставления правильного окончания." %>

Теперь мы должны увидеть "1 vote".

### Более Умный Алгоритм Голосования

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

С этим есть пару нюансов. Во-первых, не очень то эффективно два раза обращаться к базе данных. А во-вторых, что более важно, у нас появляется так называемое состояние гонки (англ. race condition). В нашем случае мы как бы следуем по такому алгоритму:

1. Взять пост из базы данных.
2. Проверить голосовал ли пользователь за этот пост.
3. Если не голосовал, то проголосовать.

Однако что если тот же пользователь будет голосовать за один и тот же пост в промежутке между первым и третьим шагами? Наш текущий код позволит проголосовать за один и тот же пост дважды. Хорошо что на этот счет Mongo позволяет нам быть умнее, объединив первый и третий шаги в один вызов:

~~~js
Meteor.methods({
  post: function(postAttributes) {
    //...
  },
  
  upvote: function(postId) {
    var user = Meteor.user();
    // удостоверимся, что пользователь залогинен
    if (!user)
      throw new Meteor.Error(401, "Надо залогиниться чтобы голосовать");
    
    Posts.update({
      _id: postId, 
      upvoters: {$ne: user._id}
    }, {
      $addToSet: {upvoters: user._id},
      $inc: {votes: 1}
    });
  }
});
~~~
<%= caption "collections/posts.js" %>
<%= highlight "12~15" %>

<%= commit "13-4", "Улучшенный алгоритм голосования." %>

То, что мы говорим этим, так это "найти все посты вот с этим `id`, где пользователь еще не голосовал, и обновить их таким вот образом". Если пользователь *еще не* проголосовал, то, конечно же, найдется пост с таким `id`. А если пользователь *уже* проголосовал, то результатом запроса будет пустое множество, и далее ничего не произойдет.

Обратной стороной данного подхода является то, что теперь мы не сможем сказать голосовал ли уже пользователь за этот пост (поскольку мы избавились от запроса в базу данных на соответствующую проверку). Но пользователь и так поймет, голосовал ли он, если кнопка "Проголосовать" будет неактивной.

<% note do %>

### Компенсация Задержки

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

~~~js
> Posts.update(postId, {$set: {votes: 10000}});
~~~
<%= caption "Консоль браузера." %>

(Где `postId` это id вашего поста)

Такого рода наглая попытка поиграть с системой будет поймана нашим `deny()` callback-ом (тот что `collections/posts.js`, помните?) и будет немедленно сведена на нет.

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

Так что же произошло? В нашей локальной коллекции `Posts` обновление произошло без происшествий. Это случилось молниеносно, и наш пост переместился на первое место. В это время на сервере в таком такое обновлении было отказано. Поэтому некоторое время спустя (речь идет о нескольких миллисекундах, если вы пользуетесь Meteor'ом на своей локальной машине), сервер вернул error, тем самым говоря локальной коллекции откатиться обратно. 

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

<% end %>

### Ранжируем Посты на Главной Странице

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

Начнем с того, что нам нужно *две* подписки, одна на каждый вид выборки, или, можно сказать, тип сортировки. Магия тут в том, что обе подписки будут подписаны на одну и ту же коллекцию, но только с разными аргументами!

Мы так же создадим два маршрута, `newPosts` и `bestPosts`, доступных по адресам `/new` и `/best`, соответственно (с учетом использования, например, `/new/5` и `/best/5` для нужд перелистывания на соответствующую страницу).

Для этого мы *расширим* наш `PostsListController` контроллер через два различных контроллера `NewPostsListController` и `BestPostsListController`. Это позволит нам использовать те же самые параметры маршрутизации для маршрутов `home` и `newPosts`, дав `NewPostsListController` контроллеру наследование. К тому же это классная демонстрация того, насколько гибким может быть Iron Router.

~~~js
PostsListController = RouteController.extend({
  template: 'postsList',
  increment: 5, 
  limit: function() { 
    return parseInt(this.params.postsLimit) || this.increment; 
  },
  findOptions: function() {
    return {sort: this.sort, limit: this.limit()};
  },
  waitOn: function() {
    return Meteor.subscribe('posts', this.findOptions());
  },
  posts: function() {
    return Posts.find({}, this.findOptions());
  },
  data: function() {
    var hasMore = this.posts().count() === this.limit();
    return {
      posts: this.posts(),
      nextPath: hasMore ? this.nextPath() : null
    };
  }
});

NewPostsListController = PostsListController.extend({
  sort: {submitted: -1, _id: -1},
  nextPath: function() {
    return Router.routes.newPosts.path({postsLimit: this.limit() + this.increment})
  }
});

BestPostsListController = PostsListController.extend({
  sort: {votes: -1, submitted: -1, _id: -1},
  nextPath: function() {
    return Router.routes.bestPosts.path({postsLimit: this.limit() + this.increment})
  }
});

Router.map(function() {
  this.route('home', {
    path: '/',
    controller: NewPostsListController
  });
  
  this.route('newPosts', {
    path: '/new/:postsLimit?',
    controller: NewPostsListController
  });
  
  this.route('bestPosts', {
    path: '/best/:postsLimit?',
    controller: BestPostsListController
  });
  // ..
});
~~~
<%= caption "lib/router.js" %>
<%= highlight "8,20,25~37,40~53" %>

Заметьте, что теперь когда у нас более чем один маршрут, мы выносим `nextPath` логику из `PostsListController` в `BestPostsListController`, поскольку путь будет различным в обоих случаях. 

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

Теперь, когда наш новый контроллер сделан, мы со спокойной душой можем удалить предыдущий `postsList` маршрут. Просто удалим следующий код:

```
 this.route('postsList', {
  path: '/:postsLimit?',
  controller: PostsListController
 })
```
<%= caption "lib/router.js" %>

Добавим так же ссылки в заголовок:

~~~html
<template name="header">
  <header class="navbar">
    <div class="navbar-inner">
      <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
      </a>
      <a class="brand" href="{{pathFor 'home'}}">Microscope</a>
      <div class="nav-collapse collapse">
        <ul class="nav">
          <li>
            <a href="{{pathFor 'newPosts'}}">New</a>
          </li>
          <li>
            <a href="{{pathFor 'bestPosts'}}">Best</a>
          </li>
          {{#if currentUser}}
            <li>
              <a href="{{pathFor 'postSubmit'}}">Submit Post</a>
            </li>
            <li class="dropdown">
              {{> notifications}}
            </li>
          {{/if}}
        </ul>
        <ul class="nav pull-right">
          <li>{{> loginButtons}}</li>
        </ul>
      </div>
    </div>
  </header>
</template>
~~~
<%= caption "client/views/include/header.html" %>
<%= highlight "9, 12~17" %>

Нам так же надо обновить наш обработчик удаления поста:

~~~html
  'click .delete': function(e) {
    e.preventDefault();
    
    if (confirm("Delete this post?")) {
      var currentPostId = this._id;
      Posts.remove(currentPostId);
      Router.go('home');
    }
  }
~~~
<%= caption "client/views/posts_edit.js" %>
<%= highlight "7" %>


Когда все это сделано, у нас теперь есть список постов ранжированных по количеству собранных голосов:

<%= screenshot "13-4", "Ранжируем по голосам." %>

<%= commit "13-5", "Добавили пути для списков постов и страницы для их отображения." %>

### Улучшенный Заголовок

Теперь когда у нас есть две страницы для отображения списка постов, трудно понять какой именно список мы сейчас смотрим. Поэтом давайте вернемся к заголовку для того, чтобы сделать его более очевидным. Мы создадим новый менеджер `header.js` и создадим helper, который будет использовать текущий путь и один или более именованных маршрутов для того, чтобы установить активный класс для нашей навигации:

Причина зачем нам необходимо поддерживать множество имен маршрутов в том, что оба маршрута `home` и `newPosts` (которые соответствуют путям `/` и `/new` соответственно) используют один и тот же шаблон. Это означает, что наш `activeRouteClass` должен быть достаточно умным, чтобы делать тэг `<li>` активным в обоих случаях.

~~~html
<template name="header">
  <header class="navbar">
    <div class="navbar-inner">
      <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
      </a>
      <a class="brand" href="{{pathFor 'home'}}">Microscope</a>
      <div class="nav-collapse collapse">
        <ul class="nav">
          <li class="{{activeRouteClass 'home' 'newPosts'}}">
            <a href="{{pathFor 'newPosts'}}">New</a>
          </li>
          <li class="{{activeRouteClass 'bestPosts'}}">
            <a href="{{pathFor 'bestPosts'}}">Best</a>
          </li>
          {{#if currentUser}}
            <li class="{{activeRouteClass 'postSubmit'}}">
              <a href="{{pathFor 'postSubmit'}}">Submit Post</a>
            </li>
            <li class="dropdown">
              {{> notifications}}
            </li>
          {{/if}}
        </ul>
        <ul class="nav pull-right">
          <li>{{> loginButtons}}</li>
        </ul>
      </div>
    </div>
  </header>
</template>
~~~
<%= caption "client/views/includes/header.html" %>
<%= highlight "9,12,15,19" %>

~~~js
Template.header.helpers({
  activeRouteClass: function(/* route names */) {
    var args = Array.prototype.slice.call(arguments, 0);
    args.pop();
    
    var active = _.any(args, function(name) {
      return Router.current() && Router.current().route.name === name
    });
    
    return active && 'active';
  }
});
~~~
<%= caption "client/views/includes/header.js" %>

<%= screenshot "13-5", "Показываем активную страницу." %>

<% note do %>

### Аргументы Helper'а

До этого момента мы не использовали какие-либо специальные конструкции. Так же, как и любые другие Handlebars тэги, тэги шаблонного helper'а тоже могут принимать аргументы.

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

В последнем случае, вы вероятно захотите сконвертировать `arguments` объект в обычный JavaScript массив, и затем вызвать `pop()` на него чтобы избавится от '/', добавленного в конец Handlebars'ом.

<% end %>

Для каждого пути `activeRouteClass` helper возьмет список маршрутных имен, а затем использует с ними Underscore'овский метод `any()` чтобы проверить, проходит ли любой из путей тест (проще говоря, совпадает ли наш URL с каким-либо путем из списка маршрутных имен).

Если какой-либо из путей совпадет с текущим путем, то `any()` вернет `true`. А еще мы воспользуемся особенностью pattern'а `boolean && string` в JavaScript, когда `false && myString` возвратит `false`, а `true && myString` возвратит `myString`.

<%= commit "13-6", "Добавили активные классы к заголовку." %>

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