It wasn’t a long time ago that many JavaScript engineers or, most of the time, web frontend engineers, were still focusing on solving detailed technical issues, such as how to lay out specific content cross-browsers and how to send requests cross-domains.
At that time, a good web frontend engineer was usually expected to have notable experience on how detailed features can be implemented with existing APIs. Only a few people cared about how to write application-scale JavaScript because the interaction on a web page was really simple and no one wrote ASP in JavaScript.
However, the situation has changed tremendously. JavaScript has become the only language that runs everywhere, cross-platform and cross-device. In the main battlefield, interactions on the Web become more and more complex, and people are moving business logic from the backend to the frontend. With the growth of the Node.js community, JavaScript is playing a more and more important roles in our life.
I am currently working for an IoT company called Ruff that builds a platform for JavaScript to write applications run on embedded devices. You might have seen a fake book cover in the title of Writing Device Drivers in JavaScript, but that is actually a part of what we do.
The boom of JavaScript, however, makes people realize that the language itself might not be powerful enough for applications on a larger scale. While we enjoy the flexibility of the language, we suffer from its lack of static-type information; for instance, consider the following:
No static type checking: We have to rely on debugging or tests to get rid of simple errors that could be eliminated when the code is written.
Refactoring is a pain: Basically, what the IDEs or editors can do about JavaScript code is renaming local variables or exported module functions at best.
Understanding code is difficult: When you grasp a piece of code, you might have to look around and manually search for references just to figure out which properties an object has and what types of property they are. This happens to our own code as well.
Compared to tools such as ESLint and even Flow, which only partially solve the problems, TypeScript does a really good job while it is still sticking to the ECMAScript standard.
TypeScript is indeed an awesome tool for JavaScript. Unfortunately, intelligence is still required to write actually robust, maintainable, and reusable code. But wait, doesn’t the intelligence part involve the true value of our work?
We might all have had trouble finding clues to mysterious bugs, or squeezed our head thinking about how we can add new features to the existing code base. Some of us, with experience and intuition built over the years, may directly come up with a design that’s not bad. For these people, getting through the common design patterns can help gain knowledge of what people have already catalogued over years in the industry or be better understood when discussing software designs with others. For people who have less experience, learning common design patterns may be a more straightforward approach to creating code that’s beautifully designed.
Chapter 1, Tools and Frameworks, provides a brief introduction to tools and frameworks that will be used through this book, including installing a TypeScript compiler, preparing an editor, and a basic workflow.
Chapter 2, The Challenge of Increasing Complexity, starts with a simple server-client synchronizing implementation; we then expand its features and see how things can gain undesired complexity and how that complexity can be reduced.
Chapter 3, Creational Design Patterns, catalogs five common creational design patterns, the Factory Method, Abstract Factory, Builder, Prototype, and Singleton patterns.
Chapter 4, Structural Design Patterns, catalogs seven common structural design patterns, the Composite, Decorator, Adapter, Bridge, Façade, Flyweight, and Proxy patterns.
Chapter 5, Behavioral Design Patterns, catalogs five common behavioral design patterns, the Chain of Responsibility, Command, Memento, Iterator, and Mediator patterns.
Chapter 6, Behavioral Design Patterns: Continuous, catalogs another four common behavioral design patterns, the Strategy, State, Template Method, Observer, and Visitor patterns.
Chapter 7, Patterns and Architectures in JavaScript and TypeScript, takes a look at the patterns and architectures that closely relate to the language (JavaScript or TypeScript) and its application, including asynchronous programming, module organization, error handling, permission abstraction, and so on.
Chapter 8, SOLID Principles, explains the well-known SOLID principles and how they can benefit a project and keep it healthy over time.
Chapter 9, The Road to Enterprise Application, guides readers to build the complete workflow of an application that is ready to scale, including testing and continuous integration.
It is possible to read through this entire book without installing anything. But it is recommended that you have a handy editor and TypeScript compiler installed to get your hands dirty. Please refer to Chapter 1, Tools and Frameworks, for the detailed preparation of tools, including Node.js, a TypeScript compiler, declaration manager, and a nice editor or IDE.
Though this book does not require the reader to have a knowledge of design patterns, it's not a book that teaches basic TypeScript syntax. If you are not yet familiar with TypeScript, please walk through the TypeScript Handbook before reading Chapter 2, The Challenge of Increasing Complexity.
If you are a TypeScript developer, this book is for you. No knowledge of design patterns is required to read this book.
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "Save the following code to file test.ts."
A block of code is set as follows:
require('chai').should();
Any command-line input or output is written as follows:
$ tsc test.ts
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Without the necessary declaration files, the compiler would complain Cannot find module express."
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
Log in or register to our website using your e-mail address and password.
Hover the mouse pointer on the SUPPORT tab at the top.
Click on Code Downloads & Errata.
Enter the name of the book in the Search box.
Select the book for which you're looking to download the code files.
Choose from the drop-down menu where you purchased this book from.
Click on Code Download.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR / 7-Zip for Windows
Zipeg / iZip / UnRarX for Mac
7-Zip / PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/TypeScript-Design-Patterns/. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.