Automation makes our lives easier and keep us out of common problems.

I’m lazy AF and I take everything that makes my life easy and smooth, Software development is not different to me. I avoid doing the following tasks manually:

• Building the app
• Create the artifact when the build is done
• Publish to the target environment
• Wait for deployment

I love automation, so once I push my changes I want to see them deployed automatically.

We are going to talk about it in this post, so we are going to start simple, let’s create a new Angular project with the Angular CLI (I’m using Angular v6).

Create a new repository on GitHub and push it to GitHub.
Now we are ready to set up our pipeline to automate the deploying process of our app, let’s start adding our awesome project to Travis-CI.

1. In the root of the project create a new file named .travis.yml
2. Populate this file with the gist below

but, what does it mean? what is happening there?

Don’t worry, this is just the configuration of:

• The language and runtime we want to use (Node/JavaScript)
• The branch(es) we want to build
• Some folders we want in the cache to make the process faster and
• The way to install-test-build our project.

I’m going to focus in two steps scripts and deploy.

Scripts:

• yarn lint will check the syntax of the code, if fails the build and deploy will be skipped.
• yarn build --base-href will build our application, same as lint, if fails deploy will be skipped.
• mv dist/my-awesome-project/index.html dist/my-awesome-project/404.html will create a 404.html file needed in Github pages when your app use the Angular Router.

Spoiler Alert: if any of the scripts above fail, the whole process will fail.

Deploy:

Deploying to GitHub Pages uses git push --force to overwrite the history on the target branch, so make sure you only deploy to a branch used for that specific purpose, such as gh-pages. It is possible to disable this “force push” behavior by setting keep-history option to true.

from Travis-CI Docs

1. provider: Tells Travis-CI where you want to deploy your project.
2. skip_cleanup: true: Prevents the reset of the current working directory and the deletion of all changes made during the build.
3. github_token: This token in generated in your GitHub repo to perform Git operation via API. Click here to create your own token. (we are going to talk about this later but please copy the token in a safety place where you can grab it later).
4. local_dir: The physical path where the output artifact was built. (Is important to note that path may change to dist/ if you are using Angular version < 6).
5. on: branch:Specify what branch(es) you want to deploy. Any branch outside this config will build but not will be deployed.

We’ve set everything in the code to automate our building/deploying process, now is time to tell Travis-CI how things will work. Sign up in Travis-CI with your GitHub account and select my-awesome-project in the list of repos, then click in the settings button.

Turn on Build only if .travis.yml is preset (if you want to build any new push for any branch set up your General config like the one below).

Travis-CI by default build only the last commit and cancel the older ones, unless there is a build running, it will be queued in the waiting list. I like to have an history of builds so I disable these options, doing this each new commit will be queued and will run its own build. You can configure this in the section ‘Auto Cancellation’.

We’ve reached the most important step in all of this automated process configuration, the way Travis-CI is allowed to push to our repo, and the answer is with the github token that we talked about earlier, in the “Environment Variables” section paste your token in the field ‘Value’ and name it ‘GITHUB_TOKEN’.

With all this set our pipeline is completed, now it’s time to see how magic happens, so let’s do it!!

• In command line create a new branch git checkout -b my-awesome-branch master
• In app.component.ts change title = 'app' by title = 'my awesome project'
• Commit this change git add . git commit -m "change app title”
• Push it git push -u origin my-awesome-branch
• Create a new Pull Request to Master and you will see how everything starts to work

Our branch start building, yay!

But we are halfway to our goal, deploy it to GitHub Pages.

You might notice the deploy was skipped, that’s because we told Travis-CI only deploy master branch, but all build process was successful.

Now is time to merge my-awesome-branch to master . The pipeline start over

Master branch starts building and when is finish the application is deployed, a new branch named gh-pages is automatically created, Travis-CI takes care to obtain the built artifact and push it to this branch.

The only thing remain is use GitHub Pages to serve our site, go to your repo Settings > GitHub Pages section and select gh-pages branch.

Our site is alive!!!!! From now on we’ll only take care of making our app more and more awesome!!

**Update Dharmen Shah suggest to add a 404.html file to avoid the 404 error page not found when the Angular app has routing.

Deploying your Angular app to Github Pages using Travis-CI was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. The issue? 😲

Its documentation isn’t very verbose, so you’re left with doubts about what to do. For example, in the previous version you could set yarn as the default package manager like this:

ng set packageManager=yarn
// Or if you want to set it globally
ng set --global packageManager=yarn

However the new way to go with CLI V6 is this one:

ng config cli.packageManager yarn
// Or if you want to set it globally
ng config -g cli.packageManager yarn

The difference is clear, but there’s no documentation about the paths for the variables you can configure, or even the accepted values. Essentially we’re in the dark here 😥.

Now let me show you the ways of the config command, and how to know what can be configured in Angular V6 CLI 😉.

2. How to use it

The config command usage can be found in the documentation, though it doesn’t shows you which properties you can configure.

In basic terms you need a path and a value for the property you want to configure. Without the value it would only print the current value. If the path is something like cli.packageManager and you want to configure it with Yarn, then this is how the command would look like:

ng config cli.packageManager yarn

You can make this the default configuration for all your new projects by adding -g or --global flag:

ng config -g cli.packageManager yarn

Now, let’s explore how we get to know which properties are configurable.

3. Reading the Schema

To find out what parameters are configurable in the config command we need to know where to get the schema from(basically what paths & values can be used). This file is available at:

 node_modules/@angular/cli/lib/config/schema.json

It looks like this:

The important part here are the properties. Do you remember the path previously used to set yarn as package manager? We used cli.packageManager, right? Well, the schema for the cli properties are shown in line :13. You’ll notice it’s a reference for an object called cliOptions under definitions property. That’s our target in this case:

The cli property can have multiple properties like defaultCollection, packageManager and a few others…

Do you see where we’re going with this? To set the desired package manager we have to use the cli.packageManager path because that’s what the schema accepts.

The good thing about knowing how to read the schema is that you can find the description and the type of data accepted as a value. Additionally, some of them specify the options you can choose.

The packageManager for instance can receive a string, but not any string, it has an enum property, which tells you which strings you can pass to this property. In this case the Angular CLI accepts “npm”, “yarn” & “cnpm” (I didn’t even know cnpm existed).

4. What Now?

Now you know how to use the command, how to check the schema & build the paths for the properties to configure.

The schema is huge (1605 lines at Angular V6 release), but if you know what config you’re searching for, just search by a keyword, with a bit of luck it will available in the property key or in the description.

Now feel 😎(awesome) for knowing how to configure your Angular project.

Angular V6 CLI Config was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thanks to @angular/router package, implementing this in our applications is easier than you might think. So let’s get started.

1. Creating our million dollar fancy application

We’re going to use Angular CLI to create our application, let’s create a new app.

For those who are getting started, this command will create an angular application and its basic structure, followed by the dependency installation. For more please refer to @angular/cli.

Notice I passed the routing flag to our ng new command, this will generate the routing for our application.

2. Creating our main components

Let’s suppose we’re going to have two main components in our app, the former is going to be the HomeComponent where our users will visit our application when they hit let’s say fancy-app.fancydomain.

The latter, our BigFeatureComponent that’s gonna be the one we will Lazy Load as the user navigates through our application. So let’s create them using angular CLI.

For the purpose of this tutorial, we are skipping the creation of test files passing the spec=false flag. Do not forget to add tests to your production ready applications.

This way angular CLI will automagically create our two new components and updates our AppModule for us with its respective declarations. More info about @angular/cli commands can be found here

For now our project structure should look like this.

3. Adding features to our Application

For now, we have all our application structure generated. Now is time to start adding those game-changing features.

First we’re going to create the routing for our application, which will be in charge of mocking up the navigation of our application as the users perform application tasks. Open up our app-routing.module.ts and complete it up with the following routes.

For a more detailed information about how the @angular/router package works, here’s the official documentation.

By adding this, our angular app will register the path routes /home and /bigComponent and make them available to the user, as they use our app show them the appropriate content, HomeComponent and BigFeatureComponent respectively.

Each of the components will have its own game changer feature, but for the purpose of this blog post I’ll keep things simple and will focus in what really matters, how to Lazy load an angular Module. More on that later.

I added each of the respectively anchor tags to our HomeComponent and BigFeatureComponent HTML’s, to be able to navigate through our application components.

Our home-component.component.html should look like this.

And our big-feature.component.html like this.

And to make sure we’ve been following around our app.module.ts should look like this so far, with the respective component declarations and the routes registered as imports.

4. Running our App

ng serve

Now if we fire up our application, we should see this screens.

Nothing fancy to see here…

Right now, our application bootstraps all the needed resources at boot time. Each component defined previously, is bundled in the initial package that our apps serves to the client requesting our application.

We can see this in our browser’s devtools network tab, as soon as we start our application all the bundled resources of our application are downloaded and while the user navigates through it everything is available as the application were downloaded at the startup time.

5. Adding module lazy loading

So far so good. Now we want to lazy load our components as soon as the user requests certain feature of our application. First, we should create a new Module, which is necessary to wrap up the components that are going to be lazy load.

The following @angular/cli command will create our new module, called big-module.

Second, we need to adjust the folder structure to reflect the wrapping of BigFeatureComponent into our new recently created Module BigModule. So far our application folder structure should look like this, with our big-module folder wrapping big-feature-component.

Now, the interesting part about this blog post. We need to register our new Module to be lazy loaded as the user request certain feature of our app. Let’s say, when the user navigates to /bigComponent route.

For this we are gonna make use of the LoadChildren Module available in the @angular/router package. Registering a route with LoadChildren is as easy as the following code snippet. Here we just changed, which component we’re going to load for the children module we want to lazy load.

The LoadChildren path should be composed by the relative path of the module without its extension + # sign + module exported class.

In our case ‘./big-module/big-module.module#BigModuleModule’ follows the latter pattern. Being BigModuleModule the exported class of our big-module module.

Next, we need to define the child routes of our now lazy loaded module. As we just gonna have /bigComponent route and not any child route after it, we just need to register the empty path as child route for our lazy loaded module followed by the component we want to load after the mentioned route is reached in our router configuration.

One interesting thing to notice here, its the use of RouterModule.forChild method. This is used because we are in a child module, being AppModule the root module of our application and is where we registered our top level application routes.

Only call RouterModule.forRoot in the root AppRoutingModule (or the AppModule if that's where you register top level application routes). In any other module, you must call the RouterModule.forChild method to register additional routes.

So far so good, we’ve been through a long road. That’s all we need to get our BigModule lazy loaded as we navigate to /bigComponent route.

We can see in the network tab of the browser’s developer tools that our app as soon as we hit the route path, a new chunk of the application is downloaded. That’s the module being Lazy Loaded.

That’s all folks, hope you have enjoyed this post and have learned how to lazy load a module in angular. Go further, and try to optimize your application using this strategy aiming to reduce the inicial bundle size and speeding application boot time.

I’m looking for a new gig. Strong experience working on highly dynamic applications using both angular and reactjs. Dms open on X formerly twitter @camilogiraldo

Full source code can be found in github here.

Be sure to follow me @CamiloGiraldo and hope to share more blog post with you guys in the future. Feel free to share. Thank you.

Lazy loading Angular Modules was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

So you found that cool magic ultra-awesome library that will solve all your problems in your Angular application, only one problem… that library needs another library didn’t wrap in an Angular module, or even worse, the library itself has no wrapper so all you have is a brand new super sport V8 car without wheels

That’s what happened to me the first time I wanted to use a library called ng2-select2. It’s a cool library that helps you with your select elements in an angular application. The problem came out when the documentation said that slect2 library was necessary and it ended up needing jQuery as well. Both of them, JS libraries.

Besides, ng2-select2 library needs both of them as global libraries. This let them be reached across all the application (and it’s not necessarily a bad thing as probably you’ll need your JS library to be free like a bird and be available by you anywhere in your application)

Whatever it is, I’m gonna tell you how to implement and use a global Javascript library into your angular Application and for all practical purposes I’m gonna do it with ng2-select2 and its dependencies (essentially same for any JS library)

1- First thing you have to do is install your main library -ng2-select2 here- and save it in your package.json as it follows (omit this step if you are interested only in a JS library itself)

npm i -S ng2-select2

**Note: you can add your JS libraries like an ordinary JS application by using a CDN and link them with a script tag into your index.html file, however it’s not a good approach as it’s not recommended by angular team (and in most cases you won’t want be touching index.html file), so try to avoid this and continue with step 2

2- As specified in the documentation, it needs select2 and jQuery libraries in order to work, then…

npm i -S jquery select2

Easy peasy isn’t it? Does it means is everything runs sweet? Well… NOPE

The next you need to do is make your JS libraries global for your application, so they are reachable everywhere in the app.

4. Import your JS libraries in the “scripts” array into your .angular-cli.json file as it follows

**Note: Don’t forget to re-run your app due this file is not watched by the demon angular projects comes with

And that’s it! If you need to install any other JS library into your app, just follow the same steps and put it in the array script as shown above

WAIT! YOU SAID WE CAN USE THOSE JS LIBRARIES ANYWHERE IN MY APP!

Yes I did, and in order to do that I deeply suggest you to install the typings for any JS library you want to use (if there is any). It lets you type your library objects making your life easier (after all this is Typescript!, that’s the greatness of it)

5. Install the typings files you need (Optional)

npm i -S -D @types/jquery @types/select2

DON’T import the library you need to use into your component with the import statement (eg. import * as $ from ‘jquery’;) by doing so you’ll end up with two instances of the library (no cool!).

6. Just use it as it was already import into your component (please don’t kill me for using jQuery with Angular!)

And that’s it!. Easy isn’t it? If you find a better approach or find an error on my approach let me know. See you next time ;)

Setting a Javascript library as global in Angular was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yes, I am one of those developers who marries one technology, platform or framework and doesn’t care too much about the other ones. I realized this is a bad practice and if you are in the technology world this couldn’t be very healthy. Why? Because nothing is forever, one technology can be very popular today but that doesn’t mean it will keep being like that the next year or even the next month.

So, I decided to start paying attention to the Angular framework, and I have been playing around with Angular for a couple of weeks now. Like doing little things from a big project that the company I work for is building: Checking Angular code on GitHub, watching tutorials on YouTube, reading the official documentation or creating small web applications in order to start grabbing the concepts.

One of the reasons why I started doing this is because of the happy and vivid community around Angular. When I first found it, I knew that I wanted to be part of it as well as to be proficient with this framework.

If you are reading this and you are a newbie as me on Angular, I would like to cheer you up to follow my steps and to start this never-ending trip, I assure you that you will be glad about the things that you can build with this technology.

But how this change started?

I went to an Angular Meetup, being honest, I was doubting mainly because a little voice inside of my head was saying: “Man, you are doing it ok with React and React Native… so, why do you bother going to an Angular event?”

Community:

Despite of this little voice, I entered to the meetup and Bum! I felt a very positive energy there, seriously, everyone there seemed so friendly and happy. It seemed to me that I wasn’t in a common technology meetup, I was around of people who believe in Angular, who love building things with this technology and other technologies around it and also love the present and future that this technology promises to them.

Job Opportunities:

When this event was finished, I went home and I made a research about Angular and the companies who are seeking Angular developers, then I realized that there is a big amount of companies seeking for persons who know Angular. This made me say something like: “Oh man!… and why I don’t know Angular yet?”.

Yes, It could be hard:

I knew that it wouldn’t be easy to start looking at different concepts or points of view when you are deep in love with one technology, like I was with React; but of course going through this process makes you a better developer.

So, I have been learning interesting and different concepts on Angular like two way data binding or the popular strictly typed programming language of JavaScript: TypeScript.

Why I am starting to love Angular was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

An interface in object-oriented languages is a an abstract type that defines behaviours as method signatures. It can be considered as a code contract 📝, in order to implement it we must follow its rules.

Let’s create an interface called LabelledValue, this would be a custom type that assigns a label to a value:

Now we can use LabelledValue as a type, for instance, in a variable declaration:

We need to provide all the required elements in the interface in order to use it 📝:

The transpiler would alert us of this error with a message like: Type “{label: string}” is not assignable to type “LabelledValue”. Property “value" is missing in type “{label: string}”.

Optional properties

Some properties of an interface might not be required, and TypeScript allow us to define when a property is optional or not. Each optional property is denoted by a ? at the end of the property name.

In this interface the property hexColor is optional, and we can use this interface as follows:

The advantage of optional properties is that we can describe the optional properties while still also preventing use of properties that are not part of the interface.

Readonly properties

Properties with the keyword readonly can only be modified when an object is first created.

After the assignment, the values x and y can’t be changed.

The transpiler will alert us with the message: Left-hand side of assignment expression cannot be a constant or a read-only property.

This is pretty handy if we need an “immutable” behaviour. In general, we use const when we are using a variable , and readonly if we are using a property.

Interfaces are a very powerful feature, they allow us to have much more control over the way we structure our data. Let’s use Color interface inside Point interface, that way we can have consistency in our objects:

Class Types

In some cases class inheritance might not be the way to go ⚠️, but interfaces can provide the consistency needed among classes. Mainly because interfaces explicitly enforce that a class meets a particular contract.

An interface defines a generic template (properties and methods) that will have to be implemented by the class, this is another difference with inheritance where the child class inherits the members from the parent class.

For instance, we can define an interface that would enforce the implementation of two methods, area and volume.

Now we will implement this interface in a class:

A Brief Introduction to TypeScript — Part 4 was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

This new approach can be considered as syntactic sugar because it doesn’t change the existing prototype-based inheritance model, but allows a simpler way to create objects and manage inheritance. TypeScript allows us to use these techniques now without having to wait for the browsers to support them 🚀.

Class declaration

In OOP paradigm, a class represents the blueprint of an object or entity, it provides initial values for state and implementation of its behaviour. This representation allow us to create reusable components and TypeScript provides syntax that is very common in other object-oriented languages.

In general, a class is composed of a name, attributes and methods. The syntax to create a simple class looks like this:

This class contains one attribute (name) and two methods ( constructor, greet).

Now that we have the blueprint, we can create several objects based on this class. When an object is created by the constructor of a specific class, this object is called an instance of the class.

We can create and initialize an instance of this class using its constructor as follows:

Now that we have created john, we can use the behaviour implemented in the class. In this case, the greet method:

The console output is: Hi! I'm John Doe.

Member variables

In TypeScript, each class member (property or method) is public by default. This means that they are visible outside the class, even if they don’t have the explicit public label:

If we create an instance:

The console output is: John Doe. But since each member is public by default, we can access and change them outside of the class:

The console output is: Jane Doe, even if we created a person called John Doe. This free access to class members can be very dangerous if it’s not controlled ⚠️, that’s why TypeScript adds the possibility to have private members.

When a member is marked private, it can’t be accessed from outside of its containing class.

The transpiler would alert us of this error with a message like: Property “name”is private and only accessible within class “Person".

Class behaviour

In the last article we developed some typed functions, mostly related with arithmetic operations, like add and multiply. We could create a basic calculator class with them 🔢 :

Notice that we didn’t write function for the methods.

The behaviour of this class is defined by its methods, and we can expand these until we create a class that fully defines the behaviour that a basic calculator should have:

Inheritance

One of the main features in OOP paradigm is the possibility to create new classes based on others using inheritance.

For instance, we would like to extend our basic calculator into a scientific calculator. Calculator would be our parent class:

And we would like to extend from it into another class called ScientificCalculator, this would be the new child class that inherits all the properties and methods existing in Calculator. ScientificCalculator can also include additional properties and methods not included in the parent class.

A Brief Introduction to TypeScript — Part 3 was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Named functions

The syntax to declare a function in JavaScript follows a particular structure:

For instance, if we would like to create a named function to calculate the sum of two given numbers, it would be like this:

And if we test it with numbers it behaves as expected:

But JavaScript allows to use this function with other datatypes, for example boolean and string:

And this is not bad per se… but maybe, just maybe… this could generate some unexpected behaviours when dealing with large scale projects. 🔥

This is why TypeScript adds new capabilities to these functions, one of them being the capability to declare the type of each parameter in order to create the signature:

We can also add a return type, but TypeScript is able to infer it with the return statements:

Optional and Default Parameters

In TypeScript, every parameter is assumed to be required by the function. This is very different from traditional JavaScript where every parameter is optional ❗. If we would like to have this optional parameters, we need to add them after the required parameters with ?:

In TypeScript, we can also set a default value for a parameter in case of not having a value provided or undefinedis passed.

Anonymous functions

If the function name is omitted in the function expression, it becomes an anonymous function. This kind of function is usually stored in a variable or used as an argument of another function.

When stored in a variable it ends with a semicolon because is part of an executable statement.

As seen before, TypeScript gives the option to add types to each parameter and to the function itself with the return type.

This is called anonymous function with type inference, but in the case that we would need to declare the full type of the function, it would be as follows:

In order to declare the type of the variable add the input and output types need to be declared. The input types are declared as (x: number, y; number)accordingly with the parameters of the function, and the output type is related to the return type numberpreceded by the => symbol.

Arrow functions

So far we have been seeing the functionkeyword a lot in the different declarations, and this is quite repetitive for a programming language that is functional. But TypeScript offers a simpler syntax to declare a function.

Let’s use one of the already studied functions:

We can rewrite addas follows:

This function declaration is called arrow function because of the => operator and is known in other languages as lambda function. In general, arrow functions can be declared as:

If the statements consist in just one return statement, it can be simplified and return can be omitted:

We can add types to each parameter and the return type:

A Brief Introduction to TypeScript — Part 2 was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.

This language allow us to use features from the most recent ECMAScript versions and even some features that are not even in the scope of the standard. This is because when compiled, it produces JavaScript in a cross-platform safe version. TypeScript, currently in the version 2.5, adds features like optional static typing, classes, interfaces, modules, and many others. All of this allow us to use JavaScript from the future right now!

But how does all this sorcery work?

TypeScript needs something that transforms its syntax into standard JavaScript, this is called the transpiler, a type of compiler that takes the source code in a programming language as the input, and transforms it into another programming language.

TypeScript files have the .ts extension, and the transpiler produces the well known .js files.

TypeScript also allows the use of common JavaScript libraries and frameworks, by providing an easy integration with declaration files.

Types

One of the most controversial features of this language are its types, mainly because it seems to be sometimes an initial misconception of how they work and how strict their use really is. In order to clarify this, let’s start by reviewing our understanding of types.

Dynamic Types

JavaScript counts with dynamic types. This means that when you declare a variable, you don’t define the type:

The type will be inferred during execution, this allows a variable to have different types:

This apparently simple and convenient feature, can make the programming and debugging activities way more complex in the long run.

Static Types

This is what makes the whole difference, TypeScript adds optional static types to JavaScript, this means that you can declare a typed variable:

And the type of this variable will be the same in your development process thanks to the type checking at compile time:

The transpiler would alert us of this error with a message like: Type “number” is not assignable to type” string”.

TypeScript supports most of JavaScript types and it also adds some other new datatypes.

The most important thing to notice here is that the static types provided by TypeScript are optional, this means that even the core principle behind the language can be used based on convenience, unlike other static typed languages that enforce the use of types. And this separates TypeScript from other typed languages, for instance Java, where the use of types is very strict.

Even more, in case you decide not to adopt types, the types will be inferred by the transpiler.

Can you see it? I bet you can now!

Now let’s dig into what TypeScript types have to offer:

Boolean

Is similar to the Boolean JavaScript datatype, it represents logical values that can be true or false:

Number

As well as in JavaScript, all numbers are floating point values. TypeScript supports decimal, hexadecimal, octal and binary literals:

String

Like the well known string type in JavaScript, this datatype uses double quotes (”) or single quotes (’) to surround the text. A basic string variable declaration in TypeScript would be:

or:

TypeScript supports the use of template strings, these are multiple lines surrounded by the backtick/backquote (`) character.

You can also have embedded expressions within a template string with the form ${expression}, these allow you to have evaluated operations inside the string, also known as string substitution.

In this scenario, the variable message as the following value:

TypeScript 2.5 says:
Hello!

These features enhance significantly the traditional JavaScript string datatype, and allow us to use modern capabilities that are well known in other programming languages.

Array

A typed array can be declared in two ways. In the first one, the datatype is followed by []:

In the second one, the generic array type is used with Array<elemType>:

Enum

Is a special datatype and it allows a variable to be a set of predefined constants, giving a consecutive numeric value associated with each identifier.

Any and Void

When we don’t know the type of the variable, we can use the type any, this means to mute the type checking but in some scenarios might be necessary, like when we deal with dynamic content or external sources.

The absence of any type at all is represented by void, this is mostly used with functions and interfaces that we will see later.

Other Datatypes

TypeScript 2.x introduces new datatypes like: null, undefined and never. But for now we will avoid them in order to focus just in the common scenarios faced with static types.

A Brief Introduction to TypeScript — Part 1 was originally published in Angular Medellin on Medium, where people are continuing the conversation by highlighting and responding to this story.