Learn TypeScript 3 by Building Web Applications

Gain a solid understanding of TypeScript, Angular, Vue, React, and NestJS

Sebastien Dubois, Alexis Georges

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781789617863
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming in JavaScript
• Index: Computer Science

Learn TypeScript and many of its features by building state of art web applications from scratch with the help of modern tooling, frameworks, and libraries

Key Features

• Create modern Web applications to help businesses around the world benefit from better quality applications
• Learn the latest features of TypeScript 3 and use them wisely
• Explore TDD practices, OOP techniques, and industry best practices to create high-quality and modular apps

Book Description

TypeScript is a superset of the JavaScript programming language, giving developers a tool to help them write faster, cleaner JavaScript. With the help of its powerful static type system and other powerful tools and techniques it allows developers to write modern JavaScript applications.

This book is a practical guide to learn the TypeScript programming language. It covers from the very basics to the more advanced concepts, while explaining many design patterns, techniques, frameworks, libraries and tools along the way. You will also learn a ton about modern web frameworks like Angular, Vue.js and React, and you will build cool web applications using those. This book also covers modern front-end development tooling such as Node.js, npm, yarn, Webpack, Parcel, Jest, and many others. Throughout the book, you will also discover and make use of the most recent additions of the language introduced by TypeScript 3 such as new types enforcing explicit checks, flexible and scalable ways of project structuring, and many more breaking changes.

By the end of this book, you will be ready to use TypeScript in your own projects and will also have a concrete view of the current frontend software development landscape.

What you will learn

• Understand and take advantage of TypeScript's powerful Type System
• Grasp the key concepts and features of Angular, React, Vue.js, and NestJS
• Handle asynchronous processes using Promises, async/await, Fetch, RxJS, and more
• Delve into REST, GraphQL and create APIs using Apollo
• Discover testing concepts, techniques, and tools like TDD, BDD, E2E, Jest
• Learn Object-Oriented and Functional Programming concepts and leverage those with TypeScript
• Explore design practices and patterns such as SOLID, MVC, DI and IoC, LoD, AOP, and more

Who this book is for

This book is for software developers who are willing to discover what TypeScript is and how to leverage it to write great quality software. Developers that are already familiar with TypeScript will find this book useful by learning the languages featured introduced by most recent releases. Basic knowledge of the JavaScript programming is expected.

Coding WorldExplorer to Explore the Population of the World

In this chapter, we will build WorldExplorer, a web application that will retrieve and display information about the world population. The data will be obtained through a RESTful web service of the World Bank (https://datahelpdesk.worldbank.org). The application will display interactive charts using the Chart.js (https://www.chartjs.org) library.

We will introduce you to additional TypeScript concepts such as modules, module resolution, barrels, and some others. Thanks to modules, we will be able to drastically improve the organization of our code, as well as its readability and testability.

In order to get the data, we will use the Fetch (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) and Promise (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) APIs included in modern web browsers. We will also learn about async and await to make our asynchronous code look synchronous.

In this chapter, we are hence covering the following topics:

• Understanding modules
• Loading and bundling modules
• Exploring TypeScript modules
• Introducing module resolution
• Building the WorldExplorer application
• World Bank Open Data APIs
• Understanding the Fetch API
• Understanding async/await and generators
• Implementing the domain model
• Implementing the population service
• High-level design
• Implementing the view layer
• Implementing the controller layer

Understanding modules

Before we dive into code, we need to take a step back and discuss some theories.

We will first take a short detour through the history of JavaScript to better understand what modules are and where they come from, before looking at how they're defined in TypeScript.

Why do we need modules?

Modules are a design pattern used to improve the structure, readability, and testability of code. Many programming languages have some level of support for modules. Of course, TypeScript is one of them!

Modules are incredibly useful; thanks to them, you can do the following:

• Structure code in self-contained blocks (just like sections in a document or chapters in a book).
• Encapsulate code (since modules are self-contained).
• Define public APIs: Modules expose what they want to define their interface with the outside world.
• Create isolated namespaces: Modules have their own namespaces and they don't pollute other modules.
• Reuse existing code by loading and using third-party libraries, other modules, and much more.
• Define your dependencies: Explicitly define the list of modules that the current one requires to function.

Code is difficult to organize without the possibility to isolate parts of it in modules. By the way, this was one of the main issues with our TodoIt and MediaMan applications.

Note that, without modules, we would have to pollute the global scope a lot more. And, as you should know, global state is considered evil and needs to be avoided whenever possible! This reason alone should be enough to convince you to use modules.

In the next subsections, we will explore different types of modules that have been introduced into the JavaScript ecosystem over time and that are still being used today.

A bit of history about JavaScript modules

When JavaScript came out, it didn't provide any support for modularization. There was no specific feature that you could make use of to organize your code in logical groups, expose/hide parts of your code base and define your dependencies.

Given that JavaScript was initially intended to be a glue language rather than a language used to build fully-fledged applications, it wasn't too much of an issue. And of course, when the web was younger, web developers usually didn't do much using JavaScript apart from changing status bar messages, creating small animations, or displaying alert boxes (there were, indeed, exceptions).

Over time, more and more code got written in JavaScript and, of course, the lack of modularity became problematic. At the time, people would isolate their code in different JavaScript files and import them one by one along with their dependencies, hoping to do it in the correct order and with compatible versions.

Code also often defined global variables and it wasn't rare to get into deadlock situations where two different libraries wanted to use the same global variable names (for example, the $ global variable name used by jQuery).

The situation was actually worse since dependencies also had to be downloaded manually and loaded separately. Integrating code from different library authors was no fun.

JavaScript developers suffered a lot back then, which of course led to the introduction of clever workarounds (or hacks, as you might prefer to call them).

The Revealing Module pattern

To ease the pain, many developers started using object literals and naming conventions to try and avoid name clashes, but this wasn't so great. Others were more clever and leveraged JavaScript closures with IIFEs (we discussed those in Chapter 3, Improving TodoIt with Classes and Interfaces; IIFEs are anonymous, immediately invoked, function expressions) to encapsulate/isolate parts of their code and expose only the properties and functions that they wanted to.

This approach became known as the Revealing Module pattern (http://jargon.js.org/_glossary/REVEALING_MODULE_PATTERN.md). A popular example of this was jQuery, whose plugin system used this approach.

Here's a concrete example of a module using this pattern:

var myBooks = (function() { var collection = [ { name: "Lord of the rings", author: "JRR Tolkien", rating: 10 }, { name: "1984", author: "George Orwell", rating: 9 } ]; function getCollection() { return collection; } function favoriteBook() { return collection[0]; } function sortBooks() { // no-op } function addBook(book) { collection.push(book); sortBooks(); } return { books: getCollection(), addBook: addBook, favoriteBook: favoriteBook() } })(); // immediately invoked
myBooks.addBook({name: "foo", author: "bar"}); console.log(myBooks.books); console.log("Favorite: ", myBooks.favoriteBook); 

In this example, the only global variable is myBooks. In the return statement of its associated function, we define the public API of our module. This allows us to keep some parts private, such as the sortBooks function.

These IIFE-based solutions can be considered basic modules even though they don't rely on a dedicated language keyword.

IIFEs and the Revealing Module pattern were only the first steps toward better code organization and other variations of module definitions were devised over time. Unfortunately, they only solved part of the modularization puzzle. They only helped with the isolation/encapsulation of code, not dealing with dependencies.

The AMD and CommonJS modules

As time went on, library authors joined forces and two de facto standards emerged in the JavaScript community: Asynchronous Module Definition (AMD) and CommonJS (CJS). Both of these are specifications for module types that also describe a way to load those modules and their dependencies.

AMD modules were mainly used by RequireJS (https://requirejs.org) and Dojo Toolkit (https://dojotool...