Much like CoffeeScript, Jade is a language that depends heavily on tabbing. When you want to add children to an HTML tag, you simply use tab. Tag IDs and classes can be added using the CSS selector notation ('input#name.first'). This means classes are expressed with a dot (.) and IDs are expressed with a pound (#). Let's look at an example:

//- JADE
div#container
  ul.list
    li(data-bind="clickable") Click me!

<!-- HTML – OUTPUT -->
<div id="container">
  <ul class="list">
    <li data-bind="clickable">Click me!</li>
  </ul>
</div>

As you can see, special attributes such as data-bind are added with parenthesis. Symbols such as <, >, and closures are not required anymore. In this example, we have a div tag with an id attribute of "container", a ul tag with a class attribute of list, and a li tag with a special attribute of data-bind.

You will find yourself using special attributes often for the input tags to add value, placeholder, and other attributes.

Meteor templates are Jade components. In Meteor, we define a template with the template tag and apply the special name attribute to create a reusable HTML block. In Jade, when we create a template, we create a component as well. This looks as follows:

//- JADE
template(name="landing")
  h3 Hello World!

<!-- HTML – OUTPUT -->
<template name="landing">
  <h3>Hello World!</h3>
</template>

Now we can use this template as a Jade component anywhere in our views. To call a Jade component, you simply prepend a plus sign to the name of the template. Let's look at an example where we want to place a landing page inside a main_layout page:

//- JADE
template(name="landing")
  h3 Hello World!

template(name="main_layout")
  +landing

<!-- HTML – OUTPUT -->
<template name="landing">
  <h3>Hello World!</h3>
</template>

<template name="main_layout">
  {{> landing}}
</template>

That's it! Notice that we have prepended the plus (+) sign to the name of the template to call it. This is equivalent to using {{> landing}} in SpaceBars (Meteor's version of Handlebars). Components can have parameters as well, which can be later used in the templates' instance. Let's make our example output someone's name:

//- JADE
template(name="landing")
  h3 Hello {{name}}

template(name="main_layout")
  +landing(name="Mr Someone")

# COFFEESCRIPT
Template.landing.helpers
  "name": ->
    Template.instance().data.name

<!-- HTML – OUTPUT -->
<template name="landing">
  <h3>Hello {{name}}</h3>
</template>

<template name="main_layout">
  {{> landing name="Mr Someone"}}
</template>

Adding attributes to your templates can make your templates flexible as shown in the preceding example. Still, it is unlikely that you will have to use this as templates "soak up" data from their parent context.

Helpers in Meteor are functions that return data before rendering to the view. We use helpers for iteration, logical statements, and variables. The two basic helpers are each and if, but adding the raix:handlebar-helpers package will add a dictionary of other useful helpers to keep your code from repeating. Let's have a look at how we can use our helpers:

//- JADE
template(name="list_of_things")
  each things
    if selected
      p.selected {{name}}
    else
      p {{name}}

<!-- HTML – OUTPUT -->
<template name="list_of_things">
  {{#each things}}
    {{#if selected}}
      <p class="selected">{{name}}</p>
    {{else}}
      <p>{{name}}</p>
    {{/if}}
  {{/each}}
</template>

In this example, the each helper is iterating through the return value of another helper named things and if the selected helper resolves to true, then we will render p.selected with the name variable.

It's important to understand that everything that is not an HTML tag is a helper, and that if you want to use a helper within a tag, you need to use {{}} or #{} to express this.

Go to jade-lang.com and handlebars.js to know more specific information. With this information, you should be able to do just about anything.

Stylus is a language that does away with the need for semicolons (;) and curly braces ({}) in exchange for making good use of tabbing. Let's look at an example:

// STYLUS
// Let's make a vertical positioning class
.vertical-align-middle
  //PART 1
  position:absolute
  width:100%
  height:100%
  display:table
  overflow-x:hidden

  .special
    background:black

We can see in PART 1 how properties are defined for a class by tabbing those properties in .special is used to select an HTML tag with the special class that is a child of the vertical-align-middle class. Let's look at how PART 1 compiles:

/* CSS – OUTPUT PART 1 */
.vertical-align-middle {
  position:absolute;
  width:100%;
  height:100%;
  display:table;
  overflow-x:hidden;
}
.vertical-align-middle .special {
  background:black;
}

Now let's add a more complex selector:

// STYLUS
// Let's make a vertical positioning class
.vertical-align-middle
  //PART 1
  ...

  //PART 2
  > *
    display:table-cell
    vertical-align:middle

PART 2 has a combination of special CSS2 selectors: specific parent (>) and all elements (*). In this particular order, the CSS2 selectors are picking the "any first sibling" element only and applying the rules. Let's look at how PART 2 compiles:

/* CSS – OUTPUT PART 2 */
.vertical-align-middle > * {
  display:table-cell;
  vertical-align:middle;
}

Let's add a new class to the current class that aligns the object to the top:

// STYLUS
// Let's make a vertical positioning class
.vertical-align-middle
  //PART 1
  ...
  //PART 2
  ...
  //PART 3
  &.whole-page
    top:0

PART 3 uses an ampersand (&) to describe an element that is not a child but instead is concatenated with the extra class. Let's look at how PART 3 compiles:

/* CSS – OUTPUT PART 3 */
.vertical-align-middle.whole-page {
  top:0;
}

Unlike CSS, Stylus supports variables. This keeps a lot of things manageable when we want to make major changes to the look of our site. Suppose we have two colors that we want to use throughout our site, but we know that these colors are going to change. Let's define them as variables so that we can easily modify them later:

// STYLUS
primary-color = #ffffff
$secondary-color = #333333

.text-default
  color:primary-color
  background:$secondary-color

.text-inverted
  color:$secondary-color
  background:primary-color

Easy right? In this example, both primary-color and $secondary-color are variables. Stylus optionally supports the use of the money sign ($) to indicate a variable. This can make it easier to spot variables.

Unlike CSS, Stylus supports functions too. LESS, Stylus, and Sassy CSS (SCSS) refer to functions as mixins. Functions will make your CSS concoctions much easier to share across a project. We will cover the two types of mixins in Stylus: mixins and transparent mixins.

Mixins are functions that take a defined set of parameters. Let's take a look at how we can write a mixin:

// STYLUS
animation(duration,delay,timing)
  -webkit-animation-duration:duration
  animation-duration:duration
  -webkit-animation-delay:delay
  animation-delay:delay
  -webkit-animation-timing-function:timing
  animation-timing-function:timing

button
  animation(500ms,0,ease-out)

/* CSS – OUTPUT */
button {
  -webkit-animation-duration:500ms;
  animation-duration:500ms;
  -webkit-animation-delay:0;
  animation-delay:0;
  -webkit-animation-timing-function:ease-out;
  animation-timing-function:ease-out;
}

In this example, we first define the animation mixin, and then we apply the mixin to the button HTML tag. However, there is a much easier and effective way of doing this via a transparent mixin.

A transparent mixin, basically, takes all the parameters and saves them in an arguments variable without you having to define anything. Let's have a look:

// STYLUS
animation()
  -webkit-animation:arguments
  animation:arguments

button
  animation(pulse 3s ease infinite)

/* CSS – OUTPUT */
button {
  -webkit-animation:pulse 3s ease infinite;
  animation:pulse 3s ease infinite;
}

Notice how we did not have to define every single parameter in the mixin, and the arguments variable simply passed all the arguments that it could find. This is especially useful for keeping the code flexible.

Stylus essentially upgrades CSS in such a way that it makes the code much easier to manage and therefore, ends up saving us a lot of development time.

Go to stylus-lang.com and learnboost.github.io/stylus to learn more about Stylus.

Meteor templates are the special blocks of HTML code that generate Meteor template objects (Template.<yourtemplate>). It is through Meteor template objects that we wire the HTML code to logic. People who have worked with an MVC framework will refer to these templates as views. This is a key concept to understand.

Open up your terminal and create a new project:

meteor create basic_meteor

Now let's add our languages:

meteor add coffeescript
meteor add mquandalle:jade
meteor add mquandalle:stylus

Remove the three visible files from /basic_meteor (do not remove any of the files starting with a dot), and create /client/layout.jade. This is something that exists in one way or another in every Meteor project. Let's program:

//- layout.jade
head
  title Meteor Basics
  meta(name="viewport" content="user-scalable=no, initial- scale=1.0, maximum-scale=1.0")
  meta(name="apple-mobile-web-app-capable" content="yes")
body
  +basic_template

I highly recommend adding these metatags to make your site mobile-friendly right from the beginning. With this snippet of code, we are effectively starting up the very first thing that Meteor is going to render before running any code. Once this is rendered, Jade takes care of rendering basic_template. Let's program this in a new file, /client/basic_template.jade:

//- basic_template.jade
template(name="basic_template")
  h1 Hello World!

Behind the scenes, Meteor is compiling our Jade templates and putting them all in one big file. You will never have to worry about loading basic_template.jade before layout.jade when it comes to templating.

Throughout the book, we will use meteorhacks:flow-router and meteorhacks:flow-layout to easily navigate to different templates.

We have already discussed what helpers are in Jade, but how do we create helpers in Meteor? Let's go back to our basic_meteor project and create /client/basic_template.coffee. It is important to understand that Meteor helpers are used to control the variables in our template. People who have worked with an MVC framework can view this file as a controller. Let's write our first helper:

#basic_template.coffee
Template.basic_template.helpers
  "name": ->
    "Mr Someone"

Notice that the helper is defined within the helpers function of the Meteor template object: Template.<your_template>.helpers(<your_helpers>). Helpers are mostly functions that will return anything you want them to including Meteor collection cursors. Let's bring all this together now:

//- basic_template.jade
template(name="basic_template")
  h1 Hello {{name}}

This will output Hello Mr Someone inside the h1 HTML tag. Let's add a slightly more complex helper:

#basic_template.coffee
Template.basic_template.helpers
  "person": ->
    name:"Someone"
    prefix: "Mr"
    children: [
      {
        name:"Billy"
      }
      {
        name:"Nancy"
      }
    ]

//- basic_template.jade
template(name="basic_template")
  with person
    h1 Hello {{prefix}} {{name}}

    ul
      each children
        li {{name}}

In this example, we are using with to set up the data context of the HTML tags that belong to it; this data context is equivalent to person. Data context refers to the value of this inside a helper. So if you set up an object as the data context, this will be equivalent to that object. Also, we iterate through children with an each statement so that we can list out their names.

Meteor taps into common JavaScript HTML events such as click, change, and focus. An event is anything that happens to an HTML element that you are listening to. Suppose we want to be able to change the name of a person to one of the children by clicking on them. We do this through the templates' event map. Let's take a look at an example of how we can do this without using reactivity or collections:

#basic_template.coffee
Template.basic_template.events
  "click li": ->
    $("h1").text "Hello #{@name}"

Easy! So to catch template events, we need to use the Template.<your_template>.events(<your_event_map>) function. In this particular example, we are using jQuery to replace text.

The event map is an object where the properties specify a set of events to be handled. These events may be specified in any of the following ways:

# Runs any time you click anywhere
"click": ->

# Runs any time you click a li element
"click li": ->

#Runs any time you click a li element OR mouseover a li element
"click li, mouseover li": ->

The key string of the event is composed of two parts: the first is always a type of event (click, hover, change, and so on) while the second is always a CSS selector.

The event loop is like a queue; it runs a series of functions one by one. Because functions are processed sequentially, each function effectively blocks others from being processed until the function is done.

In other words, the event loop functions much like a single-line conveyor belt where things are being inspected. For every inspection made, the line is stopped and nothing moves.

Meteor uses Fibers – a NodeJS library – to get around this issue. Many of the functions that you will run will be on a separate fiber. What does this mean? This means that the functions will run on a separate conveyor belt for processing. Still, not all functions are built this way, you need to make sure your server-side functions do not block the server.

So which functions could potentially cause the server to get blocked? Meteor.methods(), Meteor.publish(), and any function that does not run inside a fiber on the server. Let's see how we can unblock each one and when we should do this.

Functions defined under the Meteor.methods() that you know are going to take a long time to process, should always run on a Fiber or defer time consuming code to a Fiber. We can quickly solve this by calling the @unblock() function from within the method. Let's look at an example:

# METEOR METHODS
Meteor.methods
  #BLOCKING
  time_consuming: ->
    Meteor.setTimeout ->
        console.log "done"
      ,60000

  #NON-BLOCKING
  time_consuming_unblock: ->
    @unblock()
    Meteor.setTimeout ->
        console.log "done"
      ,60000

In this example, when you run Meteor.call("time_consuming"), the server will be blocked. When the server is blocked, other visitors won't be able to reach your site! Instead if you run Meteor.call("time_consuming_unblock"), the server will continue to function properly but consume more resources to do so.

Meteor.publish() can be easily unblocked after installing the meteorhacks:unblock package as well. This one will be particularly useful when we start to make very complex publishers that might consume a lot of resources. Let's look at an example:

# METEOR PUBLISH
#BLOCKING
Meteor.publish "external_API_query", ->
  HTTP.get "http://connect.square.com/payments"

#NON-BLOCKING
Meteor.publish "external_API_query_unblocked", ->
  @unblock()
  HTTP.get "http://connect.square.com/payments"

In this example, we are waiting for an HTTP call to respond. This will certainly block the server if we subscribe to external_API_query, so we use external_API_query_unblocked instead.

All other functions that run on the server and you know are going to block the server, should run on a fiber. Meteor has a special function to help us make this easy. It is called Meteor.wrapAsync(). Let's see how this works:

# METEOR UNBLOCKED FUNCTION
unblock_me = Meteor.wrapAsync ->
  Meteor.setTimeout ->
      console.log "done"
    ,60000

The merge box is the algorithm that identifies all the changes that are happening to the database. It basically handles publishers, subscribers, and reactivity. The merge box also handles the initial load of data using DDP messages.

It is important to understand that we can communicate directly with the merge box via all the commands that are available to us under the Meteor.publish() function. The more optimal we can make our Meteor.publish functions, the faster the site will load.

Atmospherejs.com has always been the "go to" website to find packages. Here you will find thousands of packages produced by the community for free. There are a handful of packages that we absolutely need to install to make our website function properly.

First, we install the languages:

meteor add coffeescript
meteor add mquandalle:jade
meteor add mquandalle:stylus
meteor add less

Next, the router and functions that will help us with SEO and routing:

meteor add kadira:flow-router
meteor add kadira:blaze-layout
meteor add meteorhacks:fast-render
meteor add nimble:restivus
meteor add yasinuslu:blaze-meta
meteor add dfischer:prerenderio
meteor add wizonesolutions:canonical

We will need a couple of packages as well to help us manage publishers:

meteor add lepozepo:publish-with-relations
meteor add tmeasday:publish-counts
meteor add meteorhacks:aggregate
meteor add http
meteor add meteorhacks:unblock

These next packages will extend Meteor's functions:

meteor add xorax:multiple-callbacks
meteor add aldeed:collection2
meteor add aldeed:autoform
meteor add fastclick
meteor add reactive-var
meteor add alanning:roles
meteor add accounts-password

meteor add u2622:persistent-session
meteor add ongoworks:security

We will need these packages to properly manage time:

meteor add momentjs:moment
meteor add mrt:moment-timezone

For the last set, we'll be using a couple of additional packages that will make the design process much faster:

meteor add kyleking:customizable-bootstrap-stylus
meteor add raix:handlebar-helpers
meteor add fortawesome:fontawesome
meteor add percolate:momentum

We need to remove some packages for security too:

meteor remove autopublish
meteor remove insecure

All of these packages will be explained in more detail throughout the book, but all of these are must-haves. The first package that we need to explain is the wizonesolutions:canonical package. This package makes sure that all incoming traffic is routed to your ROOT_URL, so it is particularly useful when you want all the traffic to go to your SSL site. The first thing that we need to do before running Meteor is set up canonical to run only in the production environment.

Create /server/canonical.coffee, and add this code:

#/server/canonical.coffee
if process.env.NODE_ENV is "development" or process.env.ROOT_URL.indexOf("meteor.com") > -1
  Meteor.startup ->
    process.env.PACKAGE_CANONICAL_DISABLE = true

This code snippet effectively sets your PACKAGE_CANONICAL_DISABLE environment variable to make sure that canonical is inactive while you are developing.

What are environment variables? These variables are defined within the scope of the deployment, and they make sure that the project knows information before the build finishes on the server. Information such as what database to use, which domains to use, and other setup information can usually be found in these variables. We will cover this information in the final chapter.

A proper file structure is tremendously important in Meteor. We have found that the best way to work is with functional top-level modules. This means that every folder is a micro-service, and therefore can act on its own. This allows for a lot of modularity in the project, and it's very easy for others to understand what it is that you are trying to accomplish. In this section, we will cover this file structure and Meteor's special folders.

Let's look at a sample web application folder structure:

/online_shop
/online_shop/cart
/online_shop/cart/cart_route.coffee  #RUNS ON CLIENT AND SERVER
/online_shop/cart/client
/online_shop/cart/client/cart_view.jade  #RUNS ON CLIENT ONLY
/online_shop/cart/client/cart_controller.coffee
/online_shop/cart/client/cart.styl
/online_shop/cart/server
/online_shop/cart/server/cart_publisher.coffee  #RUNS ON SERVER ONLY
/online_shop/cart/server/cart_methods.coffee

In this folder structure, cart is the micro-service, and it is composed of a route, view, controller, and publisher. The files placed under a /client directory will be published to the client and will only run on the client. The files placed under a /server directory will only run and be accessible on the server. If a file is placed in none of these directories, then the file will run on both the client and server. The expected structure goes like this:

/project_folder
/project_folder/_globals
  ./client/<global support function files>
  ./server/<global support function files>
  ./lib/collections/<collection>/<file>
  ./lib/collections/<collection>/server/<permissions file>

/project_folder/router
  ./client/layouts/<layout file>
  ./lib/<configuration file>
  ./lib/<middleware file>

/project_folder/<module>
  ./<route file>
  ./client/<template file>
  ./client/<logic file>
  ./client/<styles file>
  ./server/<publishers file>
  ./server/<methods file>

It's important to note that the /lib directory will always run before any other code does. Let's place our canonical file under the /_globals/canonical/server directory.

Let's create our first module: the router. Create the /router/client/layout.jade directory, and we will only have one layout throughout the project. Now let's code our layout:

//- LAYOUT.JADE
head
  title Online Shop
  meta(charset="utf-8")

  //- Allow saving to homescreen
  meta(name="apple-mobile-web-app-capable" content="yes")

  //- Do not try to detect phone numbers
  meta(name="format-detection" content="telephone=no")

  //- Make it mobile friendly
  meta(name="viewport" content="user-scalable=no, initial- scale=1.0, maximum-scale=1.0")

body

template(name="layout")
  +Template.dynamic(template=nav)
  +Template.dynamic(template=content)

Here, we have introduced the Template.dynamic component. This component may be used to render other templates dynamically by changing the value of a variable to the name of the template we want to render. We decided to use two variables—nav and content— that are controlled by the router. So, basically, the content variable will be changing to different strings that are equal to the names of our templates.

We will create our landing module in the next chapter to learn not only how to use the router but also how to properly subscribe to data.