Angular Project Structure

This is what our project tree looks like:

Let's have a look at it step by step:

1. /e2e/ directory:

├── e2e

│ ├── app.e2e-spec.ts

│ ├── app.po.ts

│ └── tsconfig.e2e.json

 COPY CODE
e2e stands for end-to-end and it refers to e2e tests of the website. It contains testing
scenarios (scripts) which simulate user behavior. We can simulate a user who visits a
website, signs in, navigates to another site, fills the form and logs out.

2. /node_modules/

All 3rd party libraries are installed into this folder when you run npm install. Those
libraries are bundled into our application. What is important to know is that you
 shouldn't include this folder when deploying your application to production or
committing to the git repository. If you move your project to a new location you
should skip this folder and run npm install in a new location.

3. /src/

├── src

│ ├── app

│ ├── environments

│ ├── favicon.ico

│ ├── index.html

│ ├── main.ts

│ ├── polyfills.ts

│ ├── styles.scss

│ ├── test.ts

│ ├── tsconfig.app.json

│ ├── tsconfig.spec.json

│ └── typings.d.ts

 COPY CODE
This is where we will keep our application source code.

o /app/

│ ├── app

│ │ ├── app.component.css

│ │ ├── app.component.html

│ │ ├── app.component.spec.ts

│ │ ├── app.component.ts

│ │ ├── app.module.ts

│ │ └── typescripts

 COPY CODE
This folder contains our modules and components. Remember: Each Angular
application must have at least one module and one component.

o /asset/
 This folder contains static assets for our app like images, icons, styles.

o /environments/

This folder contains two files, each for different environments. You will use
this file to store environment specific configuration like database credentials
or server addresses. By default there are two files, one for production and on
for development.

o favicon.ico

The favicon of our app.

o index.html

This is is a very simple HTML file. If you open it you will note that there are
no references to any stylesheet (CSS) nor JS files. This is because all
dependencies are injected during the build process.

o main.ts

This is the starting point for our app. If you ever coded in languages like Java
or C you can compare it to a main() method. If you haven't, then just
remember that our application starts to execute from this place. This is where
we are bootstrapping our first and only module — AppModule.

o polyfils.ts

Polyfils files are used for the compiler to compile our Typescript to specific
JavaScript methods which can be parsed by different browsers.

o styles.css

This is global stylesheet file that is by default, included to our project. Keep in
mind that each component has its own style component which applies styles
only within the scope of given component.

o test.ts

This is a configuration file for Karma. Karma is a testing tool shipped along
with Angular, we will cover it one of the later lessons.

4. .angular-cli.json

This is an important file. It contains the configuration for CLI which defines which
3rd party script or styles should be included, which files should be served as static
assets, where compiled code should be placed and much more. We will cover it in
later lessons.

5. .gitignore
 This file instructs git which files should be ignored when working with git repository.

6. karma.conf.js

Another configuration file for Karma. We will cover that in the future.

7. package.json

This file is mandatory for every npm project. It contains basic information regarding
our project (name, description, license etc.) commands which can be
used, dependencies — those are packages required by our application to work
correctly, and devDepndencies — again a list of packages which are required for our
application however only during the development phase. I.e. we need Angular CLI
only during development to build a final package however on production we don't
need it anymore.

8. protractor.config.js

asdf

9. README.md

File containing a description of our project. All the information which we would like
to provide our userswith before they start using our app.

10. tsconfig.json

A bunch of compiler settings. Based on these settings, it will compile code to JS code
which that browser can understand.

11. tslint.json

TSlint is a useful static analysis tool that checks our TypeScript code for readability,
maintainability, and functionality errors. This file contains its configuration. We will
see how it works in a future lesson.

Fundamentals
In order to crate Angular apps, you have to know Typescript. Within thenext few
lessons I will teach you its basic concepts, by covering the following subjects:

 Type annotations
 Arrow functions
 Interfaces
 Classes
 Constructors
  Access modifiers
 Properties
 Modules

If you are familiar with these concepts you can skip this tutorial and navigate to the
next part, however if you are new to TypeScript then follow it carefully.

What is TypeScript?

At a first glance you might confuse TypeScript with JavaScript. Especially that any
valid JavaScript code is also a valid TypeScript code, however, it doesn't work
another way around. TypeScript is a superset of JavaScript.

Image taken from https://angular2buch.de

Remember:
TypeScript is a superset of JavaScript

That means that TypeScript extends JavaScript with extra functionality which is not

present in the current version of JavaScript supported by most browsers. So what
are those features?

Strong typing

If you are familiar with languages like Java or C# you probably know that each
variable requires a type and this type has to be declared upfront. JavaScript is a
loosely typed or a dynamically typed language. Variables in JavaScript are not
directly associated with any particular value type, and any variable can be assigned
(and re-assigned) values of all types:

var foo = 42; // foo is now a Number

var foo = 'bar'; // foo is now a String

var foo = true; // foo is now a Boolean

 COPY CODE
In a weakly typed language, the type of a value depends on how it is used. For
example, if I can pass a string to the addition operator and it will AutoMagically be
interpreted as a number or cause an error if the contents of the string cannot be
translated into a number. Similarly, I can concatenate strings and numbers or use
strings as booleans, etc.

In a strongly typed language, a variable has a type and that type cannot change.
What you can do to a variable depends on its type. If we try to compile the above
code in TypeScript we will get the sfollowing error:

[ts] Subsequent variable declarations must have the same type.

Variable 'foo' must be of type 'number', but here has type 'boolean'.

 COPY CODE
The advantage of a strongly typed language is that you are forced to make the
behavior of your program explicit. If you want to add a number and a string your
code, you must translate the string into a number to be used as an operand of the
addition operator. This makes code easier to understand because there is no (or
less) hidden behavior. This also makes your code more verbose.

Remember:
Strong typing is optional in TypeScript but using this feature makes your application
more predictable and make it easier to debug so you should definitely make use of it.

Object-oriented

Object-oriented programming (OOP) is an old concept used by multiple languages

like Java or C# to help developer associate together data and methods within one
"object". In OOP object are created and are able to interact with each other using one
another's public facing methods. JavaScript itself is not an object-oriented
language in the way that C++, C#, or Java are. TypeScript, on the other hand, can
be treated as an object-oriented language because of the language constructs it
introduces on top of JavaScript closures.

TypeScript brings many object-oriented features which we missed in JavaScript for a

very long time. We have explicit concepts of:

 Classes
 Interfaces
  Constructors
 Access modifiers (public and private)

We will learn all of that in the later sections.

Compile-time error

Let me explain first what run-time error is as this is a common case. We are talking
about the run-time error when we face any issue while using our application. In
other words — if you make a mistake when you create your website and write some
code, you will see it only while using the application/website. For example, if you
make a typo in an webpage file your browser console will show you an error when
you load that page.

Due to weak typing in JavaScript, it often happens that we try to perform operations
on a variable with a different type. If our application logic is complex we might not
spot that we are trying to assign elements of a different type to each other. In
JavaScript, we will get to know about the error only when someone triggers code and
it fails. In contrast, TypeScript can provide us with compile-time errors, which means,
it can spot errors while compiling code to JavaScript, and fix it before deploying to
production. Of course it won't catch them all, but still a lot.

Awesome tool-set

I won't write much about this. Along with this course you will see how many useful
tools come with Angular.

Let's don't waste time and start coding!

PREVIOUS LESSON