Welcome to Part 3 of 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.

He has produced 18 courses for Pluralsight.

Writing Directives and Views

With regards to Directives this module covers:

– Directive Naming
– Purposes
– Directive Controllers vs Link Function
– Requiring Controllers In Directives
– Directive Interfaces

It also covers the following topics relating to views:

– Avoiding FOUC (Flash of Unstyled Content)
– Writing Valid HTML
– Being Declarative
– Treating HTML as a DSL

Directives – Naming

Naming collisions in JavaScript can be disasterous! And Angular generally won’t give us an error when it happens.

There are two sources of name collisions we can have with our directives: other Angular code, and HTML itself.

It is common to name directives using camelCase in JavaScript and snake-case in HTML.
It’s also common for developers to either forget to use snake-case in their HTML, or sometimes even change the casing back to camelCase to match the JavaScript.

The directive no longer works and Angular does not throw an error because it does not know the directive was incorrectly named.

We also see that Angular can overwrite HTML5 tags, such as section, if we use HTML5 tag names for our directives.

The Angular team recomends using a prefix (other than “ng”) to avoid this coding abomination.

We also learn about Multiple Directive Resource Contention https://docs.angularjs.org/error/$compile/multidir

A good naming strategy is critically important in Angular.

Quiz
1. How many directives with the same name will Angular allow?
2. Angular will always throw an error when two directives conflict. True or False?
3. What should you do to avoid naming conflicts with HTML tags and attributes?

Directives – Purposes

The three main purposes for directives are:

– Widgets
– DOM Events
– Functionality

We see examples of all of these.

Directives – Controllers vs Link

We can either add functionality to our directive by putting it in the directive link function, or create a controller and put the functionality in there.

In this lesson we compare the same functionality implemented in each of these ways. The most effective option entirely depends on the situation.

Directives – Requiring Controllers

We can require in a controller from a different directive, and this could be a sibling directive on the same element or a directive on a parent element.
Joe shows code examples of how to achieve this. He says there are other ways to solve the problem, such as a shared service, which Joe teaches later in the course.

Directive Interfaces

There are three options:

– Shared Scope
– Inherited Scope
– Isolated Scope

When using an inherited scope, all the items on the parent scope are available to the child scope. This is generally a bad thing because it means there may be a lot of collaborators.
This is why Joe recomends using an isolated scope.

Avoiding FOUC in Views

When authoring Views in Angular, we want to avoid FOUC, which either stands for Flash of Unstyled Content, or Flash of Uncomplied Content.

We see the {{curlies}} momentarily before Angular downloads and processes the content. Joe explains and demonstrates three techniques for avoiding this:

– ngClock
– ngBind
– Waiting image

Quiz
1. What files do you have to change to make ng-cloak work?
2. What is the simplest way to avoid FOUC?

Writing valid HTML with Angular

There are two main solutions when wanting to write valid HTML in your Angular views:

Only use Class or Comment Directives (easiest)
Use Attribute Prefixes

Quiz
1. Not all angular views can be made valid. True of False?
2. How do you make most angular attribute directives valid?
3. What ways can you write directives that can be valid?

Thinking Declaratively Part 1

jQuery programming tends to be imperative. Angular thinking is different, and looks to program in a declarative manner. We want to:

Put Declarative View Logic in the View
Avoid putting Imperative Logic in the View

To demonstrate, we start with a simple form that we want to make editable. We have a sample student called Stuart Dent.

In the view we have a duplicate area with editable fields. We can implement it imperatively by:

– using the ng-click=”edit()” attribute
– adding an edit function which sets the visibilities.
– adding ng-style attributes

Although this works, it’s less effective. We can simplify our code by:

– setting editMode to true on edit and false on save.
– replacing ng-style with ng-show and ng-hide

Thinking declaratively, we represent our state in our controller and get the view to manipulate itself based on this.

Thinking Declaratively Part 2

Joe shows another example: follow/unfollow functionality.

Again we start with the imperative solution, and then see how a declarative solution is more effective.

The declarative code is much cleaner.

Rather than thinking about the controller taking direct control of the view, we should have the view listen to the state of the $scope and update the view based on it.

Treating HTML as A DSL

Joe says directives as a DSL is truly paradigm changing: we can turn HTML from a low-level description of the layout of a web page, into a DSL describing the functionality of our apps.

He takes a regular student info page and breaks it down into a DSL:

– replace login form with sc-nav-login directive
– replace top navigation bar with sc-top-nav
– replace student info with sc-student-info
– replace editable student info with sc-editable-student-info
– replace HTML containing both sc-student-info and sc-editable-student-info with a single directive sc-display-edit-student-info

This is a design process that produces components that encapsulate and describe the functional pieces of our application.

By thinking about how our directives and views fit together and can indicate what our apps are doing with needing to read code, we make our applications far more maintainable.