Guide to TypeScript: A Leading Web Development Tool
About Typescript:
Trying to access an object property by iterating over its keys is one of the most common Type Script puzzles. Although JavaScript uses this approach frequently, Typescript tends to throw up all sorts of roadblocks in your way. This short sentence has developers turning the tables and Typescript throwing red squigglies at you. Just not enjoyable. There are several remedies for it. I previously attempted to "enhance" Object keys. Although it's a great exercise in declaration merging, I wouldn't recommend doing it frequently. Dan also writes deeply on this. Undoubtedly, annotating is a solution. So hey, let's first have a look at the issue.
All we need to do is access a Person's fields through their keys to print them. This is not allowed by TypeScript. The string [that is returned by Object. keys (p) is too broad to enable access to the tightly specified object structure of Person. How come, though? Isn't it clear that we can only use keys that are already in circulation? Using Object. keys for this purpose is the whole idea! Yes, but we may also send objects that are Person subtypes and have additional features not found in Person. As a result, you may argue that printers should continue to function properly. The code is unaffected, however, it does output additional properties. Each property should be accessible because it is still the set of keys for P. Thus, let's presume that Object. Keys returns (key of Person) [. precisely what my 2-year-old "repair" seeks to accomplish. Something like this may be written simply.
Typescript tool:
You may also access other objects of Person if Object. Keys (p) returns an array of type keys of Person [. This may not be correct. In our illustration, we only print undefined. But what if you tried to implement those values in some way? At runtime, this will malfunction. You are protected against situations like these by TypeScript. It's straightforward and states: You could assume it to be a key of Person, but there's a lot more that it might be. You can only be helped by type guards. The same problem is displayed by TypeScript. As a string expression cannot be used to index a person type, the element inherently has a type of "any". The same justification. We introduce a new generic type parameter T that extends from Person rather than requiring that p be a Person (and hence be compatible with all sub-types of Person). All types that have previously been compatible with this function signature are still compatible, but when we call p, we are interacting with a specific sub-type rather than the more general super-type Person. Since TypeScript recognizes that T is sufficiently distinct from Person to shield you from mistakes, we replace T with anything consistent with Person.
Bottom line:
The fact that TypeScript is quite cautious with its types may seem strange at first, but it benefits you in unexpected ways. I suppose this is the point at which JavaScript devs typically yell at the compiler and feel like they are "fighting" it, but hey, TypeScript could have saved you behind. When this becomes a nuisance, TypeScript at least provides you with workarounds. I was called by Amanda Quinn from O'Reilly a few months back. She's seen my book TypeScript in 50 Lessons, which was released by Smashing Magazine around two years ago, and she's read my articles. She asked whether I would be interested in contributing to the TypeScript Cookbook, a book they have been considering, and that would strongly complement my writing style and subject. Initially, I was a little concerned because I believed I had covered everything of TypeScript that could be covered in a book, and because TypeScript in 50 Lessons took a year to design, I worried that a new book on the same subject would either be too similar or lack substantial substance.
Comments