What I wish I learned before starting my first MEAN app

If you are a good student and follow the instructions given by the MEAN.JS project, you will go through these steps before starting your first MEAN flavored full-stack JavaScript app:

1. Read the Mongo docs  
2. Read the Express docs  
3. Read the Angular docs  
4. Read the Node docs  

It’s entirely possible though that you are more like me, and you simply generated the MEAN.JS boilerplate and tried to jump right into it developing your first app, learning what you needed as it came up.

If that sounds like you, I would love to throw at you some tips that would have helped me a lot as a I started out, coming from Java and knowing very little about single-page apps or modern front-end code.

1. Build your learning app (mostly) from scratch

The boilerplate is meant for developers who need to quickly get started a production-ready MEAN app. Not necessarily developers who just want to learn all the parts. Digging into the boilerplate will throw you into a lot of other things (like grunt.js) that will complicate seeing the basics in action.

I ended up building my first MEAN app following The Code Barbarian’s ToDo list MEAN tutorial.

2. There is only one page

Given you are working on a single page app, there will be a single Express route which will serve an html page back out to the client. This page is going to be bare bones: your layout, a global css file if you have one, and script tags for all of your JavaScript files. Every request to the server will hit this route and therefore render the same page. There will be different views that the user interacts with on that page, but these will be added to the page afterwards.

Others routes in the Express backend are used for configuring your REST api. That is, you call these routes from your front-end to interact with your server data. Client-side rouring (probably via angular-ui-router) is what determines the actual views content.

3. require()

There are two basic ways to share code between files in Node, one uses modules.exports and the other uses just exports.func. Both of them are part of the built-in Node module loading system (not Express like I first thought). With both, the full code of your javascript file will get run. The main difference between them is when you call require() on the file that contains them and assign that to a variable, say foo. Whatever you assign to modules.exports will get run when you call foo(), while whatever you assign to exports.func will get run when you call foo.func().

4. #

Sure, I had seen hashsigns in URLs before, but I just ignored them and kept on browsing. When you get into using Angular in your app, you’ll need to know what that’s all about.

Fortunately it’s not terribly complicated. It’s something called a fragment identifier. Without having to know too much, whatever comes before the # gets sent to the backend, and everything after it gets sent to Angular. If you’ve already gotten into routing with Angular, that should help clear up how you define your states for the $stateProvider (or $routeProvider).

retiredcanadianpoet

Juan learned how to program on a TI-83 calculator (thank you, Mrs. Douglass). He is currently a Java Web Developer who spends his free time learning how to program truly well and how to play guitar t