Setting up your project file structure
When you spin up a new project in Meteor, the default file configuration is built to get you up and running immediately. That's great, but if you're looking to keep your code optimized and easily understood, you'll need to tweak the file structure a bit. The following recipe maps out the file structure that you can use for the majority of your projects.
Getting ready
You'll want to create a new base Meteor project, which we will then modify to suit our needs. In a terminal window, navigate to the folder where you would like to create the project and enter the following command to create a project called FileTemplate:
$ meteor create FileTemplate
Tip
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you. Optionally, the code samples can also be downloaded from https://github.com/strack/PacktMeteorRecipes.
This will create the base file structure. Now, navigate to the folder in the File Explorer window of your choice. For this exercise, we'll use a Mac OS X Finder window so that we can visualize the folder structure:
Tip
Always start with a fresh Meteor project (don't try to create your folder structure manually). Even though the file structure looks simple, there are hidden files and folders created by the meteor create command that you can't live without!
How to do it…
To set up your project file structure, proceed with the following steps:
- In your root folder, delete the default
.css,.js, and.htmlfiles. FileTemplate should now appear empty, similar to the following screenshot:
Tip
Instead of deleting the base
.html,.css, and.jsfiles, you could break them apart using the code/file entries discussed in the following steps. - Create the following subfolders in your root folder:
clientserverbothprivatepublic
- Navigate to the
clientsubfolder. Create a new file namedmain.html. Edit this file and add the following code (taken fromFileTemplate.html):<head> <title>FileTemplate</title> </head> <body> <h1>Welcome to Meteor!</h1> {{> hello}} </body> <template name="hello"> <button>Click Me</button> <p>You've pressed the button {{counter}} times.</p> </template> - Create a new subfolder in the
clientfolder namedscripts. - Inside
scripts, create a new file calledmain.js. Edit this file, adding the following code (taken from theMeteor.isClientsection ofFileTemplate.js):// counter starts at 0 Session.setDefault('counter', 0); Template.hello.helpers({ counter: function () { return Session.get('counter'); } }); Template.hello.events({ 'click button': function () { // increment the counter when button is clicked Session.set('counter', Session.get('counter') + 1); } }); - Create a new subfolder in the
clientfolder namedlib. Create two subfolders namedscriptsandstyles. - Inside
styles, create a new file calledstyle.css. - Navigate to the
serversubfolder. Create a new file namedserver.js. Add the following code to theserver.jsfile and save the changes:Meteor.startup(function () { // code to run on server at startup });Your completed file structure should now look like the following screenshot:
How it works…
We'll break down this file structure in pairs for the most part. This is because for almost every folder, there is another folder that serves the opposite purpose.
client/server
The client folder is interpreted by Meteor as code that belongs exclusively to the client. The server folder is the exact opposite and tells Meteor that any files contained inside should only apply to server-side processing.
Having separate client and server folders logically separates your code (making it easier to visualize), saves unnecessary processing, and prevents errors (client templates and rendering code will throw errors if processed by the server).
Inside of the client folder, we've placed a scripts subfolder and two files, both with the main prefix (main.html and main.js). The scripts subfolder is for our benefit, separating out HTML and JavaScript so that when we go back and review our code, it will be easy to read and segment.
main/lib
The main prefix is used to tell Meteor: run this code last. When Meteor goes about processing and compiling files, it waits to process anything named main until the very end. This helps in situations where libraries or scripts need to be initialized before you can take advantage of them.
Conversely, the lib folder tells Meteor: run this code first. Anything placed inside, or as a child of, the lib folder will be run first by Meteor at runtime. This is a great place to put global variables, common libraries not already included as packages (see Chapter 2, Customizing with Packages), and of course any style sheets. This is why we've included a scripts and styles subfolder and have created an initial generic style.css file.
Using the main prefix and the lib folder together helps us maintain proper sequences and ensures that our styles load as quickly as possible.
public/private
The public folder is a repository for assets that need to be accessed globally. It's a very good place to store non-sensitive information, such as images and text files. It's also easy to remember. If you need something to be shown publicly, put it in the public folder.
The private folder is the opposite. It's a place to store assets that can only be seen by the server. This is a good place to put moderately sensitive information (you'll want additional security, such as a database, for the information you want to keep more secure). Any files placed in the private folder can be referenced by the server with no special path or navigation arguments.
both
The both folder stands all by itself as the folder accessible by both the client and the server. When you are creating models and collections (see Chapter 4, Creating Models) you'll want to put the declarations in a file inside of the both folder. The main reason for doing this is so that you don't duplicate code, and you can ensure that both the client and the server are working from the same model declarations.
There's more…
Obviously, you don't need to create this file structure from scratch every time. You can use your favorite script engine (Grunt, Gulp, Shell Script, and so on) and create a script that can make the necessary changes with a single command. Alternatively, you can create the template once, copy the entire folder to a new location, and then use it as if it were a new project.
If you do decide to use this recipe rather than an automated script, make sure you update your base template to the latest Meteor build periodically and each time you make a copy. This can be done very easily in a terminal window. Navigate to the root folder (for example ~/Documents/Meteor/FileTemplate) and run the following command:
$ meteor update
You will either receive a message letting you know that the folder is already up to date, or Meteor will update the project to the latest version.
See also
- Chapter 2, Customizing with Packages
