Just before we plunge into the coding bit, and start with our web app, there are some more things I’d like to mention in conjunction with yesterday’s post. Namely we’ll explore what Angular is made up of, and what we’re going to be learning, the most-mentioned, and talked about feature of Angular - two-way-databinding, etc.
Some of the reasons that I, personally, will be using Angular to build web apps, are mentioned in yesterday’s post. Apart from those, there are a few more reasons to use Angular to build you next web app.
As mentioned before, all Angular web apps are single page applications. But what are single page web applications? Single page applications are not to be confused with simple applications. Yes, they can be simple, but more often than not, they are more complex. The term “single page application” refers to an application that loads only a single HTML file within the browser, and then dynamically, these apps they update / modify this single HTML update based on how a user uses, and interacts with the application. Single page applications heavily rely on JavaScript that is compiled on the client (browser). These applications uses HTML5, and asynchronous JavaScript to work. Single page applications help create a very fluidic user experience, without page reloads. Angular is for making such web apps. All components (see below) in Angular, are launched with the index.html page (singe page app).
Angular is great for creating responsive, reactive applications that are fast, cross-platform web apps that manipulate the DOM, while working with the datasets. Writing apps in Angular is quick, because of the CLI, and other modules that Angular is built of. There are quite a few paid, and free Angular templates available to kick start your app development, this makes prototyping your next web app super fast, and super easy. It’s made of JavaScript, and when Angular compiles TypeScript to JavaScript, it auto optimizes the code for the multitude of JavaScript virtual machines.
Still not convinced? Read more here.
What Will We Be Learning? What Makes Up Angular?
Angular is made up of modules, and components. All apps made in Angular are made up of modules, and components too. A module is a set of components, and some other stuff, rolled into a single set or unit. A component is just that, a component of the app - a section or a bit of an app. This component can be as small as a button component or as big as an entire web page / view.
Angular apps have more than just modules, and components to them though. Most Angular apps use directives, services, dependency injectors, controllers, scopes, data-binding, routing, observables, forms, pipes, http calls, and so on. All of the above mentioned words either form a part of a component or a module, and afford a certain functionality with which our apps can do what they need to. For e.g. services, and dependency injections help different parts of an Angular app to communicate with other parts of the same app. They also help maintain, and keep track of the state of an app.
Routing is used to manage URLs. Now, it’s an obvious question — Since Angular apps are single page web apps that do not depend on page reloads, why then do we need routing? There are multiple answers here. First and foremost, routing helps logically break up the single page app into multiple parts. It also affords us user, and robots friendly URLs that can help a user navigate to a part of the app she is looking for without having to start at the top. Having routing built in, also helps the browser’s history to keep track of URLs, in the case when, and where a user clicks on the back button, routing kicks in, directing the user again to what she’s looking for. This offers a certain reliability to users, browsers, and search engines alike.
Observables allow an Angular app to work with asynchronous code, and Angular embraces asynchronous code. We’ll see more of Observables later in the course.
Forms, like the name suggests, is all about creating forms, submitting forms, and collecting form datasets.
Pipes are used to filter data that is sourced from a data source, before it’s displayed to the user. Pipes are essentially filters, and if you’re familiar with the terminal, then you may have already used pipes to connect or filter.
One of the features that Angular affords us is two-way-databinding. What’s two-way-databinding? Data is often manipulated, over a period of time; it is mostly in a state of flux. Consider a property “sentence” as a part of a model “grammar” (grammar here is a table or a dataset). When a user or the app itself updates the property “sentence,” two-way-databinding makes sure that it is updated everywhere within the app. By everywhere I mean that “sentence” not only gets updated in the table or dataset, but also the variables that are assigned to hold the value of “sentence” for a particular row / set too get updated, along with the UI. Anywhere within the app, be it the UI, the Model, or the code (variables), when “sentence” for a dataset #id or row #id, of the “grammar” table or dataset is updated, then this updated value propagates throughout the Angular app, irrespective of where the change occurred and / or how.
Two-way-databinding in Action
Two-way-databinding just means when properties of a model get changed, they changes also reflect within the UI, and vice-versa. With Angular, two-way-databinding comes bundled, and it does make a lot of things easier. We’ll see more of two-way-databinding, down the line.
We’ll be using most of what’s mentioned above, along with learning how to test, and deploy our Angular applications. All the things mentioned above, and some more stuff, makes up Angular. And these are what we’ll be looking at, over the course of the next few weeks.
Right, so that’s that. Next up is a first exploration of the project folder, and understanding a few other things, followed by a long post on components.
