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:
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.
3.142.156.202