Angular is a mature and stable framework that offers a lot out-of-the-box.
While the learning curve might be a bit steep, it offers great DX (developer experience) and a way to streamline your team's work.
A funny anecdote I've read online has to do with a small company of about 50 developers where half of the employees were working with Angular, and the other half was working with React.
One of the Angular developers wrote that while they were constantly delivering their projects on time, and had enough energy left to go grab some beers from time to time after office hours, the React team was having to do overtime work most of the time - and of course, had to debug weird issues instead of relax a bit.
Obviously, the above story is anecdotal, but I have a hunch it might be true.
Out of all the frontend frameworks I've worked with, Angular takes the high runner-up position - i.e the second place.
The first place, as far as DX is concerned, still goes to the Elm language, but that's a topic for another book.
Due to its popularity and relative ease of use and its streamlined approaches, I'd even say that Angular might share place number one with Elm - at least in my experience.
Anyway, enough with singing praises to Angular.
Let's review what we'll learn in this book.
Things we'll learn:
Here's a non-conclusive list of the things we'll learn, start to finish:
1. Angular is a grouping of pre-built code that helps us build websites
2. There are two kinds of Angular (the "old" one called Angular.js and the "new" one, simply called Angular)
3. To use Angular we need to have Node.js and NPM installed
4. We also need to have Angular CLI installed
5. To build a new Angular app we use this command in the console: `ng new ourappname` (where `ourappname` is the part we can change)
6. `ng s` serves our app in the browser
7. We can view our app at `localhost:4200`
8. To check what version of Angular is installed on our machine, we run `ng --version`
9. To automatically update our version of Angular, we run `ng update`
10. When running `ng new someapp` we can choose if we want to use routing and we can decide between various styling options
11. Each Angular component consists of the *Class file*, the *Template file*, the *CSS file*, and is wrapped up by a module file.
12. Multiple Angular components can "live" in the same module.
13. The Class file of an Angular's component has the following structure: *import-decorator-export*
14. The `@Component` decorator is given properties using an object literal. This decorator adds some meta information about our component, and is used internally by Angular to put together a working app.
15. The *Class* file defines the *logic* of our component
16. The *Template* file defines the *ui* of our component
17. Variables are displayed in template files using the moustache syntax
18. The `app.module.ts` file's structure is as follows: *the import - the @NgModule Decorator - the export*. Actually, all modules follow this structure.
19. The `@NgModule` decorator describes how to compile a given Module and all its components. It has the following properties: `declarations, imports, providers, bootstrap`
20. The Router (e.g `app-routing.module.ts`) is a service
21. The `app-routing.module.ts` Router has this structural pattern: *the imports - the routes - the @NgModule decorator - the export*
22. An Angular app is mounted inside the `index.html` file, in the `<app-root></app-root>` element
23. Our Angular apps built with `ng new someapp` come pre-bundled with Git, and a single commit
24. To generate a component, we can run `ng generate component componentname`, or more succinctly: `ng g c componentname` - where we can change the `componentname` to whatever works for us
25. The above command generates 4 new files, and updates the `app.module.ts` file automatically
26. Each newly generated component has its own subfolder
27. Each component in Angular goes through a life-cycle, and we can add our own code to each of the predefined stages of this life-cycle using *lifecycle hooks*.
28. An example of a lifecycle hook is `ngOnInit()`
29. Once the new component has been defined and the module updated, it can be added as a sub-component to a "parent" component through the "parent" component's template (e.g "the navigation component to the App Module")
30. When we generated a component, Angular automatically updated `app.module.ts`, by importing it and listing it inside the `declarations` in the `@NgModule` decorator of `app.module.ts`
31. We can style each component individually
32. To target a parent, we can use the `:host` style selector
33. We don't have to use a generator, we can write an Angular component from scratch.
34. We can add global styles to `./src/styles.css`
35. We use `routerLink` in Angular instead of the `href` attribute in anchors
36. Each route is defined as an object inside the `routes` array in `app-routing.module.ts` file
37. Each such object has two properties: `path` and `component`
38. There are several ways to bind template files to class files - this is data binding.
39. We can data-bind in tree ways, through: 1. interpolation, 2. event binding, and 3. property binding
40. We bind events using round brackets: `()`
41. We bind properties using square brackets: `[]`
42. We set the values of data in our component's *Class* file, e.g `border = 10`
43. We can dynamically update HTML attributes in our templates using property binding and method calls in our class files
44. We can bind properties to button clicks by updating properties inside the methods called by click events
45. Variable interpolation, property binding, and event binding are all examples of one-way data flows
46. We can use the "banana in a box" syntax (`[()]`) to achieve two-way binding
47. We provide data to our angular apps using services
48. A service is generated using this code: `ng generate service someservice`, where the `someservice` part is editable
49. The above command can be shortened to `ng g s someservice`
50. Data is provided through methods in our services
51. When we define a method in a service, we need to provide the expected return value of that method
52. We use `HttpClient` to access third-party APIs (online data sources)
53. Angular errors can sometimes nudge us to successful debugging of our Angular apps
54. To consume a service in our component's class file, we must subscribe to a service using the syntax: `this.data.someMethodFromService().subscribe(res => { // do something with res here })`
55. We use data model files to define the expected structure of our data, in an `interface`
56. To bind the value returned from a service, we assign whatever was the result of the subscription to the property that we want to update. For example: `this.border = res`, where `this.border` is the `border` property declared on the Class file and bound to in the Template file, and the `res` variable is the result of the `subscribe()` call.
Things we'll gloss over
2. There are two kinds of Angular (the "old" one called Angular.js and the "new" one, simply called Angular)
3. To use Angular we need to have Node.js and NPM installed
4. We also need to have Angular CLI installed
5. To build a new Angular app we use this command in the console: `ng new ourappname` (where `ourappname` is the part we can change)
6. `ng s` serves our app in the browser
7. We can view our app at `localhost:4200`
8. To check what version of Angular is installed on our machine, we run `ng --version`
9. To automatically update our version of Angular, we run `ng update`
10. When running `ng new someapp` we can choose if we want to use routing and we can decide between various styling options
11. Each Angular component consists of the *Class file*, the *Template file*, the *CSS file*, and is wrapped up by a module file.
12. Multiple Angular components can "live" in the same module.
13. The Class file of an Angular's component has the following structure: *import-decorator-export*
14. The `@Component` decorator is given properties using an object literal. This decorator adds some meta information about our component, and is used internally by Angular to put together a working app.
15. The *Class* file defines the *logic* of our component
16. The *Template* file defines the *ui* of our component
17. Variables are displayed in template files using the moustache syntax
18. The `app.module.ts` file's structure is as follows: *the import - the @NgModule Decorator - the export*. Actually, all modules follow this structure.
19. The `@NgModule` decorator describes how to compile a given Module and all its components. It has the following properties: `declarations, imports, providers, bootstrap`
20. The Router (e.g `app-routing.module.ts`) is a service
21. The `app-routing.module.ts` Router has this structural pattern: *the imports - the routes - the @NgModule decorator - the export*
22. An Angular app is mounted inside the `index.html` file, in the `<app-root></app-root>` element
23. Our Angular apps built with `ng new someapp` come pre-bundled with Git, and a single commit
24. To generate a component, we can run `ng generate component componentname`, or more succinctly: `ng g c componentname` - where we can change the `componentname` to whatever works for us
25. The above command generates 4 new files, and updates the `app.module.ts` file automatically
26. Each newly generated component has its own subfolder
27. Each component in Angular goes through a life-cycle, and we can add our own code to each of the predefined stages of this life-cycle using *lifecycle hooks*.
28. An example of a lifecycle hook is `ngOnInit()`
29. Once the new component has been defined and the module updated, it can be added as a sub-component to a "parent" component through the "parent" component's template (e.g "the navigation component to the App Module")
30. When we generated a component, Angular automatically updated `app.module.ts`, by importing it and listing it inside the `declarations` in the `@NgModule` decorator of `app.module.ts`
31. We can style each component individually
32. To target a parent, we can use the `:host` style selector
33. We don't have to use a generator, we can write an Angular component from scratch.
34. We can add global styles to `./src/styles.css`
35. We use `routerLink` in Angular instead of the `href` attribute in anchors
36. Each route is defined as an object inside the `routes` array in `app-routing.module.ts` file
37. Each such object has two properties: `path` and `component`
38. There are several ways to bind template files to class files - this is data binding.
39. We can data-bind in tree ways, through: 1. interpolation, 2. event binding, and 3. property binding
40. We bind events using round brackets: `()`
41. We bind properties using square brackets: `[]`
42. We set the values of data in our component's *Class* file, e.g `border = 10`
43. We can dynamically update HTML attributes in our templates using property binding and method calls in our class files
44. We can bind properties to button clicks by updating properties inside the methods called by click events
45. Variable interpolation, property binding, and event binding are all examples of one-way data flows
46. We can use the "banana in a box" syntax (`[()]`) to achieve two-way binding
47. We provide data to our angular apps using services
48. A service is generated using this code: `ng generate service someservice`, where the `someservice` part is editable
49. The above command can be shortened to `ng g s someservice`
50. Data is provided through methods in our services
51. When we define a method in a service, we need to provide the expected return value of that method
52. We use `HttpClient` to access third-party APIs (online data sources)
53. Angular errors can sometimes nudge us to successful debugging of our Angular apps
54. To consume a service in our component's class file, we must subscribe to a service using the syntax: `this.data.someMethodFromService().subscribe(res => { // do something with res here })`
55. We use data model files to define the expected structure of our data, in an `interface`
56. To bind the value returned from a service, we assign whatever was the result of the subscription to the property that we want to update. For example: `this.border = res`, where `this.border` is the `border` property declared on the Class file and bound to in the Template file, and the `res` variable is the result of the `subscribe()` call.
Things we'll gloss over
- Observers and observables
- Subscriptions
- Data models
- Building more complex apps
Unfortunately, we couldn't fit all of these concepts in such a short book like this one, without making it a lot more theoretical (and a lot longer).
Explanation of the reason why this book was written the way it was
The focus of this book is on *practicality*. I wanted to write a book that would give the most value to its readers in the shortest amount of time.
Here are a few things to consider regarding this concept:
1. This book comes with its own repo. I've referenced this repo throughout the book, and it should serve as a quick way to check against your own errors as you read it.
2. The goal was to make this book into a tool that would give a complete Angular newbie a chance to get to some level of comfort with Angular, in a neat and practical package. I dare say that this entire book can be read, cover from cover - *while following examples* - in about 5-6 hours.
The above two considerations make this book very useful if you're faced with the following situations:
2. The goal was to make this book into a tool that would give a complete Angular newbie a chance to get to some level of comfort with Angular, in a neat and practical package. I dare say that this entire book can be read, cover from cover - *while following examples* - in about 5-6 hours.
The above two considerations make this book very useful if you're faced with the following situations:
- you are a new developer in an Anglar team and need to get up to speed quickly
- you need to cram for an exam involving Angular
- you need to quickly get to some level of competence with Angular for a job interview
Obviously, this book opens more doors than it closes.
It's my attempt at giving the best bang for not only the buck, but also for the time invested.
There's many Angular materials online that are simply too complex to grasp, and take too much time to go through.
Hopefully, I've achieved my goal with this one.
## Additional explanation
In early 2018, I set out to write an in-depth book on JavaScript basics.
This single book soon turned out to be over a thousand pages long, so I've split it into three books.
Again, these three books started getting a bit on the heavy side, so I've again split them into the total of five books.
It's 2021, and those books are still in progress.
I've learned one thing from this experience.
Maybe it's better to sometimes write books that go for quick wins.
Not that anything is inherently wrong with my JS books. Actually, I'm really proud of them.
But with this Angular book series, I wanted to try a different approach. I hope you'll like this different take on learning a JavaScript (TypeScript) framework, and that you'll get value out of it.
If that's the case, please shout it from the rooftops!
It's quite a lot of work to write a book like this, and it's not a very glamourous job. Also, you won't make too much money with it.
So, if you find yourself learning a lot from this book, please leave a review, or share your thoughts with me!
Thank you.
What's next?
This brings me to the topic of new books in this book series.
Currently, they are only a plan. I try not to plan too far ahead with these books - it's not a productive approach.
Thus, I've only planned to write the second book in this series, in the coming weeks/months - depending on my workload.
Currently, I envision the second Angular book to cover in more depth the topics of:
1. Working with Angular Animations
2. Observables
3. Subscriptions
4. Other basics of RxJS
5. A bit more explanation on TypeScript
6. Using ngx-bootstrap and MDL with Angular
2. Observables
3. Subscriptions
4. Other basics of RxJS
5. A bit more explanation on TypeScript
6. Using ngx-bootstrap and MDL with Angular
In a few words, I'm planning to continue guiding the reader through the interesting world of Angular web development.
Till then, I wish you all the best in your life and career.