Typescript to JavaScript post compile
Tags: javascript, typescript, angular
Published: 2019-10-25 14:39:23

Imagine something like the Angular class/component shown here. It's a component that draws a circle with text in it. 

![](https://thepracticaldev.s3.amazonaws.com/i/8qvezg8b79j9eeeez1bf.PNG)


When compiled the Javascript looks like this:


 ![compiled to javascript](https://thepracticaldev.s3.amazonaws.com/i/ei7rqwrosfd8nm7ey87s.PNG)



We can see that the @Input() properties of Angular wind up in the function CircleTextComponent using the keyword this. *e.g. this.radius, this.backGround etc.* Notice that the javascript equivalent does not need the type of *string*.   This is because the loosely typed javascript employs ["implicit cohersion"](https://dev.to/promhize/what-you-need-to-know-about-javascripts-implicit-coercion-e23).  Nice...  

The keyword 'this' means *this-object*. Therefore; *this.radius* means this CircleTextComponent's radius property. 

[The input keywords in Angular](https://angular.io/api/core/Input) allow other users of this component to inject the values they want. Like this:

![CircleWithText](https://thepracticaldev.s3.amazonaws.com/i/569naja51sjpdoooztb9.PNG)

We know that app-circle-text HTML custom tag works, because our component defined it in the selector section below. 


![componentDecorator](https://thepracticaldev.s3.amazonaws.com/i/5wnt77becu5ujf3u2hdf.PNG)

An Angular concept for sure...

**Models**

Many of today's JavaScript experts don't use models at all! What? Yes, instead they use the power of Javascript objects instead. They may prefer the [object.assign method](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) Or even dynamically create objects where needed; each time using *key:value* pairs that are not known by the IDE. 
*e.g. let person = {lastname:"somename"}* 
The IDE has no concept if the key spelling or value type is correct. Only subsequent uses of this object allows the IDE auto-complete setting the values.  But it will never catch value type errors. 
 
The problem of not using models in JavaScript is summed up asking these questions: "How many person objects were created, where are they, and were any keys misspelled and do they all exactly have all the same key names?  And what about the values, were they all of the same type? In other words are you only going to find those types of errors at run-time! Ouch...

There's a better way. If we are using Typescript for your models. Our circle model would look like this:
![circlemodel](https://thepracticaldev.s3.amazonaws.com/i/4yvnlp0pzddacihx3zs2.PNG)
And now our IDE (Visual Studio Code) can do pre-compile time type checking as shown here.
![typechecking](https://thepracticaldev.s3.amazonaws.com/i/1oiua2zc2u6qqi7kkqjd.PNG)

Notice that backGround is in red! This is because we put in a number and not a string. But the best part is that we don't have to discover this at run time as the Typescript compiler will flag this as an error.  

Typescript models are great to keep key names all the same, all the values to only what they should be [type wise] (https://javascript.info/types). 

This is why I prefer Typescript, compile time error checking, over linting.

In our next tip, we'll discuss the ViewModel concept.