06s-reactivity.md.erb

---
title: Reactivity
slug: reactivity
date: 0006/01/02
number: 6.5
sidebar: true
contents: Learn about Meteor's reactive code dependency system.|Understand the motivations and how it makes code declarative.|Learn to use advanced code that uses reactive data.
paragraphs: 20
version: 1.7
---

コレクションがMeteorのコアな機能だとすると、リアクティビリティは　そのコアを　便利にする（ shell？）です。

コレクションは　データの変化を処理するアプリケーションの（ way？）を　（radically？）に　（transform？）します。
たとえば、AJAXなどで人力でデータの変化をチェックして、
HTMLにその変化をパッチするよりも、
Meteorによって、データの変化がどんなときでも（ come in？）して、シームレスにユーザーインターフェースに適用することができます。

少し時間をとってこの点を考えてみます：
（underlying？）なコレクションが更新されると、Meteorは裏側でどんなユーザーインターフェースのパーツでも変化させます。　

これをするために必須な（way?）は、 .observe()を使うことです。
.observe()はドキュメントがカーソルの変化にマッチした時に　コールバックを（fiew?）する　カーソル関数です。　

~~~js
Posts.find().observe({
  added: function(post) {
    // when 'added' callback fires, add HTML element
    $('ul').append('<li id="' + post._id + '">' + post.title + '</li>');
  },
  changed: function(post) {
    // when 'changed' callback fires, modify HTML element's text
    $('ul li#' + post._id).text(post.title);
  },
  removed: function(post) {
    // when 'removed' callback fires, remove HTML element
    $('ul li#' + post._id).remove();
  }
});
~~~

こうしたコードが　どのようにして　（pretty quickly？）に　複雑化するのか　すでに分かっているかもしれません。
投稿ごとの属性の変化を処理すると想定すると、投稿の <li>内の複雑なHTMLを変化する必要があります。
（？？？）、（？？？？？？）

<% note do %>

### When *Should* We Use `observe()`?

上記のパターンを使うことは特に、サードパーティーのウィジットを(dealing with？)する時に必要となります。
たとえば、コレクションデータに基づいたリアルタイムなマップのピンを加えるか削除すると考えてみましょう。　　

その場合、Meteorコレクションと（ get the map to "talk" with？）して、
データの変化の反応を見分けるために、　observe()コールバックを使う必要があります。
一例をあげると、マップ API のdropPin() や removePin()メソッドを呼び出すために　addedとremoved コールバックを使うことになります。

<% end %>

### A Declarative Approach

Meteorではより良い方法が用意されています。　宣言型アプローチである　リアクティビリティです。
宣言型であることで、（specify behaviors for every possible change？）する代わりに
（once？）オブジェクト間の　関係を定義でき、同期されていることを（ know ？）できます。

これはパワフルなコンセプトです。（？？？）
なぜなら、リアルタイムシステムには　予期できない時にすべて変化できる　多くの入力データがあるからです。。

observeコールバックについて考える代わりに（　All this to say ？）、 Meteorでこのように書くことができます：

~~~html
<template name="postsList">
  <ul>
    {{#each posts}}
      <li>{{title}}</li>
    {{/each}}
  </ul>
</template>
~~~

その後で、このようにして投稿リストを呼んできます：

~~~js
Template.postsList.helpers({
  posts: function() {
    return Posts.find();
  }
});
~~~

裏側で、Meteorはobserve()コールバックにつないています。
また、　リアクティブデータが変化すると　関係のあるHTMLのセッションを再び取り出しています。（？？？）

### Dependency Tracking in Meteor: Computations

Meteorはリアルタイムでリアクティブなフレームワークですが、Meteorアプリの中の全てのコードがリアクティブというわけではありません。
この場合では、　何かが変わる度にアプリ全体が再実行することでしょう。（？？？）
その代わりに、リアクティビリティはコードの特定の範囲を制限されています。　
私たちはその範囲をコンピュテーションと呼んでいます。

コンピュテーションは　変化によってリアクティブデータソースを毎回実行しているコードのブロックです。（？？？）
たとえば、セッション変数　リアクティブデータソースを（have？）して　リアクティブに（ to it？）に反応したいとすると、
コンピュテーションを設定する必要があります。

しっかりとこの設定をする必要はありません。
というのは、Meteorがすでに　各テンプレートに　（special？）なコンピュテーションをレンダリングしているからです。
（　テンプレートヘルパー内のコードとコールバックは初期設定でリアクティブであるということ意味しています。）（？？？）

リアクティブデータソースは　いつその値が変化するか知らせることができるように（it？）を使って
すべてのコンピュテーションをトラッキングします。
そうするために、（ it？）はコンピュテーションで　invalidate()関数を呼び出します。

コンピュテーションは通常、無効化（on？）　再評価する内容　を設定します。（？？？）
そしてこれが　テンプレートコンピュテーションに　何が起きているかということです。　
（テンプレートコンピュテーションは　ページをより効率的に（try and redraw？）するマジックを使います。）
必要であれば　　（？？？）　無効化　コンピュテーションがすることを　さらにコントロールできますが、
実際これは　ほとんどの場合で　　あなたが使っている行動です。（？？？）

### Setting Up a Computation

私たちはコンピュテーションの裏側の仕組みを理解したので、　実際に（one？）を設定することは 不相応なほど（？？？）簡単そうです。

~~~js
Deps.autorun(function() {
  console.log('There are ' + Posts.find().count() + ' posts');
});
~~~

私たちは　Meteor.startup()ブロック内の Depsブロックをラップする必要があります。　
　Meteorが　Postsコレクションを　（loading？）終えた時に　（it ？）が実行します。（？？？）

~~~js
> Posts.insert({title: 'New Post'});
There are 4 posts.
~~~

すべての結果として、　　　私たちは　とても自然な方法で　リアクティブデータを使う　コードを書くことができます。
　依存システムは　裏側で　適切な時点で　再評価する　処理をします。　（？？？）