DEV Community: Erxk

Angular Mastery: Template Syntax

Erxk — Tue, 01 Oct 2019 10:57:53 +0000

Mastering the Fundamentals of Angular Template Language: Part 1

Getting Started

Complexity: [Beginner , Intermediate , Advanced, Expert]

Article Goal: Streamline information from experience and the Angular Documentation to aid in understanding Angular Template Syntax — Utilizing cheat-sheets, code-examples, and focusing on the essentials.

Article Topics (What We’ll Learn):

Expressions & Statements: Guidelines, Rules, and Usages
Properties & Attributes: How they relate to Data Binding
Data Binding: Dynamically generating views

Angular Template Language (ATL)

Angular Template Language is the language used when working with a component-template/html in Angular. We can consider ATL an extension of HTML that allows us to employ Interpolation, Angular Template Expressions & Statements, Data Binding, etc…

To understand the Angular Template Syntax, first, we will investigate Angular Template Expressions and Statements.

Expressions & Statements

If you’ve worked with Angular then you’ve likely used an Angular Template Expression or Angular Template S_tatement_ before.

Angular Template Expressions/Statements will be called expressions and statements for short.

Expressions and statements are essentially a mini-syntax derived from a subset of JavaScript Expressions. [Table A] below may help illuminate the context of when we use one or the other.

Note, in [Table A], type refers to a data binding type. — We cover data binding in a later section once we have the necessary context of expressions, statements, and properties.

Table A

Expressions

Expressions have their own syntax and general guidelines that should be followed. — Expressions should be simple , quick , and have no side-effects. These qualities are key to performance. In most cases, expressions will be evaluated every change detection cycle 🔁.

The expression syntax is very similar to JavaScript expressions. — However, there are some limitations to operations that promote side effects. For a complete list see here, for syntax examples see [Table B]. See source code for corresponding examples of syntax from [Table B].

Table B

Note, the above examples all use interpolation for consistency. — The results would be the same with two-way [(property)]="expression" and property binding [property]="expression"; as they all use expressions.

Tip: Expressions can utilize a safe-navigation operator to guard against null and undefined [target]="object?.property"

Statements

When working with event-binding () we are utilizing statements. They should be written in a way that is simple and usually has a side-effect. Statements are event-driven, and events usually update state/data from a user action; which is why statements should have side effects.

Statements can execute potentially long-running operations and various tasks because they only run when the bound event fires.

Compared to expressions, similar rules apply to the syntax of statements with some exceptions. The majority of the time we will simply invoke a method inside of a _statement. — _See [Table C] for syntax examples, see source code for corresponding examples.

Table C

Key Points

Unlike s_tatements_, expressions should not execute complex logic, they should always be quick.
Expressions can utilize the pipe operator |to chain to Angular Pipes. Statements utilize ; and , to chain multiple operations/arguments and cannot use Angular Pipes.
Both expressions and statements should be simple, short, and concise.

Properties & Attributes

Before we dive into Angular Data Binding, we should understand the differences between properties and attributes.

Data Binding works with properties , not attributes. Exceptions are attributes such as aria-* and svg. Properties are read from DOM Nodes, whereas attributes are read from HTML Elements. Attributes are used to initialize properties and do not change.

Caveat, using setAttribute() will change an attribute and re-initialize its corresponding property.

Many attributes have 1:1 relationship with properties. For example, on an HTML Input Element, value is the name of an attribute and the name of a property. — The GIF below summarizes the above information in action.

property “value” changes, attribute “value” does not

Key Points

Angular Data Binding generally works with properties
Attributes and properties are different things, even when they have the same name
Attributes generally do *not * change

Data Binding

Data Binding allows us to dynamically set DOM properties and listen for events simply by declaring a target element property/event and writing an expression/statement. — To better understand data binding, we will use native elements such as input and create our own components with custom bindings.

Data Binding has three categories of data flow : source-to-view, view-to-source, and two-way (view-to-source-to-view).

One-Way Binding ( Source-to-View )

When discussing source-to-view binding we will focus on property binding [property]="expression". As discussed in the previous section, data binding works primarily with properties.

Collectively, all five [property]="",[class.css-class]="",[style.css-pro]="",[attr.attribute]="", {{interpolation}} are categorized as source-to-view.

You may be wondering, where does interpolation fit into source-to-view binding? When using interpolation, Angular evaluates the expression and writes the interpolated result to an element property. — In other words, Angular converts interpolation into a property binding.

As shown in the GIF below, all three examples bind to the textContent property and produce the same result.

Property bindings often expect a specific return type based on the target DOM property. Depending on what type our element/component is expecting, we should return that given type.

To summarize, we can visualize source-to-view binding in a username example. Whenever our source properties are updated, the view will reflect those updates on change detection.

One-Way Binding (View-to-Source)

View-to-Source, also known as Event Binding, connects an event to a statement. In other words, when a user fires an action on an element (view-target), it invokes a method inside of our component (data-source)

Event Binding is unique in that it provides the template variable $event. This $event variable contains all information regarding the event including any potential updated values.

Using the same username example from earlier, we can visualize our view listening for events and invoking methods from our source on that event.

$event.target.value abbreviated to $event.value

Two-Way Binding (View-to-Source-to-View)

Two-Way binding [()], also known as View-to-Source-to-View, is essentially a shorthand syntax for property binding and event binding together.

Two-Way Binding follows a semantic pattern in the component where an @Input named x and a corresponding @Output named xChange.

The snippet below shows its usage with the t_wo-way Binding_ syntax, as well as explicit syntax using one-way property binding and one-way event binding.

The GIF below attempts to shed light on why/when we would utilize two-way binding in a component. Notice, with only one-way property binding (second example), the component value is initialized and updates. However, the external value that was passed in does not update when the internal component value updates.

When only one-way event binding is in place (third example), the initial value is never set. Changes are seen in the component, but in this case, we cannot increment or decrement undefined; causing NaN to display.

(countChange)=”externalValue=$event.target.value”

Visualizing the data flow in our username example, our source and view now form a complete circle of invoking the class/source on an event and updating the template/view on change detection:

Key Points

Data Binding has three directions: Source-to-View (Property Binding)[], View-to-Source (Event Binding)(), and View-to-Source-to-View (Two-Way Binding)[()]
Property Binding [] writes to the target element
Event Binding () listens to the target element
Two-Way Binding [()] is just syntactic sugar for Property + Event Binding.

Conclusion

We’ve covered the basics of leveraging Angular Template Syntax to create dynamic views. — In the next section, we will cover the attribute directives NgClass and NgStyle. Thanks for reading!

References

Angular & Headless CMS

Erxk — Mon, 08 Jul 2019 23:10:14 +0000

Build a Blog with Angular and Contentful

I have built a blog application using Angular and a headless CMS, Contentful. Contentful gives developers and non-developers alike the ability to manage content in a web application. I use Contentful to manage content on my website. — I am not sponsored by Contentful and any headless CMS could be substituted. See alternatives [1]

Live Demo 🌌

Download the Source Code 🚀

App Overview

Summary

What is a Headless CMS
Contentful Basics
Angular: Accessing & Displaying Content
Hosting

What is a Headless CMS

As I learned to build web applications, I heard about Content Management Systems (CMS); such as Wordpress or Drupal. I thought to myself, why would a developer use this if they already knew how to build a website? At the time, I did not understand the need or use-case.

Later, when I was ready to create my own side-projects and ship them to non-developers, I paused.

How can someone, who is not a developer, update content on my web application?

I had already spent a significant amount of time developing my skill set building front-end applications. Would I now have to learn something like WordPress to build apps?

Headless CMS has entered the chat.

Headless CMS, like Contentful, are essentially web applications that abstract away the database/backend from developers and non-developers alike.

A headless CMS does not provide a front-end. — They do provide developers with an API to get content from the back-end, and a user interface for non-developers to enter content into the back-end.

We will build an Angular application to display data and use Contentful to create/manage that data.

Contentful Basics

We will cover the basics of Contentful. — For a comprehensive introduction see here [2].

Contentful Overview

As an example, let’s set up a new Space with a Single Content Type in five steps.

Top-Left Menu: Create Space

1. Create a Space

Getting started is as simple as signing up. — Once signed up, we can create our own Space. As an analogy, we can think of a Space like our own individual database.

Create a Content Type

2. Create a Content Type

We will add a Content Type to our Space. We can think of a Content Type like a table definition in a Database. — A Content Type is not the actual content, just the design.

Add Fields to the Content Type

3. Create Fields

Now we will add fields to our Content Type. Think of fields like columns in a database table. — In our example, we are creating a blog post, which will have fields such as title, description, body, etc…

Create new Content

4. Create Content

Each piece of Content we add will be similar to a new row in a database. We will fill out each field we defined earlier in our blogPost Content Type.

Space ID & Content Delivery Acess Token

5. Access the API

In the next section, we will use our Space ID and Content Delivery Access Token to retrieve our Contentful data and display it in our application.

Angular: Accessing & Displaying Content

To get started with the Contentful API, we add the following object to our environment.ts file. We enter the information from step 5 of Contentful Basics.

1. Display All Entries of a Content Type

Using cdaClient.getEntries(content_type), we retrieve a promise containing all Content for a specific Content Type. The resolved data is an array of blog posts. Each entry has two properties, fields and sys.

Sys contains information such as created-date and ID. Fields are the fields we defined in step 3 of Contentful Basics.

Leveraging the Angular Structural Directive, *ngFor, we can dynamically add all blog posts to the DOM. — When we add a new blog post to Contentful, our post will be automatically added by our Contentful Service.

Using Angular Template Syntax, we can build list items displaying info from our Contentful Service such as createdAt, ID, title, description, etc…

2. Display a specific Entry of a Content Type

Using cdaClient.getEntry(id), we can query a specific entry from our Contentful data. The resolved data is a single blog post with the sys and fields properties.

When a user clicks one of the containers from the first section, the router navigates to a dynamic route /posts/:id. In snippet 1.2, we passed the ID as a parameter via routerLink.— We can retrieve the ID from Angular’s ActivatedRoute paramMap.

Contentful provides a Markdown editor for all text fields. We will leverage this by converting the Markdown to HTML and setting the inner HTML on a div. [4]

Use innerHTML judiciously, If we do not have full control over what is being entered into the innerHTML we need to sanitize the input to prevent xss-attacks [5].

Using Angular’s Structural Directive, *ngIf, we can optionally display a field if it exists. In our example, we will display a link to an original publication if present.

3. Add a New Contentful Entry

After publishing a new Contentful Entry, our application is immediately updated on refresh with the latest Content. — No changes are needed to our Angular project.

Final Product

Hosting

The live demo is hosted with Firebase. For directions on hosting a project with Firebase see here [6]. For alternative forms of hosting see here [7].

I am not affiliated with or sponsored by Firebase or any of the alternatives.

Resources & References

[1] Sanity | FlameLink | Headless Wordpress

[2] Contentful-Tutorial

[3] Structural-Directives

[4] Learned the Markdown-to-HTML Technique on fireship

[5] DOM Sanitizer

[6] Host with Firebase

[7] Netlify | AWS | Digital Ocean

Improve Performance with Web Workers

Erxk — Tue, 18 Jun 2019 11:23:52 +0000

Using the Angular 8 CLI

Introduction

This article will illustrate how to improve start-up performance using Web Workers. Our example will be an Angular 8 application. Using the Angular 8 CLI simplifies getting started with Web Workers. However, using Web Workers is not specific to Angular and most of these concepts can be utilized in any Javascript or Typescript application.

Download the Source Code 🚀

We will cover

Measuring Performance in Lighthouse
Getting Started with Web Workers in Angular 8 [1]
Measuring Performance with Web Workers
Web Worker Limitations and Pitfalls

Measuring Performance with Lighthouse

First, we need to get a baseline measurement to gauge how performant our application is on start-up without a Web Worker. Note, we are running our Angular application in production mode — This affects start-up performance.

In the Google Chrome Developer Tools 🛠, using Lighthouse, we can measure the performance of our webpage on startup [2]. I have added a long-running task/computation to the startup of our application (for-loop building a massive string).

Performance without Web Worker

When we execute a long-running task on the Main thread, our application appears to be locked up. This is because the Main thread is blocked by all of the computations in our long-running task. Thus, the user cannot interact with our application until the process has finished.

By clicking “View Trace”, we can see a visualization of CPU time on start-up. In our example, the majority of the time spent was evaluating/running our script/task. We can also verify in the trace that our code is running in the Main thread.

Performance without Web Worker

Getting Started with Web Workers

The Angular 8 CLI has simplified getting started with Web Workers. To create a Web Worker, we will simply run the Angular 8 web-worker schematic.

Generate a Web Worker

The name and location of the worker are mostly arbitrary. A caveat, if your Web Worker has the same name and folder as your component, Angular will automatically add the following code to your component for you. If not, add this code where you want to use the worker.

The only other code generated is the actual worker itself. This is where we will move our long-running computations to.

Main thread → Web Worker → Main thread

When our Web Worker invokes worker.postMessage('hello') the content inside our 'message' event listener will execute inside the Worker. Once our task has completed, postMessage(response) will be called from the Web Worker and worker.onmessage(data)=> {} will execute inside our component back in the Main thread.

Web Worker Performance

Once we move our long-running task to the Web Worker inside of addEventListener('message', (data)=> { // Here }); we will be ready to test our performance again. Note, we will cover various limitations when executing code in a Web Worker later. For now, we simply move our code from the component to the Web Worker.

We can see that the performance of our application on start-up has significantly improved. This is because the Main thread only takes 1.8s before its finished evaluating our Javascript and rendering our components on the screen.

When our long-running task was in the Main thread, we had to wait the additional time to complete the long-running task before the application became interactive.

Performance with Web Worker

The application stays interactive the entire time our script/task is running, as it is not on the Main thread. Performing a “View Trace” we can verify that our script/task is running in an instance of our Worker and the Main thread is sitting idle.

Performance with Web Worker

Web Worker Limitations & Pitfalls

Cannot Pass Functions to Web Workers

Functions and methods cannot be passed to Web Workers. When an object is passed to a Web Worker, all of its methods are removed. If a function is passed to a web worker, the following exception will occur.

worker.postMessage(() => {return 'hello'});

Working with DOM & window

Web Workers run in a different global context than window. DOM manipulation is not allowed, and some methods and properties of the window are not available in web workers. [3]

Running very large processes

In general, there is not a significant difference in time to complete a task when running in Main or in a Web Worker. If you run very large processes inside of a Web Worker, there is a point where the Web Worker becomes significantly slower than the Main thread.

In our example, if we increase the number of iterations significantly, we can see the difference in performance changes dramatically.

Smaller Dataset: 19ms | 37ms

Larger Dataset: 13s | 39s

Summary

Measure the performance of an application on start-up using Lighthouse in Google Chrome Developer Tools.
Long-running tasks/computations in the Main thread will cause the UI to lock and become unresponsive
Delegate long-running tasks to Web Workers to improve performance
Angular 8 CLI simplifies getting started with Web Workers
Be aware of limitations and pitfalls when working with Web Workers

References

[1] https://angular.io/guide/web-worker

[2] https://developers.google.com/web/tools/lighthouse/

[3] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

What Makes a Great Programming/Technical Article?

Erxk — Thu, 13 Jun 2019 13:04:19 +0000

What do you look for when considering if a programming/technical article is great? What style of technical articles do you prefer? Tips and tricks, tutorials, how-tos, etc...

For myself, I value when the article has a repository associated with it so I can download the source code or examples. If the information provided is backed-up by examples and the writing is clear and concise I usually consider that a great article.

I'm also a sucker for good charts and graphs 📊

Angular & RxJS: Detecting Memory Leaks

Erxk — Mon, 27 May 2019 14:02:27 +0000

I’ve built a sample Angular application using RxJS to simulate various memory leaks. The majority of these techniques apply to any component-based framework using RxJS.

You can download the source code here: https://github.com/Everduin94/memory-leaks-rxjs 🚀

We’ll cover:

Strategies for detecting a memory leak
Unsubscribe and Garbage Collection
Solutions to resolve subscription-based memory leaks

Strategies For Detecting A Memory Leak

Using Google Chrome Developer Tools 🛠 (Ctrl+Shift+I) In Google Chrome

Allocation Timeline 📈

Allocation Timelines allow us to see if the minimum size of our heap is growing over time. We’ll start with a baseline before creating or destroying any components.

Now while the timeline is running, we’ll create/destroy the LargeLeak Component multiple times. Note, I’ve typed large into the filter as we are looking for allocations of the LargeLeakComponent

LargeLeakComponent.ts

Now we return to our starting point (destroy LargeLeakComponent) → manually run garbage collection (🗑 garbage-can icon in the top left) → and restart the allocation timeline (⚫ circle icon in the top left). We can see our minimum heap size has increased and the allocations are not being released.

Heap Snapshot 📸

The heap snapshot is useful once we’ve identified a leak. Unlike allocation timelines 🐌, a heap snapshot won’t cause latency while we interact with our app. Ultimately, both snapshot and allocation timeline can be used to detect leaks.

We’ll start with a heap snapshot before doing anything in our application. This will be our baseline or starting point. We can see 0 ServiceObservableLeak Components have been allocated.

ServiceObservableLeak.ts

After toggling creation/destruction multiple times → manually running garbage collection 🗑→ and taking another snapshot ⚫. We can see that the component is not being released via garbage collection.

Note, searching for just the component is not always an effective method for finding a memory leak. If we assume there is a memory leak, we should also inspect the number of subscribers in memory. 🔍 Using the snapshot comparison (Dropdown next to filter), we can compare two separate snapshots. This shows us we’ve allocated 30 subscribers and deleted 0. More on this in “Unsubscribe and Garbage Collection”.

Unsubscribe and Garbage Collection

It’s commonly mentioned that subscriptions hold a reference to the component. Thus, the component cannot be released, creating a memory leak. Not being able to release either object referencing each other is known as a cycle. [1]

Cycles are a limitation of the “Reference-counting garbage collection” algorithm. Modern browsers utilize a “Mark-and-sweep” algorithm 🎯. Mark and Sweep algorithms will collect all non-reachable objects from the root (Global Object). This solves the limitations of cycles.

We can validate this idea of cycles being handled by the garbage collector by testing with a local finite observable. As we toggle the local-finite component → manually run garbage collection 🗑→ take a heap snapshot ⚫.

FiniteObservableComponent.ts

We can see that the component is not leaking, even though we have not used a subscription management strategy (such as unsubscribe).

”So I can just let garbage collection manage my subscriptions?”

No.

If the subscription/component still has some reference back to the root, it will not be garbage collected. We can see this in our ServiceObservableLeak Component from the previous example. Since our observable (observable$) is allocated in a service (SourceService), the component still has a reference back to the root via the observable. We need to unsubscribe for the component (ServiceObservableLeakComponent) to be available for garbage collection.

Not managing subscriptions is a bad practice and should be avoided. Take the FromEvent Component for example. The component initializes a local observable that is watching for click events on a button within FromEventComponent.

FromEventComponent.ts

In this example, the component is being released but the subscriber is not. To make the situation more complicated, the subscriber only leaks when the click event has been fired at least once. This creates a memory leak that is very difficult to track down. — The solution is to always manage your subscriptions.

Solutions

I plan to write in more detail on these methods in a future article. For now, here’s a high-level overview. 🌎

Unsubscribe

Unsubscribing to all subscriptions in the ngOnDestroy method is a valid strategy. This is similar to what the async pipe does under the hood on a component-level.

Async Pipe

Will manage your subscription based on the life of the DOM element it’s associated with. Async pipe will make a new subscription wherever it’s declared. Use “as” to re-use the value provided.

Take

take, takeUntil, and takeWhile will all manage a subscription automatically based on a condition being met. For example, takeUntil will take an observable as an argument and maintain a subscription until that observable emits a value.

Resources / References

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management
Syntax-highlighted images are generated by https://carbon.now.sh