Book Image

Hands-On TypeScript for C# and .NET Core Developers

By : Francesco Abbruzzese
5 (1)
Book Image

Hands-On TypeScript for C# and .NET Core Developers

5 (1)
By: Francesco Abbruzzese

Overview of this book

Writing clean, object-oriented code in JavaScript gets trickier and complex as the size of the project grows. This is where Typescript comes into the picture; it lets you write pure object-oriented code with ease, giving it the upper hand over JavaScript. This book introduces you to basic TypeScript concepts by gradually modifying standard JavaScript code, which makes learning TypeScript easy for C# ASP.NET developers. As you progress through the chapters, you'll cover object programming concepts, such as classes, interfaces, and generics, and understand how they are related to, and similar in, both ES6 and C#. You will also learn how to use bundlers like WebPack to package your code and other resources. The book explains all concepts using practical examples of ASP.NET Core projects, and reusable TypeScript libraries. Finally, you'll explore the features that TypeScript inherits from either ES6 or C#, or both of them, such as Symbols, Iterables, Promises, and Decorators. By the end of the book, you'll be able to apply all TypeScript concepts to understand the Angular framework better, and you'll have become comfortable with the way in which modules, components, and services are defined and used in Angular. You'll also have gained a good understanding of all the features included in the Angular/ASP.NET Core Visual Studio project template.
Table of Contents (16 chapters)

Loading modules

So far, just two options were considered to specify the location of a module to load in an import statement, relative to the importing module and absolute path:

//relative to current module
import DOMList from "./lib/jQueryList"

//absolute path
import DOMList from "c:/wwwroot/myWbSite/lib/jQueryList"

Absolute paths should be avoided since copying or moving the whole file tree into a different location would break the code, so the only viable option analyzed was a path relative to the importing module. Organizing the whole code with relative paths is straightforward if one has full control of how to place each file.

Unluckily, this is not the the case when one uses third-party libraries with their own import statements and their own dependencies, since library authors don't know where their files will be placed, and where the files of other...