Book Image

The TypeScript Workshop

By : Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matt Morgan, Vekoslav Stefanovski
5 (1)
Book Image

The TypeScript Workshop

5 (1)
By: Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matt Morgan, Vekoslav Stefanovski

Overview of this book

By learning TypeScript, you can start writing cleaner, more readable code that’s easier to understand and less likely to contain bugs. What’s not to like? It’s certainly an appealing prospect, but learning a new language can be challenging, and it’s not always easy to know where to begin. This book is the perfect place to start. It provides the ideal platform for JavaScript programmers to practice writing eloquent, productive TypeScript code. Unlike many theory-heavy books, The TypeScript Workshop balances clear explanations with opportunities for hands-on practice. You’ll quickly be up and running building functional websites, without having to wade through pages and pages of history and dull, dry fluff. Guided exercises clearly demonstrate how key concepts are used in the real world, and each chapter is rounded off with an activity that challenges you to apply your new knowledge in the context of a realistic scenario. Whether you’re a hobbyist eager to get cracking on your next project, or a professional developer looking to unlock your next promotion, pick up a copy and make a start! Whatever your motivation, by the end of this book, you’ll have the confidence and understanding to make it happen with TypeScript.
Table of Contents (16 chapters)
Preface

InversifyJS

InversifyJS is an implementation of an IoC container (inversion of control, which DI is part of) for TypeScript (and JavaScript) applications. It is one of many implementations and, as we've seen above, some frameworks come with their own DI solution, such as Angular or Nest.js.

Note

Other alternatives to InversifyJS for general-purpose projects include TypeDI and TSyringe, as well as typescript-ioc.

The basic idea in InversifyJS, as in most other implementations for an IoC container, is to have one place that defines all the concrete implementations of functionality, and the rest of the app only depends on abstractions (for example, interfaces). This greatly reduces coupling, and changing one implementation to another doesn't affect the entire app or require lots of code changes.

Note

Coupling is about how tightly integrated/dependent two components (usually classes) are, in the sense that if we change one of them, how likely is the other to break...