Video details

Nir Kaufman - Practices for the 21st Century Angular Developer | AngularUP 2021


Practices for the 21st Century Angular Developer "The Angular framework is usually associated with large-scale, enterprise systems. While Angular is certainly built for the task - you don't necessarily need everything Angular has to offer.

The simple truth is: It's easier to add complexity - but much harder to simplify complex applications once implemented. In this session we will learn how to use Angular as little as needed, and why there are no such a thing as ""bad practice""." Nir Kaufman -
Front End Guild Lead, Next Insurance.


Good morning. This time you're going to hear my broken English as the keynote speaker. But at the end of my session, I'm going to say if you worked in Hebrew, because I've got something very important to tell you and I don't want the English speakers to understand. I think that's my first in person conference since 2019 started. So it's cool. It's nice to see a lot of you here. The title for my talk is Practices for Angular Developers, the 21 century version. I don't know, whatever. And for this stock, I've got a message. I prepare this talk. Not to be super technical, but I want to share with you my perspective working with Angular for almost eleven years. And if there's one thing that I would like to take from my talk, from this talk is this message, guys, there are no bad practices. Now. I've got something like 30 minutes, 35 minutes. So I'll try to convince you or you know what not to convince you to show you and try to open your mind. All right. So open your mind. And today we're going to rethink Angular. Yeah, that's me. 20 kilowatt. But that's me. That's my picture. You can visit my small website if you like. I don't know if you like titles. I've got a bunch of them. You can find them there. I'm leading the front and Guild of Next Insurance. We are proud to support and be part of the sponsors in this conference. So come over, say Hi, and we've got some cool surprises for you. And, of course, beer. Yeah. So like I already told you, I'm in a long time relationship with Angular started in 2010, which means that I think eleven years. I've been working with Angular since AngularJS on a daily basis as a developer, consultant, trainer, you name it. So after ten years, after a decade, I think I've got my own opinions, and that's what I'm here to share with you. So the Angular framework, I think the advantage of Angular is its biggest weakness because we want to keep things simple. And Angular is like build for the enterprise. I think that each one of you already associates Angular with enterprise complicated applications. I would like to share with you who's familiar with Ruby on Rails, who heard about it, a very popular framework. And this is a quote from their docs. Ruby on Reals is a framework that's based on conventions. The base assumption is that we are not special and we are not unique. And I've been working with hundreds of projects during these years, and I can tell you that basically all of us building pretty much the same thing. But Angular is not built upon conventions. Every time today when you start an Angular project, you're probably selecting some defaults. We can argue about it, but it's NX mono repo because it's a very advanced workspace and Ngriks, and we're going to start a fresh new Angular project and we're going to bring everything in. Why? Because our system is going to be complex in the future. So let's do how we say it in Hebrew. I don't know how to translate it into English. A preparation for air conditioning. Now, I want to show you something. All right. Basic, true story. Anyone here ever actually read the style guide on the website? No. Yeah, five people. So on the website, there is a style guide. And one of the best practices is never do like elastic input and output. If you're not sure exactly what it is, here it is. This is Angular website. Read the docs. It's going to solve you a lot of problems. And they say, like, this is a very bad practice and they've got like a very good reason for this. You've got an input. If you've got an input, don't rename it. All right, that's not cool. But if you look closely, you'll find this in the Angular source code. So wait a second. You tell us that this is a very bad practice. You shouldn't do it. It's part of the style guide. Like, you convinced me. But you're doing it because it makes sense. So what I'm trying to say, and that's the first message before we jump into the actual practices is Best practices. Best practices. Now, I think today there are no better best practices. There are like trade offs choices you make based on. Based on knowledge. Cool. That's the dirty secret of Angular source code. I found at least five best practices that they written on the style guide that they're actually using the other things. All right, let's get started. Very important talk. Who've seen this YouTube talk? Not too many people watch it. I'm going to share this slide with you. This is the introduction of React. All right, 2015, I think. But in this talk, this guy is challenging everything we knew about building a single page applications, specifically the MVVM style architecture, and introduced React and React solution for this. It evolved to React and Flux and it affects Angular as well. And the whole front end scene. Since then, if I say the word, the dirty word MVVM, I'm not cool anymore. Because, come on, it's component architecture is the store Redux, push, blah, blah, blah. And what I like to tell you guys is that these design patterns are useful and relevant and being used today in other frameworks, in other technologies. I think Android still using the MVP, the Motor view presenter pattern. So just because we've got component and we introduced Redux and all this buzzing around doesn't mean that we should forget some basic core design patterns that might solve our problem. So some classic slide. I used to show this slide when I used to teach AngularJS back in 2011. So that's my first practice. And my first practice is Challenge Yourself. This is a demo project that I prepared for you just to show you that if you do choose to implement a classic design pattern like the NVM, nothing bad will happen. It doesn't mean that just because today it's very popular to build Angular around libraries and lazy, loaded feature modules that all connect to the store. It doesn't mean that we can't build something, which is, you know what for my opinion is simple. And for most use cases, that's probably the design pattern that I'm going to choose. And today at next, at one of our complex system, we rewrite implementing the MVVM design pattern with Angular. And that's cool. We're going to come back to this in a second. All right. So my first practice is don't forget about important, classic, useful UI design patterns that have been there for a while. It's battle proof. And it doesn't mean that just because you're using Angular, you should forget about them. Less Ng modules. The most popular question, and I've been in this. I mean, how many types of modules do you know? Like, we've got the shared model, the app model, the routing model, the feature model, and in the community, we always talk about it. Hey, what do you think is considered to be the best practice? And I've been there myself. I help people to understand how to construct their Angular application around Angular modules, a bunch of Angular modules and manage dependencies. But what would happen if we use just one module? Get off the stage? What will happen if we'll challenge ourselves? We are going have one entry point. And you know what? I'm going to do something even more radical, a simple entry point for my old app. And I even going to write my app component in line above the engine module that contains just a router router because that's all I need and everything is going to be part of this module. So, yeah, bundle size. All right. Most cases excuse me, share module, maybe my message to you guys is this. I think the practice that we should practice today start with few modules. Don't be radical. Don't build your entire app on top of one Angular module. Use less modules because it's easier to add Angular modules. It's harder to reduce it. So if you by default generating modules, I think most of you already know it. You started to get lost, and eventually every module is Loading the other module and you've got like a whole bunch of Angular modules. And guess what? Guess what? You already heard the rumor that Angular 13, we're going to get rid of the mortgage is going to be optional. So even the Angular team understand that we should think a little bit different about this thing. So less modules and less Zon JS, because Zon JS is the source of all evil. And we should look around we should look around at other solutions like this popular library. You might hear about it. It's called React, and it doesn't really matter that there are other frameworks that are doing the same trick. In React. This is a snippet. If you never saw a React code, this is how a component looked like. But the most important line is the function add. You see, React won't trigger any change detection cycle unless you change the value. But Angular, let's do something nice. Let's go to my Playground component and let me ask you this. If I create a button, if I create a button, let's implement do check just so we can do all right, because I'm trying to. Let's do a console log checked. This is how you write checked in Swedish. This is my second language. Sorry, let me switch back to plain English. All right. And here's our app. And here's the console log. And a bunch of errors, because the app module is not doing anything important. I just did this, which is very bad. Don't do it. Never. All right. And I go to the playground. Here's my playground. And here's, check. You can see it here. And if you create a button like this, click and you implement a new function that's not going to do anything, change detection going to trigger. Yes, of course. Why? Because change detection in Angular is event driven. And if we're going to do something like this, if we come here and do this, implement in it. Come on. Because I'm using this. All right. You want to do it like this? No problem. Let's take the hard way. Come on. All right. Here you go. Ng. If we do a set time out, what's going to happen? Set timeout that doesn't do anything, change detection is going to trigger. Yes. And if we do an Http request that doesn't do anything, change detection is going to trigger. Yes. So my practice, if you're starting a project from zero from scratch, no engine zone. But I want to be practical. I don't want to be radical. All right. So if you're not familiar with the following techniques, you can include a file called zone. Flags. And you can just disable timers, for example. So you can fine tune zone. Js and say, all right, that's fine. I like Zon. Js to trigger when I click, when I've got, I don't know, some kind of events. Different events, request animation frame. Maybe not. It doesn't matter. But you can fine tune zone. Js to ignore specific events and take control. So if you got a set time out, but you don't want to run change detection, switch it off. So my practice would be start with no zone. Js if you can. But if you want to get practical, you've already got a system up and running fine tune zone. Js. Get familiar with this feature zone. Flags, and just make sure that you know exactly which event is going to trigger. Zone. Js. So the practice is less zone. Js. All right. Modular Angular. Sometimes we forget that Angular is modular, which means it's built from different modules, and it's okay to replace these modules with something else. Just because we've got Http client, for example, doesn't mean that we can't do something like this and use Fetch and use Promises. There's nothing wrong with Promises because we've got RxJS and reactive programming. It's amazing. It doesn't completely mean automatically means the Promises are bad and we shouldn't use them anymore. Promises. The feature is built in JavaScript. It's got less complicated syntax. Maybe because reactive programming is hard. What I'm trying to say, guys, it's okay to use Promises and to convince you most of the important features in Angular walk with Promises. This is a snippet from the source code of Validator, which support Promise or Observable. So you can choose this is the Async pipe. The Async pipe support Promises. That's fine. If you decided to use a Promise, Async pipe going to work. That's not an issue. It's not deprecated. This is the can activated. This is the router guard. It walks with Promises. So it's important to us to remember that, first of all, there is nothing wrong with Promises just because we've got RxJS. Rxjs is an amazing, powerful tool. You don't have to use it everywhere, so use it where you need it. And if you choose not to use it, you can still build Reactive UI using Promises. If you find it more simple to use football for the Use case, you won't lose too much of Angular. Cool, guys. Promises are not your enemy. And the last one that's going to summarize. How much time do I get? I don't have any timer. No one knows. Five minutes, ten minutes. Dome Manipulation my favorite bed practice. Never manipulate the Dome. You learn Angular. That's the first thing you learn. Dome manipulation is bad. Don't do it. If you want to manipulate the Dom directly, use the renderer, use Angular API, use whatever. But that's nice to say. In reality, we have to manipulate the Dom. The most popular library is manipulated on directly primeg the CDK. The renderer API is limited. And yes, we are talking about practices. Best practices, best practices. So if you are going to manipulate the Dom directly, you're going to be coupled to the Dom. In all of my years as an Angular developer, I can tell you that 98% of the Angular apps that I had the opportunity to be involved in running the browser. That's a web app. It's running the browser. Once you import a third party library, you're a couple to the dump, period. All right, how many of you wrote an Angular app the exact same code and used native script or universal? How many people? 12345. Super cool. Did you have some Dom manipulation? Probably. How did you deal with it? You wrap it in extra layers, but let's do something fun and let this talk get ways. End. I'm going to build the directive, and I'm going to build a directive by the book. All right, I don't know which book, but it's going to be some book. So I'm going to create an element that I'm going to save a reference to. I'm going to save a reference to a parent. I'm going to save a reference to the window now. Yeah, I know I can wrap the window and inject it from outside, but let's not deal with it for now, because I'm going to do some serious domainipulation and I want to use Angular. So I'm going to inject the element ref, because that's the way you do it. And now I think I can do yeah, elementref, and I'm going to inject his friend R, which is going to be renderer two, because two is always better than one most of the time in the constructor. This is directive. Yeah, I'm going to save the element. Going to be elementref, elementref, native element. We don't want to manipulate them directly. So we're going through the elementref, the parent, I'm going to use the renderer and I'm going to check for the parent node. I'm going to pass this element, this element, because it's a native element. And I'm going to implement two methods. What they want from it can be read only. All right, so what I'm going to do, show or like open and then hide, hide. And here it's going to be two lines of code. This window is going to be a window open, and we're going to just open a new window quickly. So it's going to look like this with let's do a with 66. Cool. So this window is window now. It's telling me it can be now, blah, blah, blah. And all of this TypeScript that we like. And eventually this renderer, we're going to do append child and we're going to append to this window. We're going to append this element. If you're familiar with Angular enough, you know where I'm going with this. Eventually when you hide, it's going to be a penchant, but this is going to be this parent and this element and this window, we're going to close and that's it. So this is a very interesting directive, this window. All right, very interesting directive. I called it portable and I exported this portal, and if I hit my playground, we're going to use it. There is a very nice counter here, you see, just to show you change detection works. And on this Div, I'm going to use my directive portable. I'm going to save a reference for it. Portal equals portal, because I want to call these methods from here. So let me just create two buttons quickly. Open and this is going to be returned. I'm just going to call this portal directly. Portal open and portal hide. Let's see what we've got. So this is my counter. I'm going to do an open. I'm going to send it to a new window. Parent append child is not a function, of course, live coding. Parent append. Child is not a function. Do you see it? Where someone? Where is it? Which line? Which line? 22. Thank you. 22. Append child. This window, document, body. Yeah, who said it? I've got a job offer for you. We need people like you in our team. All right, so let's do open now, we opened it up in a completely different window. All right. Edit still works. Change detection still works. And we're going to return it and it's still keeping the state. So I just manipulate the Dome in a very brutal way. I destroyed it completely. All right. The reason that I did it is because I know that there are two kind of trees in Angular. The logical tree and the renderer view, and the logical tree stay intact. And I didn't broke the logical tree. I just manipulate the render tree. It's too short. But if you want to learn more, there is a meetup coming up with a workshop on this one. But this is not enough because you can say, well, this demonstration is cool. You just show us how you created a fresh new Dome and Angular steel works. But we're talking about direct Dome manipulation. So what's going to happen if we're going to do old school, we're going to do an ID card, we're going to go to the portal. And you know what? There is no Angular. Let's take this and just remove any sign of Angular here. Instead of this, I'm going to document. Who remembers document, getelement by ID. Yeah, we're going to do a card. All right, I'm going to ignore the typing now because I'm short in time and I want to make a point and push to production. The parent gonna be this element solve all the problem. Parent. Alright. And we don't need all of this. We're going to do a vanilla the worst, like the bed practice ever. A penchild. If you see any Angular here, let me know. Yeah, we're done this parent, a penchild and this element. So the point that I'm trying to prove is, if I'm going to skip Angular API, am I going to break everything like they promised? If you do direct domainipulation, bad things going to happen. Let's give it a try. Counter still works completely new Dome still works. So change detection intact. Angular still in control. I've got the state management. I can return it here almost. But that's because of me. I'm defined of reading a penchant, cannot read properties of undefined in line 20. We can fix this parent, a penchant of this element. And what do you want from me here? Thank you. All right. And Angular still works and everything intact. Now, what I'm trying to say is this, we have to manipulate them directly. Everyone does it, even Angular material and prime and G. It's okay if you know how Angular works. And once you understand that you can directly manipulate the Dom because you're building a web app and that's fine. It's going to run on the web. All right, don't start with me so you can do basically whatever you want. Let's summarize it's easy to add complexity. It's hard to reduce it. Practices for angular developer 21st century start simple few modules as possible. No zone JS or shut it down with flags. Start with promises if you don't have to there is no advantage or your screens are pretty much simple. Consider to implement a known design pattern like MVC or mvvn. This is not a bad thing. All right, start simple use as much angular as you need because angular is modular. It's built for it. But we lost it. All of us. Me too. All right, we lost it. Every angular project now is microfrontance on top of mono repos with ngricks that lazy load libraries into feature models that transport themselves into bundle size which are cool things but not all of us build the enterprise and even the enterprise doesn't have to be complex. There are no bad practices. Guys challenge questions. Don't believe anyone. Don't believe me always a question I'm done but before I get off the stage I want to say a few words in Hebrew Shalom if you like to argue with me about anything that you just see all these bad practices if you want to come to my booth and tell me no you're more than welcome more than welcome this is my opinion eleven years rectangular some conclusions and I've got some whiskey for you. Enjoy this conference. Thank you again and that's it. Yeah.