Meteor 简介

简介

先来活动一下大脑。假设你坐在电脑面前，在两个窗口中打开同一个文件夹。

在其中一个窗口中删除一个文件，另一个窗口中的这个文件会消失吗？

不用实际操作你也知道肯定会消失的。在本地文件系统中的操作，不用刷新或者回调，变动就能应用到所有地方。

我们再来看一下相同的事情在网页中会有什么结果。例如，你在两个浏览器窗口中打开同一个 WordPress 后台页面，在其中一个窗口中新建了一篇文章。和桌面系统不同的是，不管等待多长时间，另一个窗口都不会发生变化，除非你手动刷新网页。

过去这些年，我们已经习惯了，人和网站之间的通信是离散的。

但是，作为新一代框架和技术之一的 Meteor，尝试挑战这一现状，让网页能够实时和响应。

Meteor 是什么？

Meteor 是一个构建在 Node.js 之上的平台，用来开发实时网页程序。Meteor 位于程序数据库和用户界面之间，保持二者之间的数据同步更新。

因为 Meteor 是基于 Node.js 开发的，所以在客户端和服务器端都使用 JavaScript 作为开发语言。而且，Meteor 程序的代码还能在前后两端共用。

Meteor 这个平台很强大，网页程序开发过程中的很多复杂、容易出错的功能都能抽象出来，实现起来很简单。

为什么使用 Meteor？

那么，你为什么要花时间学习 Meteor，而不去学其他框架呢？拨开 Meteor 的各种功能，我们认为原因只有一个：因为 Meteor 易于学习。

而且，和其他框架不同，使用 Meteor，几小时之内就能开发出一个正常运行的实时网页程序。如果之前做过前端开发，对 JavaScript 已经有所了解，甚至都不用再学习一门新的编程语言。

Meteor 可能就是你要找的理想框架，当然，也可能不是。既然只要几晚或一个周末就能上手，为什么不试试呢？

开始学习meteor

第一印象十分重要，安装 Meteor 并不会遇到什么困难。大多数情况下，在五分钟内便可以完成。

首先，如果在 Mac OS 或 Linux 系统下，你可以打开终端窗口，输入以下命令来安装 Meteor：

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

如果你使用 Windows 系统，请参考 Meteor 网站的 安装指导。

以上命令会在系统中安装 meteor 可执行文件，然后就可以使用 Meteor 了。

选择不安装 Meteor

如果你无法或者不想在本地安装 Meteor ，我们推荐你使用 Nitrous.io。

使用 Nitrous.io 可以让你在览器中直接编辑代码并运行程序。我们撰写了一篇简短的指南，介绍如何使用 Nitrous.io。

你可以一直阅读那篇指南直到“Installing Meteor”部分，然后再回到本章，从“创建简单的应用”一节开始阅读。

创建简单的应用

安装好 Meteor 之后，我们来创建一个应用。创建应用要使用 Meteor 的命令行工具 meteor：

$ meteor create microscope

上述命令会下载 Meteor，然后新建一个基本可用的 Meteor 项目。命令执行完成后，会看到新建了一个文件夹，名为microscope/，包含以下文件：

.meteor
microscope.css
microscope.html
microscope.js

Meteor 生成的应用只是一个简单的骨架，演示一些简单的模式。

虽然这个应用没什么功能，但也能运行。要运行应用，请切换到终端，输入下面的命令：

$ cd microscope
$ meteor

现在打开浏览器，访问 http://localhost:3000（或者等效的 http://0.0.0.0:3000），应该能看到下面的网页：

恭喜！你的第一个 Meteor 应用顺利运行了。顺便说一下，如果想停止运行程序，只要切换到对应的终端窗口按 ctrl+c键即可。

如果你使用 Git，正是时候用 git init 来初始化你的项目仓库。

再见 Meteorite

曾经有段时间，Meteor 依赖于外部代码包管理器 Meteorite。自从 Meteor 0.9.0 版本以后，就不再需要 Meteorite 了，因为它的功能已经融入 Meteor 之中。

所以，如果你在这本书或在浏览 Meteor 相关的资料时，遇到 Meteorite 的 mrt 命令行工具，你可以放心地用meteor 来替换它。

添加代码包

下面我们使用 Meteor 的 package 系统在项目中引入 Bootstrap 框架。

这与通常手动添加 Bootstrap 的 CSS 和 Javascript 文件的方法是没有区别的，只不过我们依赖代码包维护者来为我们更新这些文件。

既然我们说到此，我们也来添加 Underscore 代码包。 Underscore 是一个 JavaScript 工具库，对于操纵 JavaScript 数据结构非常有用。

截至写这本书时，underscore 代码包依然算作 Meteor “官方”的代码包，所以这个包没有作者：

meteor add twbs:bootstrap
meteor add underscore

注意的是现在我们添加了 Bootstrap 3。而这本书中的一些截图是老版本的 Microscope 使用 Bootstrap 2 时截取的，所有它们看起来会有稍微不同。

在 GitHub 上查看

一旦你添加了 Bootstrap 代码包，你应会注意到我们应用的变化：

与“传统”方式添加外部资源不同，我们还没有链接任何 CSS 或 JavaScript 文件，因为 Meteor 已经帮我们搞定了！这就是 Meteor 代码包的众多优势之一。

关于代码包

Meteor 中的代码包有点特殊，分为五种：

• Meteor 核心代码本身分成多个核心代码包（core package），每个 Meteor 应用中都包含，你基本上不需要花费精力来维护它们
• 常规 Meteor 代码包称为“isopack”，或同构代码包（isomorphic package，意味着它们既能在客户端也能在服务器端工作）。第一类代码包例如 accounts-ui 或 appcache 由 Meteor 核心团队维护，与 Meteor 捆绑在一起。
• 第三方代码包就是其他用户开发的 isopack 上传到 Meteor 的代码包服务器上。你可以访问 Atmosphere 或meteor search 命令来浏览这些代码包。
• 本地代码包（local package）是自己开发的代码包，保存在 /packages 文件夹中。
• NPM 代码包（NPM package）是 Node.js 的代码包，虽不能直接用于 Meteor，但可以在上述几种代码包中使用

Meteor 应用的文件结构

开始编写代码之前，我们必须要正确的设置项目。为了保证项目整洁，请打开 microscope 文件夹，删除microscope.html、microscope.js 和 microscope.css。

请在 microscope 文件夹中新建四个子文件夹：/client，/server，/public 和 /lib。然后在 /client 文件夹中新建两个空文件：main.html 和 main.js。如果程序无法运行了先别担心，从下一章开始我们会编写代码。

值得一提的是，上述文件夹中有一些拥有特别的作用。关于文件， Meteor 有以下几条规则：

• 在 /server 文件夹中的代码只会在服务器端运行。
• 在 /client 文件夹中的代码只会在客户端运行。
• 其它代码则将同时运行于服务器端和客户端上。
• 请将所有的静态文件（字体，图片等）放置在 /public 文件夹中。

知道 Meteor 以什么顺序加载文件也很有用：

• 在 /lib 文件夹中的文件将被优先载入。
• 所有以 main.* 命名的文件将在其他文件载入后载入。
• 其他文件以文件名的字母顺序载入。

需要注意的是，即便 Meteor 包含上述规则，这并不意味着它强制你为你的 Meteor 应用采用任何预设的文件结构。上述结构只是我们的建议，并不是一成不变的。

对此如果你想了解更多，我们强烈建议你参阅 Meteor 官方文档。

Meteor 采用 MVC 架构吗？

如果你之前有过在其它诸如 Ruby on Rails 框架下开发的经历，此时你心中可能会有这样的疑问， Meteor 采用 MVC（Model View Controller）架构吗？

简短的回答是，不。与 Rails 不同，Meteor 并不为你的应用强加任何预设的架构。因此本书将直接给出我们认为最合理的代码，而不对任何现有架构作过多考虑。

不需要 public 文件夹？

好吧，我们承认在之前小小的忽悠了大家一下。其实我们并不需要为我们的应用建立一个 public/ 文件夹，因为 Microscope 并不需要使用任何的静态文件。但是值得注意的是，大多数 Meteor 应用都会或多或少使用一些图片，因此我们觉得 public/ 文件夹还是值得一谈的。

另外，你可能注意到了一个隐藏的 .meteor 文件夹。这是 Meteor 存储它内部代码的地方，尝试更改里面的内容并不是什么好主意。事实上，你根本不需要关心其中的内容。有两个例外是 .meteor/packages 文件和 .meteor/release 文件。它们分别列出了你安装的所有智能代码包和你使用的 Meteor 版本。当你为你的应用添加代码包或更改 Meteor 版本时，查看这两个文件的变更可能会为你带来一些帮助。

下划线命名法 vs 驼峰命名法

对于历史悠久的下划线命名法（my_variable）和驼峰命名法（myVariable）我们认为选择哪种并不重要，只要你坚持在项目中贯彻它。

在本书中，我们将采用驼峰命名法，因为它是 JavaScript 中的惯例（毕竟它叫 JavaScript 而不是 java_script 呀！）。

对此唯一的例外是，对文件的命名，我们将采用下划线命名法（my_file.js）。对于 CSS 类，我们将使用连字号（.my-class）。这样做的原因是在文件系统中，下划线命名法最常见，而 CSS 语法本身就使用连字号作为连接（比如font-family，text-align等）。