Meteor全栈开发平台 - 不单单是前端

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接，博客地址为http://www.cnblogs.com/jasonnode/ 。网站上有对应每一小节的在线练习你们能够去试试。

全栈开发平台 - 不只仅是前端

Meteor和那些名声如雷贯耳的前端框架，好比Angular, React等都不同，它是一个 采用单一开发语言的全栈开发的平台：开发者可使用JavaScript同时 进行前端和后端的开发，而后交给Meteor运行这个包含了先后端的完整应用：

 从图中你能够看到，Meteo在前端使用浏览器做为基础运行环境，在后端则是以NodeJS做为 基础运行环境，以MongoDB做为数据持久化系统。

Meteor提供了一个横跨前端和后端的中间层平台，预置封装了不少功能库，简化了 Web应用的开发：使用单一语言快速开发Web应用，这是Meteor的最重要诉求。

初识Meteor

从构成来说，能够认为Meteor开发平台由两部分构成：

• Meteor库 - 以功能包的形式存在，封装了诸如实时通讯、反应式编程之类的核心功能。当 一个Meteor应用启动时，Meteor会自动加载这些库，为应用提供了一个基础环境。

• Meteor工具 - 能够理解为命令行方式的开发环境，它使咱们能够轻松地管理整个应用 开发流程：从建立应用、调试应用、自动化测试到打包、部署、热升级。

如今，让咱们让咱们使用Meteor命令行工具meteor建立并启动第一个Meteor应用吧。

≡ 建立应用 —— meteor create [project]

在终端中输入meteor create test,而后按回车：

~$ meteor create test↵

这个命令将在当前目录下建立一个子文件夹test，Meteor将使用内置的应用模板 做为这个文件夹的内容。咱们能够进入test文件夹，执行ls命令查看一下内容：

~$ cd test↵
~/test$ ls -al↵

你能够看到Meteor建立了3个文件和1个目录。

• test.css - 前端的样式表文件
• test.html -前端的HTML文件
• test.js - 前端/后端共用的JavaScript文件。全栈，对吧O(∩_∩)O~
• .meteor - 这个子目录是Meteor应用必须的特殊子目录，由Meteor平台维护，咱们不要动

先略过3个文件的具体内容，咱们运行起来看看。

 

≡ 运行应用 —— meteor run

执行meteor命令启动应用，在终端中输入meteor，这等价于运行meteor run：

~/test$ meteor↵

当你看到终端中出现下面的提示信息：

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

恭喜！咱们的第一个Meteor应用已经运行起来了！

≡ 中止应用运行 —— Ctrl+C

用鼠标左键点击一下终端区域，确保它得到键盘输入焦点（你应该能够看到一个 闪烁的光标），而后同时按Ctrl键和C键，便可中止应用运行：

^C
~/test$

≡ 复位应用数据 —— meteor reset

Meteor应用运行时会生成打包文件、建立应用数据库。可使用下面命令 清理这些生成的文件和应用数据：

~/test$ meteor rest↵

meteor reset命令不影响你的源代码文件。

模板文件 - test.html

打开test.html，你可能会略有不适：

它不是一个标准的HTML文件：没有html顶层标签，奇怪的符号{{> hello}}... 不过，在Metoer中这样的文件倒是合法的文件 —— 模板文件。

≡ 模板顶层标签 —— head/body/template

Meteor规定，在一个模板文件里，只能出现三种顶层标签：head、body和template。 也就是说，模板文件只能包含以这三种标签为顶层标签的HTML片断。

这是由于，Meteor在运行应用以前有一个打包/bundle的过程，此时Meteor会提取全部 模板文件（一个应用中能够有多个模板文件）中的head、body和template片断，分别进行 合并、编译后才呈现给用户：

上图中，a.html和b.html中的head片断合并后做为最终的head内容，b.html和c.html中 的body片断合并后做为最终的body内容，至于c.html中的template的内容，则最终替换了 b.html中的{{> hello}}。

≡ 模板语言 —— Spacebars

Meteor的模板使用的语言是私有的spacebars语言，它基于流行的handlebars，经过 在HTML片断中嵌入模板标签（以两对大括号为边界）实现模板化。所以，Meteor的模板 其实就是HTML标签和模板标签的混合体。

{{> hello}}模板标签用来调用一个子模板，Meteor将在最终呈现给用户的HTML文档中， 使用子模板hello的内容进行原地替换。

特殊的template标签用来定义一个子模板。

{{counter}}模板标签执行插值工做，Meteror将在最终呈现给用户的HTML文档中，使用 标识符counter对应的值进行原地替换。

样式文件 - test.css

和模板文件相似，Meteor在打包过程当中，会将全部的样式文件合并成一个大的样式文件， 而后在呈现给用户的HTML文档中引用这个样式文件：

上图中，a.css和b.css的内容将被合并为一个文件，并在最终呈现给用户的HTML文档中， 使用link标签引用这个文件。

代码文件 - test.js

test.js是最有趣的文件，Meteor将在前端和后端同时运行这个文件。能够这样理解：

• 前端 - Meteor将在最终呈现给用户的HTML文档中使用script标签引用test.js
• 后端 - Meteor将经过NodeJS读入并运行test.js

毫无疑问，若是不作任何处理，谁也无法保证一段JS代码既能够在前端浏览器环境中运行， 也能够在后端NodeJS中运行。在test.js中，咱们须要判断当前的具体运行环境，以便 执行相应的代码。

≡ 判断代码执行环境 —— Meteor.isClient/Meteor.isServer

让同一个js文件便可以跑在前端，也能够跑在后端（好比NodeJS），已经有不少 应用了，只须要判断下在某个特定环境才存在的变量就能够了（好比，NodeJS有global，而 浏览器有window）。Meteor提供了一组更加清晰的API来实现这个判断：

• Meteor.isClient - 为真时，表示当前运行环境为前端
• Meteor.isServer - 为真时，表示当前运行环境为后端

你能够看到，在test.js中也是这么作的：

//test.js
if(Meteor.isClient){
  //仅在前端执行的代码块
}
if(Meteor.isServer){
  //仅在后端执行的代码块
}

≡ 先后端都执行的代码

很显然，若是在test.js中，不判断执行环境的代码将同时在前端和后端运行。好比：

//test.js
console.log("Hello,Meteor!");
if(Meteor.isClient){...}
if(Meteor.isServer){...}

运行应用后，你将在后台的终端中看到Hello,Meteor!，也将在前台的调试台 中看到相同的输出。

前端代码 - 模板实例对象

回忆下，在模板文件test.html中，咱们定义了一个模板：

<!--test.html-->
<template name="hello">
  <button>Click Me</button>
  <p>You've pressed the button {{counter}} times.</p> 
</template>

当Meteor运行这个应用时，将自动建立一个对应的模板实例对象:Template.hello。 对模板的数据绑定和事件绑定，这些一般须要使用JavaScript实现的功能，就经过这 个对象来实现:

在hello模板中，{{counter}}模板标签中的标识符couter的值，将由对应模板实例 对象的counter函数返回值决定，这个函数被称为模板的helper函数，使用模板实例的 helpers()方法声明模板标签中标识符对应的helper函数。

而经过模板实例对象的events方法，则为模板中的button元素挂接了click事件监听处理 函数。

前端代码 - 模板标签标识符解析/helper

使用Template.hello.helpers(helpers)方法声明hello模板中模板标签标识符的解析函数。参数helpers是一个JS对象，属性表示应用在模板标签中的标识符，值 一般是一个函数，被称为helper，大体是帮助Meteor解析模板中的标识符的值 这样的意思。

好比，在test.js中咱们为hello模板中出如今{{counter}}模板标签中的counter表达 式声明其对应的helper函数：

//test.js
Template.hello.helpers({
  'counter':function(){
    return Session.get('counter');
  }
});

每次当Meteor须要对模板标签{{counter}}进行计算时，都将调用其counter标识符 对应的helper函数进行计算：它简单地返回Session变量counter的当前值。

≡ 为helper函数设定参数

helper函数能够接受参数，好比对于模板test中的displayName标识符：

<template name="test">
  <h1>Hello,{{displayName "Jason" "Mr."}}!</h1>
</template>

声明以下的helper函数：

Template.test.helpers({
  'displayName' : function(name,title){
    return title + ' ' + name;
  }
});

那么Meteor渲染后将得到以下的HTML结果：

<h1>Hello,Mr. Jason!</h1>

≡ 使用常量helper

固然，也能够将helper定义为一个常量：

Template.test.helpers({
  displayName : "Mr. WHOAMI"
})

这时，模板标签{{displayName}}将永远地被设定为固定的值了。

后端代码

在test.js中，后端代码几乎是空的，除了使用Meteor.startup(func)声明 了一个空的初始化函数。

Meteor.startup(func)方法在前端和后端都是可用的。参数func指定了 一个初始化函数，当平台就绪时，将调用这个初始化函数。

当在前端调用这个函数时，平台的就绪意味着DOM已经就绪，这时你能够进行DOM操做了：

//client side
Meteor.startup(function(){
  //jQuery对象在Meteor前端老是可用的
  $("<h1>Hello,world</h1>").appendTo("body");
});

当在后端调用这个函数时，平台的就绪意味着Meteor平台的服务进程已经正常启动，能够 进行应用层级的初始化工做了，好比，为空的后端数据集填充一些数据：

//server side
Meteor.startup(function(){
  var persons = new Mongo.Collection("persons");
  if(persons.find().count() === 0){
    persons.insert({...});
  }
});

应用目录结构

一个Meteor应用由目录下的前端文件（HTML、CSS、脚本、资源文件等）和后端文件组成。 因为Meteor存在一个打包/bundle的阶段，所以，Meteor对应用的目录结构进行了约定， 以便其打包过程可以顺利完成。

默认状况下，Meteor会搜索应用目录（包括子目录）中的全部JavaScript文件，打包后分别 送往前端和后端运行，文件和子目录的名称会影响打包结果。Meteor对如下的子目录将特别处理：

≡ client —— 参与打包的前端代码文件夹

任何名称为client的目录，其文件都不会被送日后端运行。这相似于使用if(Meter.isClient){...} 进行前端代码隔离的效果。

在生产模式下，client目录里的文件将被自动合并、压缩，但在开发模式下，JavaScript 文件和CSS文件并不进行压缩处理（CSS仍是会合并，但JavaScript文件不进行合并处理），以便于 开发过程当中的调试和错误定位。

Meteor会搜索目录中全部的模板文件中的三个顶层元素：head, body, template，其中全部 的head段会合并，body段和template段的声明都将转换为模板操做的JavaScript代码。

≡ server —— 参与打包的后端代码文件夹

任何名称为server的目录，其文件都不会送往前端运行。这相似于使用if(Meteor.isServer){...} 进行后端代码隔离的效果，但不一样的是，server目录内的部分代码不会发送到前端，所以一些敏感的 代码（好比身份验证等）应当放在这个目录。

Meteor会收集除了client, public和private子目录以外的全部JS文件，而后交给后端NodeJS 运行。后端的JavaScript代码对每一个请求将使用一个单独的线程来处理，这不一样于一般NodeJS的异步 代码模式，由于Meter认为这种模式更适合Meteor应用场景。

≡ public —— 不参与打包的前端资源文件夹

应用根目录下public子目录中的文件仅用于前端，这些文件不会被打包，可视为http访问的虚拟根目录。 例如，public目录下的logo.jpg文件，能够经过url："/log.jpg"来访问。这个目录能够用来放置favicon.ico, robots.txt，或者一些静态的HTM文件。

≡ client/compatibility —— 不参与打包的前端兼容库目录

有些前端JavaScript库依赖于使用var定义的全局变量。为了兼容这些库，这个目录里的文件在被送 往前端时，不会被嵌套在一个做用域中，而且会在其余前端JavaScript文件以前先执行。

≡ tests —— 仅用于测试的文件夹

任何名为test的目录内的文件仅用于测试，前端和后端都不会使用。

内容小结

让咱们简单回顾这个示例Meteor应用的开发过程（伪装没有使用meteor工具）：

1. 建立模板文件test.html，定义文档结构
2. 建立样式文件test.css，定义文档样式
3. 编写前端脚本test.js，实现模板、数据、事件的绑定
4. 在这个示例中，咱们基本不须要编写后端脚本

这些就绪后，扔给Meteor运行就能够了。

这有点像Apache+PHP或者IIS+ASP这些东西，Meteor提供一个基本的运行环境，你往 里面扔一个模板，立马就能够看到效果，你编写一段后端脚本，立马加强了服务器的 能力。那么，Meteor和它们的区别在哪里呢？

≡ 横跨先后端的中间层平台

在前面的课程中，咱们看到，前端和后端同时都有一个Meteor对象做为API入口（固然， 前端的Meteor对象和后端的Meteor对象不是彻底相同的实现），可使用Meteor.isClient或 Meteor.isServer判断代码运行环境，可使用一样的Meteor.startup()方法分别在 前端和后端注入初始化代码。这意味着什么？

让我把最开始的那张示意图中的Meteor层再细化一下：

很显然，Meteor最不同凡响的是，使用同一套代码，同时在前端和后端提供了应用运行的 基础环境。不得不提的是，Meteor平台在前端基础环境和后端基础环境之间，甚至已经基于 websocket创建了一个双向实时的通道！