Learning Approaches for Angular


I'll start off by introducing Ben Hofferber. He is a wonderful man who moved to Toronto five years ago now and has been working with me at Rangle since then. We've become fast friends. We live in the same building. We are, uh, just talking a lot, so we figured why not talk and have it be recorded so that it's more useful.


Yeah. And that wonderful voice you just heard is, Abdella Ali, uh, he's been at Rangle forever. There's I think only the founders have been here longer. Which is Nick at this point. And, uh, Della's fantastic. We worked on a number of projects together. Um, and yeah, like you said, we're I'm often talking about these things anyway, so figured it'd be great to record it.

The History of the Angular Learning Journey

So today we were thinking about learning angular and really like the learning journey for new people coming into the industry, people who, Hey, you know, you're starting at your first job or you're trying to get in, what does it look like to learn something like angular?


Learning Angular is actually quite interesting. I feel like this, again, some, some history here that's intriguing. Back in the day when Angular was Angular 1 and it was on its way to Angular 2 it was going to be a significant shift in how it was written. There's a lot of lessons learned from Angular 1. What ended up happening is that when Angular came out, they did enough of these really interesting, useful things that I think that the majority of people used it.

Going to Angular 2, there was some important considerations. Number one, angler wanted to maintain some core connection between Angular one and two. The simplest example is two-way data binding. This is actually very contentious at the time. React had just actually started to come out right before Angular came out. I think it was like a year before and they were like "2-way binding is not great". Um, and you know, there's maybe a lot people who felt the same way even in the Angular community.

And there were tools in Angular 1 that allowed you to kind of write around that, you know, like if you use the component architecture or even just the older directives that specified the way the inputs relate to each other, you could say like "equal ampersand" and that all told you how you pass data between components, parent, and child. And you can say always one way databinding, if you want it to. React is like, "yeah, that should be the default and that just should be the way it's done" because they were reactive functional programming. Right. And that's, you know, unidirectional. Thats idemopotent and all these fun, fancy words.


If you wanted that two way, you had to set up that listener or you had to set up the handlers.


Yeah you have to make it happen. Right. Angular was like, no, no. Out of the box, we went 2-way databinding. Um, and I think that actually was tied to the learning journey for them. They didn't want somebody to come in and learn angular two and have to learn a fundamentally different architectural style than Angular one, number one. And number two, just generally less popular architectural style back then. Back then, functional programming wasn't a big thing in JavaScript. You didn't have filter map and reduce I don't think, or if it did, it was just coming out and before that it was polyfills.

You didn't have these like long like articles and essays and guides and how to write everything functioning reactive. You still didn't have this like huge ecosystem of this. You had people who were really into it and people who weren't.

So Angular was like, you know what? We're going to support everybody. Where people who want to be reactive. You have RxJS. You can do on push change detection. You can create this entire system where data flows from top to bottom unidirectionally.

Getting Started

You went through a great job with the history and thinking through all the pieces that made Angular. So if I'm somebody new and I'm coming in, what does the learning journey look like now? Now that we've got all these systems in place, now that we've got all these libraries that we're using, I'm somebody new I'm coming in. What do I need?


Yeah. I mean, that's a good question. And I'll say you have two options and two paths, and that path really depends on how supportive of older architectures you want to be or how forward thinking you want to be.

Learning as an Experienced Developer

You can kind of see there are some big changes in how you can write angular but the problem with this is that there's no tutorials, very little documentation and very little stackoverflow questions for you to peruse and figure out why your things aren't working. If you are somebody who's brave enough or experienced enough or crazy enough, jumping to the new stuff, I'd say right away, look into how you can write a modularly federated Angular application and this is assuming you're, you're very experienced. Look into Standalone angular components, uh, look into the type forms and, and utilizing TypeScript to its full extent is really important.

There are so many things that are available that just in TypeScript, I think people underestimate even that in terms of power. Really taking advantage of all those things and mastering those things on top of RxJS will give you a suite of foundational pieces that you can build a really good Angular Application on. Then you have to learn about the architecture, and deemphasis on Angular modules you might be able to write your own idea of what that looks like. What is a good architecture in the world where modules don't need to be connected to components, right?


Because this is new now at this point even right now, standalone companies are still in beta, but with this new architecture change suddenly okay. Like things look a little bit different than they had prior. Exactly. and right now it's a little bit open in terms of what that looks like.


Yeah. If you're somebody who's really experienced in development and you were coming from other ecosystems, maybe Vue maybe React and you're like, "I want to come in and learn Angular now." Take your time to really spend some time, of course, on the older way, but really master the new way to, and that could be a strength, you know?

Everybody's always trying to do things better. And if you come in saying, I already know how to do better things, in fact here's a repository where I've done it the best possible way. You're going to have a mic up to your mouth nonstop and you'll have to talk a lot. But you might be into that, so, horay.


So we've kind of flushed out like the initial pieces that are really important for getting started and learning. What are the pieces that are like the gotchas? Ah, right.

Cause what often happens is you get architects they're in, maybe they've really never coded a large-scale application before but they've done a lot of tools, right? Like I know internal tools are often built with like, you know, any of these frameworks. Right. But now suddenly you're building a large app, you've got multiple teams running and you're trying to learn to be able to support that. What are the kinds of gotchas that fall in there?


Well, I'll say one of the biggest gotchas is that if you don't do things in the best possible way, performance will run away from you. I'll give you a really good example. So let's assume you have an Angular component and it does not have on push change detection. On push is all about that unidirectional data flow I was talking about earlier really saying only care about updating the component if the inputs change and also other things like the observables inside the component. But if the inputs change, then I know I should rerender, right.

Otherwise what's gonna happen is, there's no virtual Dom, like there is in react. It doesn't really know when things change. It has to check. It has its own tools internally that's kind of similar to virtual DOMs. It has his own like, you know, functionality, but one of the ways he does it is something called dirty checking where it will run every N amount of times per second.

It's just checking basically all the things that it thinks are relevant fields and does a comparison and, for emphasis a triple equals comparison. Right? So Objects Arrays, careful with those.


And be very careful with, uh, functions, being evaluation loops right? Because if you're saying, Hey, NgIf, this function's success, that function is going to run multiple times a second.


Exactly. Right, right away. This is one of the first things that people often have trouble with. Especially if you come from a react background because react, you write functions right in the template. No problem. But React isn't doing the same thing, really when it renders. It's very different. Angular is a template up approach where the template informs everything else. React is kind of a template as the last piece of the chain, this puzzle.


It's a big renderer.


Yeah, exactly. What ends up happening is people will put functions in their components and sometimes it's not very painful. But let's kind of paint a picture of a really painful encounter.

You have a little cute card and in there you have a couple of like functions in the template, to update the values, it's always checking to see if this thing has changed in our state update the value, uh, and maybe the data comes in as a JSON string for some weird reason, or you did some sort of JSON stringify and parsing and bringing it back for whatever reason. I'm just bringing up there just to give you an example.

And let's say, it's not on pushed change detection, it's running this. And even that might give you a little bit of a performance slowdown if you took the profiler, but you might not really notice it because what's happening is whenever you scroll the page, whenever you click on a button on the page, whenever you do any interaction, or whenever an API request is this triggering in the background, Angular dirty checking is saying, well, these are events that I have to check for. It'll be very, very noisy if you're scrolling the page then, because it's like a scroll is a as a stream of events actually.

And all those events, it's triggering me to check the, see them changed and rerendering and firing and the template and the function where I'm doing the parsing from JSON back and forth. It's actually a very expensive function. If you ever do a check and profiling on something like that you'll often see it at the top of the list, especially if you don't just have one you have, uh, an array of them. You have a grid of them, and they're all sitting at once. You will notice that for every additional one you add in every additional role you add in, you'll see a significant slowdown and all because you're trying to use it the way you use react.

The thing to remember is there are tools out of the box that help you with this. Simplest one off the bat is on push change detection. Yeah, you do that. And it'll significantly reduce the amount of calls that are happening. It may not go to all of them because the inputs might actually be updating. But it would be much, much less.

This is the thing that's really hard for us to learn about Angular is that your performance improvements have many different opportunities in terms of how they can impact your application as a whole, and if you let Angular, you can do it out of the box it's own way, you run risk of quite the performance overhead.

Angular Life Cycles

Yeah. The one I was thinking about, the kind of other gotcha that, that I've seen teams run into a lot is managing logic related to life cycles. So you have an application and it initially loads, and you notice that initial load time slows down, or there are bugs with that initial load time that depend on like a myriad of things, right?

Whether the user's logged in, whether the API calls are succeeding or whether error handling is in the right place or it could be the type of user that logged in at a certain point. That initial state of the application loading, especially if you allow a user to load right to a page, can get very complicated and very tricky.

Not only that, but because angular gives you all of these little hooks on the way in, you can have that one logic set spread across your entire application. So that at some point you're working in like five different files to do the same kind of three things and you might actually find that, oh, I'm actually repeating the same action multiple times.

Like I'm checking login like three different times just because I'm not sure when each of these is going to come in and that's a perfect place when we start to see that, where we do look at observables and we look at RxJS and we look at, okay, what are the different states that need to exist? What are the different flows that we need?

How can we build those into its effects, and then you got a direct idea of like, okay. App initialized and initialized for this user


We often try to make components, I think, much more robust and interactive and they need to be, um, and people jam, pack everything into them unnecessarily sometimes. And what end's up happening is you end up creating, one: very brittle components. And I mean brittle because, um, I'll give you an example. You use a user really nice those level card, right? Instead of each card, um, you specify I'm going to make an API request to this end point to get the data for flights and then do a filter on the one that was troubling to me, for whatever reason, um, you know, have all these cards that are doing way, way too much information.

They're making the API request themselves. Right. They're taking it down , they're doing change detection. So like crazy what these cards should be a little tiny little cute cards should just have the name of the flight. So the status of the flight and the color changed depending on the status and a link to click on.


You don't want, like if I've got a filter on these, that whenever I change that filter now, you're making a whole new set of API calls that you don't need to. You can't cache them...


and then you've got to manage state between the two things as well...


it gets to be a challenge. Yeah.


Just pass the data down. We can argue about what components are, should be smart and stupid and that's as a fun argument, but this is a pretty straightforward example of don't over-engineer a component and make it too, too much avoid if you can't actually using lifecycle hooks. Here's my hot take. I hate ngOnChanges. Yeah. I hate it. You know, it seems good in theory. And then it always is where bugs are in every application every single time.

I'm really a stickler. I really love making as many things dumb as possible. You don't have to be that way, but really ask yourself, does this component benefit from this additional information and logic and all these additional checks and effects, or would be better to give this to its parent and have the parent tell it, right. I think you'd be surprised at how much the latter is true.


I think that this gives us a good feel for two things. So we've got, we've got one thing, which was as a new architect coming in now you've got a feel for what are the fundamental pieces that you need to understand in order to just work with angular and I think we've given you kind of a taste of like, where is the complexity? What do you need to actually be thinking about? Largely it's performance. Largely it's APIs. How do you manage that logic at that large scale?

Learning Angular for New Developers

So now kind of shifting gears. If I'm somebody new coming in to angular and I'm not an experienced developer, I am not used to building web apps. Maybe even, you know, JavaScript: little shaky. What does learning Angular look like for me.


Well, that's a good question. I'd say that when you're brand new to development and Angular and all of these things at once, angular can be overwhelming because it's like learning a language on top of a language, right? You have to learn so many things that seem either very intuitive, you might even say too intuitive to you, or things that are very, un-intuitive.

An example of something that's maybe too intuitive for you is the template different impact and the way that Angular works. It makes actually a lot of sense, especially if you're coming from the, let's say pure HTML and background, like, "oh, I know all these things. I know tags. I understand attributes. I can kind of map this to what I know pretty well. But a reason why that can be complicated it is because you'll see things that are weird and like the ngFor or directives or switch cases that are on templates.

And that can be kind of jarring. It can be very much like, an uncanny valley, like, you know, like "this HTML is slightly off." Other frameworks often have this problem as well, depending on what framework it is or not at all, because they shoo being too much like HTML and there's pros and cons for that. But really the thing to learn first and foremost is that the Angular template while it looks a lot like a template, and HTML generally, has some very big differences.

Treat Components as Elements

A simple thing to remember is that Angular components are their own elements. And this is a very common early on mistake. You make an element, you call it " myHeroCard", um, component, right? You call it and the actual selector of it "my-hero-card". What that means is there's going to be an actual element on the page called myHeroCard, an actual like div or span whatever your going to call it with its own space in the HTML.

And what you put in the template is also going to live inside of it. And I can not tell you how many times people unnecessarily then put a div as a parent in that template and how much problem that causes. You don't want that. Don't...


Don't have a wrapping component around the contents of your components.


Exactly. Treat the component as a whole, as a wrapper. I know React doesn't that. And this is, again, something that confuses people, um, react, the component actually disappears when it renders and in Angular, the component becomes real when it renders and you have to make sure you interact with the well, and you can actually even do things as referencing the host.

So if you're new, really understand the relationship between the component parents and the template itself and if you respect that really well, you already have a leg up. Um, I think for initial learners, that's a very common problem that they would have. Yeah. Yeah.


And people try and solve it with a lot of different CSS hacks too. So I think a lot of times when you're thinking this element has to be inside of this other element, and you're trying to get around some of these things, sometimes you're like duplicating CSS to be able to, make it happen, or you get


pass down classes to be put into the child's internal wrapper. Right. You're trying to do a thing where I make this thing a Flexbox. So you have the hero card and I'm the hero card to say class flex, or you say style flex, whatever it is. Right. But it's not flexing unless, because the div inside of that, isn't Flexbox right. So it's like, well, how do I make it a flex in this case and not if that's in that case? I'll give a prop and pass it in. What you learned is that the only problem really here is that you've wrapped things twice.

In general in JavaScript, HTML, and web development, unnecessarily wrapping things is one of those sneaky things that people think isn't a big deal and it isn't a big deal. Every additional wrapper you've removed from an application. If you think about this as O(N) complexity, it's kinda like playing into O(N) complexity reduction, right.


That's one more div that could come up whenever a styles are being evaluated. That's one more div, that comes up when you're looking at layouts and re rendering the page. That's one more div of that comes up when you're doing paints, you know, it's, uh, yeah.


Every time you can remove a div or a wrapper or any of that, you're in the right direction. I think you, you have sometimes do it. You have to wrap things of course, but do it when you have to, not because you think you're supposed to, that's the big difference.

Inputs to Components

I'd say with Angular another thing to learn for really new is really trying to understand what it means to pass inputs in to the components and how it's kind of different than somethings that are out there. A great example is one of my favorite things to learn and to, to work with is using input setters. Input setters are actually one way I often work around recurrence in ngOnChanges that I talked about earlier. On inputs that are just basically saying " this input, isn't just gonna be a property that I listened to and then pass in my template. I want to react to that changing whenever it changes it to a very specific thing.

Normally the ngOnChanges and then you say, great look at all the changes find the one I care about and do a thing, but I think it's firing constantly, right? It's firing whenever any change happens. And so that thing has to also be guarded and say only change when this input changes. And so that's where a lot of pain comes in.

But input setters gets around that, you're saying literally I have a function that's fired when the input changes. And in there I can do a check. I can do some logic. I can update something else. You have a lot of power. It's mostly a pretty safe bet. It doesn't work very well with some tests.

I would say for anybody who's new and wants to write tests for Angular, start by avoiding test bed. Yes. Getting on to TestBed later on if you need to, but you can avoid it right away off the bat and just literally test creating a class, passing in mock dependencies. Right. And just trying something very simple outs.

Yeah. And building off of that. And then in times working with TestBed can be very useful. And, the reason why I say it's even less relevant going forward is that the entire concept of modules is less relevant going forward and TestBed basically, just a fake module rubric. Right. Right. So what's that look like when tests, when components are on their own.

Understanding Templates

So, okay. We've kind of started out talking about how new developers need to start with templates and we talked through that space a little bit. We talked through like, now once they're learning and they're on this path, what's the next steps. But I don't know if we maybe fully flushed out the top. Right.


So I say, let's say you learn templates, so you just have to do an ngFor in there. You understand to pass data down into template in the right way. You use ngIf. Master ngFor and ngIf and that can cover you for quite a few different scenarios.

Use ngif when you can, instead of using display none because NgIf actually removes the element from the page. Right. Whereas display none does not, which can be a big difference if you were moving these another component, for example, and NgIf will not render it. And that code will not fire and display none, it's still there. Technically you just can't see it.

So be aware of those differences and take advantage of them to the best of your ability. Um, but eventually you get to a point point where like, you know what, I kinda gotta handle this. Let's go a little more advanced, um, because that's great for a component or too quick for a dummy application, but then you get to state management.

This is when I think it's time for you to start playing around with NgRx okay.


Even before this though, is there a place so like, so, so if I'm somebody who's new to even JavaScript. I understand now templates, right. I can kind of understand a little bit of the logic that's happening. I can look at the template and understand probably how to style some things, how to change some of the code to make some things happen. I'm playing with stuff and I get that piece, but there's this other side of it. That's the rest of the code, right?


The TypeScript file.


The TypeScript file Yeah.


Yeah, yeah. That's a really interesting part of the application too. The first thing we'll notice in that component that you have associated with that template is the decorator, the @Component decorator, I remember this time and decorators were going to be this big deal. And then everyone's like, you know what? No, no. Yeah. They're not really used very much anymore. They're still around, but they kind of fall in a little bit of fashion without a favor.


They're really challenging to write TypeScript for.


Exactly. Probably it's a pain in the butt. Yeah. So don't get too hung up on the decorator. Okay. Dont' get hung up on the @Component thingy. He spent some time learning about it, but honestly you just learn the bare minimum as to how to interact with it, to get what you want, selector, styleUrl, or style URLs, template URL. And that covers you and on push change.


And maybe a little bit of what do the different scoped CSS things do.


Yes, of course. There's the, um, was it transcluded yeah, basically the idea is that, um, CSS is pretty encapsulating the component by default, but you may not want it to be, um, and you can specify with some rules to say, actually, any classes that are defined above, can you pass down? And these are kind of, these classes are basically global if you really want to go down that path.

Good spend time on that, but don't get too worked up on how. How the decorator works. Don't try to master that. Don't try to like make your own, you can, if you're really curious. And I always encourage people who are curious, going down that path, but if you're suddenly at 2:00 AM trying to make a decorative work or you're thinking, I need to learn this to really master angular and you have sweat run down your face and you're exhausted and your eyes are kind of all bloodshot. Put it down. Close the lid of your computer walk away from decorators and jump into the constructor.

Constructors and Injection

The constructor is more important to understand. The constructor and dependency injection is quite complicated. If you're very new to JavaScript and new to development, this is a big confusing point because it doesn't work like most constructors work. You're like really passing in parameters by defining them as expectations. Normally, you don't do that, right?

You call the fucntion, which is a class in this case, and you pass what you want into it? But here you're saying I'm not calling this component. Something else is calling it. If I just give it, if I just define what I want here it'll pass the right thing down for me.


It'll just exist magically. Yeah.


It's really weird. And it's not even proper because you also have to make sure you have it imported in the module, unless you're using forRoot if it's a service. It's not as strict as we'd like it to be. So I'd say really spend time on DI, dependency injection. It's a complicated thing. That I think has fallen out of favor, as we move towards a world in which imports and exports in files live and breathe and are normal, they weren't five years ago.

No, they weren't three years ago. Um, but now there are.


And the unfortunate thing is you're now in this world where there's going to be both for awhile here.


Exactly. You're going to see imports on the top of the page and you're gonna see DI in your constructor. So learn how that works, understand how to like, you know, like short hands, like something private.

It's a nice, easy shorthand to not have to then also in the constructor assigned to a variable. Know the difference between a private and public one. If it's public, it can be used in the template. That's a newer thing in Angular I think it was from like Angular 6. If it's private, it can't be and it can be accessed even outside of the class. Knowing all these things and using them right is that, is, that is a very beneficial thing.

Lifecycle Hooks

And then you go into lifecycle hooks.


Lifecycle Hooks are huge for components.


NgOnInit. Great example. There is a big difference between constructor and ngOnInit and I'll tell you right now what it is and you'll thank me later. When inputs are passed into the components, they are not available the first time in the constructor, but they are available in ngOnInit. Because the order of operations is constructor fires first. Inputs are bound. ngOnInit is fired.

When the constructor is fired. Inputs are not bound yet. So you can't say. Well, this dot HeroName doesn't exist.


HeroName name will not have been passed in.




You will not have access to any of the inputs that you've specified.


Yes. So in general, it is very important. I'd say get comfortable with the order of operations for lifecycle hooks. They give you a diagram on the website. You can see what everything fires and the order, they fire in, and that can really save your butt. Avoid ngOnChanges. Really stick to, I think, stick to NgOnInit and ngOnDestroy, right. Which is important if you have any loose subscribers, which I tend to avoid if possible. I love to bind to the template. And then when the template is removed, it's gone automatically, but usually there's a million things to learn. I can go on and on and on about this.


I also say too, from a, from a career growth perspective and from working with the team. It's really important to know what these are used for and how to use them. I find that, especially a lot of people who are new to the language, they want to kind of show off or show themselves and show how much they know.

And oftentimes that actually shows it comes across as like, oh, you're still learning, you know? Right. So it's actually better to know, you know, it's okay to make mistakes. It's okay to mess up. That's not, that's not what I'm saying, but I am saying like, it's good to know what these things do and using them appropriately, and also bringing it up with your team and saying, Hey, you know, I looked into this, this is actually what this is for.

We're using it in this way. What's up? Why are we using it this way? And starting those conversations. I think that that helps you better communicate with the team. It helps you learn. It helps you find out sort of what's the architecture, um, that that's kind of going on here.


We talked a little bit about new people coming into angular. We've talked a little bit about sort of like where do they start, how they go through.

There's more to say about like state management, but I think this at least gives us a good model for thinking about how. How we start.


Yeah. You have this big picture, look at Angular and see the differences between other big frameworks. And that's really, really interesting and really, really right for re-imagining, especially with the future coming in, um, you know, standalone components, the general improvements in architecture and reduction of reliance on modules, tons of really cool things you can do with that and TypeScript.

The world's your oyster. But then you also have this deeper reminder that Angular is a very specific kind of beast and learning how to navigate the templates, learning how to navigate the component itself, the, the, the class, the nature of the class that you work with all the time. Understanding the decorators and the RxJS under the hood. There's layers and layers and layers to understand.

And I would say that your best bets with any learning experience is trying to find a community of people who are either experts or also learning. Right. That's my number one advice. There's, there's going to be discord group, there's going to be a slack group, and there's going to be more than one actually. People who are learning or people who are helping people who are learning and you being with them is going to help you feel like you're less lost.

Go to the Angular discord group or slack group and throw out questions and someone there will help you out. You really need to make sure that you aren't isolating yourself too much. It's good sometimes to go off on your own to learn by yourself and play with something, write your own directive, write your own pipe by yourself. Right. But when you get stuck and when you and you look at stuff at angler, um, go back to the community, go immerse stuff with that, with those people, and you really will continue to grow and learn.


Definitely. Absolutely. And don't get too hung up on the fact that there's so much out there, there always be more. Angular even gets more complex at the higher end where there becomes like, how do you do Angular Universal, Module Federation, Angular elements.


Yeah. There's tons of these additionally abstract concepts.


Right. And, and don't get too hung up on it. No. There's way too much out there so don't feel overwhelmed by that piece.


Yeah. If you're new focus on, on the bread and butter, can I get my component to listen to data and show to them the template you're already like halfway there.


Right, exactly. And it doesn't hurt that angular is probably the highest salary for front end developers right now. So yeah, there's, there's that upside as well.


Of course, you know, whenever any language becomes, um, established and across many different industries and there's not enough developers to fulfill those needs, you're in a good position.


Exactly. Definitely. Cool. Thanks a lot Della. This was great. I think if anyone has any more questions feel free to reach out to us on Twitter or on our website.


Yeah or email, I guess that's still a thing.


I think that is still a thing. Yeah. Hahaha. Awesome. Thanks so much Della.


No Problem.


See Ya.

0:00 / 29:09