Welcome to this review of the Pluralsight course Angular Best Practices by Joe Eames.

Joe has worked both full and part time as a technical teacher for over ten years.

Also in this series:

Part 2 – Writing Controllers & Services
Part 3 – Writing Directives and Views
Part 4 – Dealing with Scope
Part 5 – Communicating Between Components
Part 6 – Breaking Down A Page into Components
Part 7 – Communicating with The Server
Part 8 – Dealing With Models

Joe introduces each of the modules that comprise this course.
This course assumes you already know Angular so watch Angular Fundamentals first if you are new to it.

The code files associated with this course are found on Joe’s GitHub account at https://github.com/joeeames/AngularBestPracticesFiles

This course is based on Angular 1.2.0-rc2. As this version is more than 3 years old, in the discussion forum I asked Joe how much of the course was still relevant to Angular development using v1.6. He replied:

“Really the only best practice that has emerged since I wrote this course is to use 1.5 components everywhere. Everything is still relevant”

Joe likes using JetBrains WebStorm, and uses it in this course, although nothing is dependent on it so use whichever editor you prefer.

Joe’s favorite browser for Angular development is Chrome, because it has the Batarang plugin for visaulizing and debugging Angular JS code.

Organizing your Code

File Organization

The options discussed are: Angular Seed, By Type, By feature, By feature then type, By feature – huge.

The original Angular Seed project is organized with one JS file for each type of object: controllers, services, filters and directives.
This approach has the advantage that you don’t need to remember to keep adding new script files in your HTML. but Joe says this style of organization is definitely not recommended as each file becomes a haystack.

We learn that there are some serious drawbacks with organizing files by type, and Joe says organizing by feature works well for medium to large sites, although there are drawbacks with this as well.

The quiz questions are:
1. Your file organization has to reflect how code is delivered. True or False?
2. A good organization method works for both the smallest and largest applications. True or False?

Understanding Modules

We see a code demonstration here: starting with a trivial app with one module and one controller. Joe adds 2 sub modules and another controller, and makes the main module depend on the other two.

We see what happens when two modules are bound with the same controller name.
The behavior does not depend on the ordering of the module declarations, but it does depend on the module order (the ordering of the dependent modules on the main module). You’ll most likely need to see this for yourself to appreciate this.

Angular has a very loose relationship between objects and the modules that they belong to. This allows greater flexibility and can reduce the code that we need to use.

This review will cover this quiz questions, but not the answers. Watch the course to find out the answers.

Quiz
1. Modules are a namespacing mechanism for angular objects. True or False?
2. What is the name of the Angular object that has a list of all the objects in your application?
3. How many injectors can exist in each angular application?

Organizing Modules

The options are:
One module for all code
Two modules: a MainModule and CommonModule
Multiple Modules

Joe describes the benefits and drawbacks of each approach.

Quiz
1. Using only one module is clearly the best method. True of False?
2. Sharing code is easiest with more than 1 module. True or False?
3. With multiple modules, your main module cannot contain any objects. True or False?

Naming Overview

When naming we have two goals: Understanding what type of object it is, and avoiding collisions. Angular does not throw an error if we name two objects the same.

Namespacing

Joe describes an example website with Students and Instructors. We want to use the same file names for each even though the logic within them differs. Joe recommends a camel case prefix to avoid collisions.

Naming Objects

Here we see some customary suffixes: Ctrl, Svc, Filter, and Drct. Also discussed in snake casing, and naming Partials.