Chapter 1: Introduction
“When will the follow-up be available?”
Because while the first book introduced readers to the fundamentals of Meteor, it’s gentle pace meant that, by necessity, it explored a fairly small subset of Meteor’s feature. You could build an application by the time you reached the final page, but there were a lot of missing links.
It’s with great pleasure, then, that I write this introduction to Your Second Meteor Application – a book that is long overdue but will surely satisfy the hordes of beginning web developers who are keen to learn more about Meteor.
Within the coming pages, readers will discover how to:
- Build a real-world Meteor project from complete scratch.
- Create multi-page applications with the Iron Router package.
- Design a custom interface for a user accounts system.
- Add a validation system to projects with very little code.
- Write code that is capable of handling errors.
But while the scope of this book is larger than the previous one, the simple language, gentle progressions, and conversational style have stuck around, so there’s nothing lost as we delve deeper into the Meteor framework.
There’s only more to love.
What We’re Building
Within Your First Meteor Application, we learned how to build “Leaderboard” – an application that was previously used as an official example of what the Meteor framework was capable of. Leaderboard, however, is no longer an official example, having been replaced by the much more interesting “Todos” application since the release of Meteor 1.0.
As implied by the name, Todos is a task management application, and having been designed to show off many of Meteor’s features, it’s packed with plenty of interesting ideas and code snippets that we can learn from.
Naturally, then, this book is dedicated to building our own version of the Todos application.
We won’t develop an exact replica of the application – our version won’t be as pretty as t he original – but we will develop many of the same features.
With this in mind, I want to suggest two things:
First, play around with the original Todos application. You should understand every nook and cranny of the application before trying to build it yourself. (Bonus points if you use the application while blind-folded.)
Second, think carefully about the various features that dictate how the application behaves. For instance, these are some details worth noting:
- Lists are used to categorize to-do list items.
- Each list has its own page.
- To-do list items must be attached to a list.
- To-do list items can be created, edited, deleted, and marked as completed.
- Editing to-do list items is done “inline”. There’s no visible form or “Save” button. You just edit the items directly within the interface.
- There’s an accounts system that allows users to register, login, and logout.
I’ll repeat these details along the way, while we’re implementing the various features, but understanding what you’re trying to build is such a fundamental step that it’ll pay dividends if you do some of the legwork yourself.
What You’ll Need
As much as possible, I want to assume as little as possible about your understanding of web development in the coming pages of this book, but so we’re not dawdling for too long on the absolute basics, I do have to assume a few things:
- You have a basic understanding of Mongo databases. You should know how to use the
fetchfunctions, how to use the
sortoperator, and what the
- You have finished reading “Your First Meteor Application”. It doesn’t matter if everything didn’t sink-in, since we will cover some old ground, but we won’t linger on already explained details for too long.
In terms of the stuff you’ll need, nothing has changed in that department. As long as you have a text editor and a web browser, you’re good to go. I’m still quite fond of Sublime Text and Google Chrome, but neither are required.
There’s no precise way that we have to structure our Meteor projects. There are some basic conventions we can follow, but for the most part, we have the freedom to structure the files and folders however we like.
I am fond of this flexibility, but it does result in the paradox of choice, where there’s so many options we can take that we’re left wondering if we’ve chosen the right one.
It also makes writing about structure quite difficult.
In an earlier draft of this book, for instance, I found the pages becoming bloated with sentences like, “Create this file in this folder…” And, “Open this file and find this part of the code…”
After the first couple of chapters, it become painful to read. I was spending more time explaining where code should go rather than what the code was doing.
Because of this, I eventually decided to not talk about structure and just let readers choose whatever structure works for them.
You don’t have to do anything particularly complicated though.
While building this project myself, for instance, I decided to keep all of the code within the project’s default files:
If you decide to take this approach, the files will become bloated, but it’s not so bad that you’ll be pulling your hair out. You just wouldn’t stick with such a minimal structure for a project that you plan to maintain.
Since the earliest release of this book, I’ve renamed a number of elements, and made some other changes that readers of that release will have to account for when continuing through the book.
Here are the changes I’ve made:
- Renamed the “title” field in the “Todos” collection to “name”.
- Renamed the “todosList” template to “todos”.
- Renamed the “todoValue” input field to “todoName”.
- Values of input fields are now being retrieved with jQuery.
- Values of input fields are now being reset with jQuery.
- Changed the “todo-value” class to the “todoItem” name.
- Restructured all of the routes. (You might want to re-read any of the route-related chapters.)
If this is your first time reading through the book though, you won’t need to consider any of these details.