Angular version 14 was released and like every new version, it, of course, also introduces a couple of smaller changes and fixes, and minor new features and improvements, and I'll provide a link to the official announcement blog post below the video, attached to this video so that you can read and learn all about those smaller changes. However, it also introduces two big new features: Typed Forms and Standalone Components, though the latter is in developer preview and might change until it is fully stable in a future Angular version. But in this video, we'll take a look at these two big new features. I'll let you know what this means for Angular and your apps, and I'll also let you know what this means for my Angular course in case you're taking that. Now, let's start with Typed Forms, the first new bigger feature introduced by Angular 14. Here I've got a standard form using the Reactive Forms approach, which is offered by Angular. In Angular, you can handle forms with the template-driven approach or by using the Reactive approach, and we're using the Reactive approach here because Typed Forms, this new feature, only applies to Reactive Forms, not to Template-driven Forms. There's no change to Template-driven Forms. Now, here for Reactive Forms though, the HTML code is the same you would have written for Angular 13, 12, 11 and so on. So this does not change. If you have a look at the TypeScript code for this component, the code also doesn't really change that much. I'm creating a FormGroup here with an email and a age FormControl and I'm connecting this FormGroup and then the individual controls to my HTML elements. That's what I'm going here. However, we'll see a difference if we then try to work with our FormGroup here in the TypeScript code. For example, upon form submission, we might want to log or send the individual form-controlled values to a server or to the console here in this case. Therefore, we can access this FormGroup and what you'll notice now is that if I try to access the values of this form with the value property on the form FormGroup, if I add another dot, I'm getting auto completion here, which basically tells me that I only have the age and email value here. Now, prior to version 14, we would have not gotten any auto completion here because Angular didn't know that this FormGroup only has these two FormControls because FormGroup was basically of type any before. So it didn't know what was inside of it. This changed now. So therefore, if I, for example, try to access a password control here, I get an error in my code because now Angular knows that such a FormControl does not exist in this FormGroup, and I have to add it first or fix my error in another way. But it's not just the existence of FormControls, which is now known to Angular. It's also the type of value that can be entered into a FormControl. For example, here I could try to output age and I might want to add plus one to it. Now, if I do this, then I'm actually getting an error here because this could be null or undefined. And whilst technically in JavaScript, we could, of course, add one to null or undefined, we might get unexpected results if we try to do that. We can, of course, let Angular know that this will never be null by adding an exclamation mark but again, we now have to be a bit more explicit and we can avoid unintended errors where we accidentally might operate on a null value. And of course here adding the exclamation mark would actually not be a great solution because we don't know if this is null or not. But it's not just the null check, which we now might need to add to our code to avoid accidental work on null values. It's also more than that because now we just don't know whether a control exists or not and whether it's maybe null or not, and we have to add code to make sure that we're not operating on null values. We now also have extra information on the type of value we have when it's not null. For example, I might want to count my email characters for whatever reason. I want to know the length of characters entered in the email address. Therefore, I could add an exclamation mark to let TypeScript know that I know that this will never be null. The better solution, of course, probably would be to add some guard here though where I check if this form email is set. So if it's not null, and then I operate on it. But either way, I can make sure that I know that this won't be null and then I could try to access length here to get the number of characters entered. But now I'm getting another error because that's the last piece you should know about Typed Forms. It's not just about null values and the existence of FormControls and FormGroups, it's also about the type of value that can be entered into a FormControl. And the way I'm initializing the FormGroup here basically tells TypeScript that I have two controls in that FormGroup and they're both null initially but I'm not passing any other information to TypeScript and therefore, TypeScript infers that they are always null so that there can never be any other value inside of such a FormControl besides null. And this is probably a bit too strict because, of course, I might want to initialize a FormControl to be null initially, to have no value initially but eventually, the user should be able to enter a value and then, of course, that will not be a null value. To let TypeScript know which value might eventually end up in such a FormControl, FormControl is now a generic type where we can specify which values can end up in that FormControl. And here we could say that it's a string or null. Null initially but once the user entered something, a string. For age, we could say that it's maybe a number or null. That would be possible here. We then, of course, wanna make sure that the type is set to number here on our input field. And now with that, you see this error for the email went away because I'm telling TypeScript that if this is not null, if it's set to some value, it will be a string because that is what I'm clarifying here. And the idea behind Typed Forms is simply that you have more type safety in your TypeScript code, that you're not operating on any as much because the problem with type any is that all your code looks fine whilst you're writing it but your app could crash in certain scenarios when it's actually running, so at runtime and you typically wanna avoid that. So that's one new feature. Now, one important question, of course, is what does this mean for your existing apps? Well, if you're not using Angular's strict mode, then it actually doesn't have any impact because you have way less stricter type checks in that case anyways. If your Angular app was initialized using strict mode though, then you might need to update your code and add extra generic type annotations like this or extra type guards like this where you make sure that you only operate on a value that could be null after checking whether it is null. If you don't have the time to update all your code like this right now, if you don't wanna add all these extra annotations right now because it would mean a lot of work for you, you can also follow an alternative approach and instead of FormControl, you could use the UntypedFormControl and also the UntypedFormGroup. This basically gives you back those old FormControls and old FormGroups, which you had in Angular 13 and earlier, and all your code will then continue to work as it did before, and you see this error, for example, is gone. And if you're using the ng update command provided by the Angular CLI, it should actually make those replacements for you automatically. This allows you to then switch back to FormGroup and FormControl and add those extra type annotations whenever you have the time for it. Now, Typed Forms, Typed Reactive Forms to be precise are one nice feature, which can improve the overall type safety of your application. Another big new feature, especially for the future of Angular are Standalone Components though. Standalone Components is one of the most amazing features added to Angular in a long time because it has the potential of making writing Angular apps much simpler and easier than it is today. The idea behind Standalone Components is that you can get rid of NgModules. So of these extra module files with all those imports and with all the extra declarations you have to add there because at the moment with Angular 13 and older, when you add a new component, you have to add it to declarations in the NgModule, and if that component wants to use certain directives or pipes, you have to add the appropriate import to the imports array. If you want to use dependency injection, you have to add the services to providers and so on. Now, there is a reason why this was required in the past but with Angular 14, we now get the developer preview of a new way of writing components, components without NgModules, Standalone Components. Now, developer preview means that it might change, that it's not fully stable yet and that's why you maybe don't wanna switch to this feature entirely yet but for the future of Angular, it might be a huge step forward and it might change the way we write Angular apps, making it much easier to write Angular apps. So how are Standalone Components used then? Well, let's say we wanna migrate the AppComponent to be a Standalone Component without requiring this NgModule. To make this work, we have to add a new flag to the @Component decorator configuration here, the standalone flag, and we have to set this to true. Now, I would imagine that maybe in the future, this flag goes away or is changed again but at the moment, in this developer preview with Angular 14, we have to add the flag like this. After adding this flag here, we have to add all the imports and providers that are required by that component to this component. Now, this component here doesn't need any providers but it needs some imports because I am, for example, using forms in there. Therefore, I should add the ReactiveFormsModule as a import here. So the features exposed by that built-in module can now still be used in this component. If this component would be using a bunch of other components, those components would also be added to the imports array here. So there is no declarations array which we add here, as we have it in NgModule, but instead, if this component used other components, they would also be added to imports here. So imports, in the Component decorator basically specifies all the external dependencies, modules, pipes, other components, directives and whatever used by this component here. Now, after adding this flag and the dependencies of a component to the component, you can get rid of the module that existed for this component. In this case, the AppModule file and now since this was the AppModule, our root module for the root component, we also have to bootstrap the application differently. Instead of bootstrapping it like this, as we did it in the past, we now get rid of this AppModule import here and we bootstrap by calling bootstrapApplication, which is imported from @angular/platform-browser. We can get rid of the platform-browser-dynamic import here. bootstrapApplication's a function, which is called and to this function, we now pass the root component of our application, in this case, the AppComponent, which therefore also has to be imported from the AppComponent file. This is how we now bootstrap our application if our root component is a Standalone Component. And as a side note, you don't have to migrate all your components to Standalone Components. If you have an application where you wanna try this feature, you can mix and match Standalone Components with modules just as needed. And again, it is in developer preview anyways, so we'll have to see how this feature evolves and which patterns will evolve. With that, however, we're bootstrapping this. And if we now run ng serve again, this application will be bundled up and we can still visit it in the browser, use it as we did before, submit this and have this app work. At the point of time I'm recording this video, I'm getting some errors here in the HTML template because my extension, my VS Code extension doesn't yet understand what this component has access to the Reactive Forms module but it should only be a matter of time until this goes away. Technically, this code is correct and this is how you can use Standalone Components to make your components more independent and get rid FormGroup a bunch of boilerplate code. Now, this is one of the features I'm personally most excited about because this has, as mentioned before, the potential of making Angular apps much simpler and getting rid of a lot of unnecessary or extra code, which we had to write in the past. I wanna emphasize again that it in developer preview, so we'll have to see how it evolves and what this means for the future of Angular but it has great potential. And that's it for the two most exiting features Angular 14 has to offer. Typed Forms can help us make our code safer and catch errors earlier. Migrating should be easy because you can go back to the old forms until you're ready and you only have to add a bunch of typed notations and fix some errors you might have in your code whilst migrating. Now, Standalone Components are not fully there yet. It's in preview, and the feature might still change in certain aspects and some code might change, so it's not something I would recommend using for all your components and all your applications yet but as mentioned, it is a feature I'm super excited about and it has the potential of making Angular way more awesome and allowing us to build way leaner Angular apps in the future. So I'm super happy to see this and I'm very excited to see how that will push Angular forward. Now, what does this mean for your apps and for my course in case you're taking that? Well, your apps should be easy to update. You don't have to use Standalone Components and maybe you shouldn't yet for all your components. It is a feature you should play around with, not necessarily migrate everything to. And for Typed Forms, as mentioned, updating should be fairly easy and it will help you make your code safer and you can go to the untyped formed for the time you need to be ready to update if you don't wanna update just yet. So updating shouldn't be too hard. Now, when it comes to my course, that course is still teaching you the latest version of Angular because the main syntax has not changed. Now, I will definitely keep a close eye on Standalone Components because I, of course, do plan to update this course and bring it up to date with this amazing new feature once it is stable and once it's clear whether that really is the way forward when it comes to building Angular applications and components. Maybe in the future we only only build Angular apps with Standalone Components and we don't really need Angular modules at all anymore. It's too early to tell but I'll keep an eye on that and of course, I'll make sure that my course stays updated and you'll learn the latest version of Angular with the course, and you learn the correct way of writing Angular apps.
