Armen, Lucas, and Subrat join this week's panelist episode to talk about Angular's "Built-in Control Flow". They begin by sharing their perspective on Angular's newest change and give an introduction to the Built-in Control Flow. Additionally, they explain its purpose and how developers can benefit from this.

    YouTube @FunOfHeuristic https://www.youtube.com/@FunOfHeuristic

    LinkedIn @ArmenVardanyan https://www.linkedin.com/in/armen-vardanyan-am/

Lucas Paganini:

Hello, welcome to Adventures in Angular, the podcast where we keep you updated on all things Angular related. This show is produced by two awesome companies, Top End Devs and Unvoid. Top End Devs is where we create top end devs who get top end pay and recognition while working on interesting problems and making meaningful community contributions. Unvoid, which offers remote design and web development services with specialization in Angular for companies that truly care about quality. In today's episode, we will talk about a controversial topic. It's a new RFC by the Angular team proposing... Oh, by the way, RFC is a request for comments. So it's a new request for comments by the Angular team proposing to bring in built-in control flow to Angular. In other words, instead of using ngif, ngfor, and ngswitch, we would have a custom template syntax for these control flow structures. But why would we want that? What are the pros? What are the cons? What are people talking? Stay tuned to find out. My name is Lucas Paganini. I'm the CEO of Unvoid and your host in the podcast. Joining me in today's episode is Armen Vardanian.

 

Armen:

So, very nice to be back on our episode.

 

Lucas Paganini:

and Subrata Mishra.

 

Subrat:

Hello everyone.

 

Lucas Paganini:

Awesome. Really good to be back. It's been a while. The past few weeks, we weren't able to find time to do the episode, but fortunately, we are back here with a new episode, and I am, for one, very, very excited about this topic. I think it brings many interesting changes into Angular, and this, it has been a momentum, right? Like, signals had just happened. And now this, like this is a big syntax change into the entire Angular language. Like it's going to change how people write every single component template. So it's a really, really big change. I was really surprised actually that the Angular team was considering to make this change because it was already so stable. Like I don't recall... colleagues of mine saying, hey, I don't like this, let's change. I think everyone was already pretty familiar with the Angular way of doing this. So I think my first question is, why change something that has been established for so long?

 

Armen:

Yeah, sure, that's a good question because I really was thinking that we should first discuss the motivations and only then talk about... You know, sometimes the motivations of the Angular team and the motivations of the wider community are not the same. But right now, the team has a very, very big and specific goal of making Angular more approachable to everyone. They want to make it more teachable, easier to explain to a beginner and so on, or for someone who's switching from another framework or whatever. And we all know Angular got this reputation of, oh, it's a big thing and it's hard to learn and so on. Which to an extent used to be true now, it's simpler even without this change. But again, I think people on the team believe that they can make it even more simple in the future. And that is the number one goal. Also to weigh in here on the situation is that apparently it has some other. benefits. So I thought the benefit of readability, which is a controversial thing to say, at this point because lots of people go around and say, oh this looks ugly and so on, but readability isn't only about being beautiful or ugly or whatever, it's about being convenient because we're working on templates, on files and so on and we want them to be more easily understandable. So we want the important things to stand out and implementation details may be hidden somewhere and we want a more singular way of doing stuff rather than different approaches and so on. This definitely will bring that to Angular. So obviously this sort of syntax will be way more noticeable on... on other than NGE for NG switch too. And it's a certain one way of doing things because with NGE, for example, there is discussion, oh, do you have to put it as the first attribute on an HTML element or you can drop it anywhere? I know lots of people just do it first because it is the most logically important one. But if you somehow do it second or third or fourth or how many attributes your element has, then you have a problem because this becomes less readable. Now I would have to search for NGEs and NGEs aren't highlighted specifically unless I have an extension or something. But Angular language service will out of the box support highlighting this syntax and it will make it more readable. More ugly, maybe, for someone, but more readable. Sometimes we make things ugly or intimidating on purpose because we want those things to be noticed. I don't know, look at the biohazard signs, right, or nuclear waste sign. It looks ugly, but it's good that it looks ugly or scary because we want people to notice them easily and discern them from their surroundings. And maybe for this, I think this will work. So yeah, that was a good bonus that the team found for it. And finally, the third important reason is, you know, this will improve bundle size because you won't have an ng-if directive or an ng-switch directive or whatever included in your package, in your final bundle because those statements will be run and compiled. into JavaScript code at compile time, and then you will just have if statements and for statements in your compiled JavaScript bundle. And that's a big benefit, that's a performance benefit. Why have all that stuff if we can just get by without it in our bundle? So those are the main motivations. I think if we go deeper, we could find some other points, but these three are the important ones. Easier.

 

Subrat:

Yeah, I would

 

Armen:

to

 

Subrat:

like to.

 

Armen:

understand, easier to read and smaller bundle size.

 

Subrat:

Yeah, I was saying I just like to add one point first thing your comparison is pretty weird like you compare if with a nuclear sign that's like yeah it's so fast that's pretty funny and the second thing what I'm thinking is like Vue, Angular and React all the companies are trying maybe talking together but it's my feeling and trying to have a similar approach as similar approach as in different frameworks because it will be easier for company to switch between frameworks. So like suppose now we have an Angular Enterprise application, it's very hard to change that to react or maybe to view. I think there are directions everyone is going. It's my feeling to just

 

Armen:

I think.

 

Subrat:

combine so that.

 

Armen:

Yeah, I think there

 

Subrat:

Yeah.

 

Armen:

is some truth to that, but

 

Subrat:

Mm-hmm.

 

Armen:

for example, you mentioned React and React isn't doing anything right now. They are moving very on the server side thing, which is cool. It has lots of capabilities like server components, client components and so on. It's a really cool thing, but it's not about the structure of the framework itself. It's more about how it can be run. Again, a great thing, but not exactly... It doesn't exactly change how we work with React, right? It's still the same code base. We just can drop it in other places. And yeah, more capabilities on that front, but not exactly how the code is written. And actually on the topic of converging on some common ground, well, if this goes... forward in Angular. Now the three big frameworks, each will have their own template syntax for doing control flow. Because Vue has directives, essentially, like Angular did with ngif

 

Subrat:

Yeah.

 

Armen:

and so on. And Angular will have this. And React will have nothing. You just write.

 

Subrat:

JavaScript.

 

Armen:

There are a bunch of ways of doing that.

 

Subrat:

Mm-hmm.

 

Armen:

Usually people do like ternary or whatever. Or you have a solid that has specific components for controlful, they have an if component, a for component, and so on. All of those are valid syntaxes. I mean, in the end of the day, whatever makes people comfortable writing and reading code. But I don't think there is any converging. Right now Angular is just going through different inspirations and saying, oh, I like this, I like that. And I like this direction because they usually pick the stuff that I personally like. For me the syntax, and when we use the word ugly, lots of people do that. It's not ugly for me, it's a bit unusual, but I came from background when I was doing back-end on Python with Django, and back then this was pretty standard syntax. It had something like you could write a curly brace and a percentage sign, right, and then you could write some Python code there. So essentially it's something like this, there's nothing new, we just... sort of circled around and came to an idea. And Svelte did that and it seemed, I don't know, good. I mean, lots of people embraced Svelte for a bunch of reasons. I don't like it that much, but it has its cool things. So this is for me, it was something that I would say it's interesting. So it won't

 

Subrat:

Yeah,

 

Armen:

be

 

Subrat:

it's

 

Armen:

bad

 

Subrat:

look

 

Armen:

if we have

 

Subrat:

good

 

Armen:

an Angular.

 

Subrat:

to me. Like it will reduce some line of code, like adding ngTemplate, for else and all. So it is two less lines. So, but.

 

Armen:

Actually, I wouldn't say, for simple examples, yes, but for more complex examples,

 

Subrat:

Yeah.

 

Armen:

like with this, you realize we can do L sieve statements as much as we want, as many as we want, and an else statement. So the idea, the code level idea here is to bring more JavaScript, like real JavaScript, yes, ECMAScript to the HTML level. And this is good news for people who do not like React, for Angular developers who do not like React. Because there are people who are like, oh, we're going directions, maybe people in the team would want to bring JSX here. I don't know, I know lots of people who are against that. I am one of those people. I find JSX kind of fun to look at, right? The opposite of ugly, but... Whenever I worked with it, it was super, super weird and so I didn't know how to manage it. And there were so many approaches that people came around it. So this is a direction opposing JSX because JSX, what is JSX? It's HTML and JavaScript. Not bad, but we need to combine them somewhere. But in essence, it brings sort of the problems that we experience with HTML into JavaScript. What Angular is doing or Svelte, for example, writes that they have this syntax is bring JavaScript to HTML. The idea is not to make JavaScript everything to everything. So JavaScript is doing CSS now, JavaScript is doing HTML now and so on. The idea is more like, Oh, why don't we make HTML that does stuff that has this? capabilities. And I don't know, as a matter of fact, this looks, essentially, at one point in the discussion on the Twitter space that we had last week about the same topic was that actually this brings Angular closer to HTML standard syntax, like valid HTML. Because essentially those curly brackets we put and so on, it's just text for HTML. If you run a component that has this template for an HTML you will probably get a normal result like, okay, this is just HTML, this is some weird text in it, rather than affecting the elements themselves. This will also solve, if we're talking about pros, this will also solve several painful concerns like you can't have two structural directives on a single element, so people either go around inventing some divs or put ng-container, which is, again, it's not bad, but, you know, now we can just, we don't even have that problem. We write if, we write for, and it's readily understandable if it's a loop inside an if statement or an if statement inside a loop. We got over this problem. We got, with this template syntax, we also, as I mentioned, would avoid all the ng-if else then. problem that we have. Again, not a big problem, but it is something that requires conscious management. So, if you are reviewing a PR, for example, and you see that someone says, ng-if condition semicolon else name of the template, you're going to look around, find the template, make sure that it is next to this element. So, this is small, but overhead. Now, you can do that. if you run if statement, the else, else if, and whatever you have there, you can have it. The for loop that we will get, we'll have an empty block, right? So you can write for some loop, and inside it you can write a empty block, we'll show that HTML in case that the array is empty, right? And it will have all the capabilities that, and you forehead. All capabilities in the template because some we're gonna talk about some cons that they have outside of the template.

 

Lucas Paganini:

I think there was a lot of interesting points brought up. So first, the part about it being unusual, if you compare with all of our previous experiences with Angular, like in the context of Angular, it is an unusual syntax. But it's a

 

Armen:

EZ!

 

Lucas Paganini:

pretty common syntax overall. Like it's pretty close to a mustache and handlebars. So it's

 

Armen:

Wait,

 

Lucas Paganini:

not

 

Armen:

but

 

Lucas Paganini:

some...

 

Armen:

is it unfamiliar for Angular? We are doing curly brackets all over our applications for interpolating data or calling functions or so on. I

 

Subrat:

Yeah,

 

Armen:

don't think

 

Subrat:

it's

 

Armen:

it's

 

Subrat:

just one curly back

 

Armen:

that otherworldly.

 

Subrat:

instead of two.

 

Armen:

Yeah, now you have just a closing block somewhere

 

Subrat:

Yeah.

 

Armen:

out

 

Lucas Paganini:

But

 

Armen:

there,

 

Lucas Paganini:

up

 

Armen:

but.

 

Lucas Paganini:

until now, there were no special... Like everything that was special in the template was in the format of a tag. So for example, even ng-container, which is a very special element because it disappears when you're actually running it, it was still written just like a regular HTML element. You used to look

 

Armen:

Which is bad.

 

Lucas Paganini:

at, which is bad, yes, but the thing is... We used to look at Angular templates and just see all of our logic inside HTML elements. So it's a shift from that because now the actual special things are gonna be with their own syntax, which I agree with you. I think this is a good thing because then you can better differentiate what is your control flow structure and what is your actual HTML to be rendered. So I actually like that, but you can't say that it's not different from what we are used to. It is different. But I don't think the syntax is difficult to grasp. It's pretty easy to get. It's a very simple syntax. It is familiar with other templating languages that most developers are familiar with, very, very close to mustache and handlebars. I really like the statement that you made about how... React kind of brings HTML to JS and Angular brings JS to HTML. I really like that. I think it was an interesting way to put it. And yeah, overall, I think that I agree with the motivations. Like for me, personally speaking, just Lucas speaking here, I like this movement. I think it's a good call. Like given the points that we discussed here, I think it makes total sense, and I think it is going to make... the code more easy to read. And as far as bringing frameworks closer to each other, I also don't think that's a real movement. I think they're still pretty apart and migrating from one to the other is still pretty hard. And I think it's gonna stay that way for a while. But one thing that I'd like to mention about bringing frameworks closer, I think what brings frameworks closer is native implementations. So I think there's a movement from all frameworks to get closer to the browser native implementation. So every time there's a proposal on TC39, is TC39? Is that, I think

 

Armen:

Yeah.

 

Lucas Paganini:

it is, yeah. Okay, so every time there's a proposal there that is getting more traction and... and getting closer to stage four, which is, if I recall correctly, the stage where it is approved and ready for the browsers to implement it, then you see a movement of every major framework getting closer to what this specification is saying. So I think if there's something that is going to bring frameworks closer together is proposals for native implementation. Other than that, I don't see them getting closer.

 

Armen:

I want to make one point specifically from what you said about this being kind of unfamiliar. I think, you know, the thing is it's a historical thing. It's because of the conditions we're right now in. Like when AngularJS started, it was just JavaScript framework. And when I say just a JavaScript framework, it worked like, I don't know how jQuery did. You dropped the script for Angular source code, right? And you build stuff with that. So back then, the only way to have a control syntax was directives. You, what Angular did, AngularJS, right, did back then was, well, you know, you have an ng-if statement somewhere. It was called ng-if, right? I did AngularJS six years

 

Subrat:

Yeah, I guess nd

 

Armen:

earlier.

 

Subrat:

hyphen if

 

Armen:

It was

 

Subrat:

I remember.

 

Armen:

ng-if, yeah, it was, yeah, ng hyphenated, ng-if, ng-repeat, it was ng-repeat, not ng-if. Wow, such memories. So what AngularJS did then was it went around the HTML code like jQuery would do and found all the directives and would say, oh, this says ng-repeat, I'm gonna go on a loop. for this HTML element. There was interpolation, but I don't remember, there was some difference before, on how it functioned in AngularJS and Angular now, because Angular has a compilation step. So you could put anything in the template. We'll just compile it to valid JavaScript and ship it to the browser. So obviously, At that stage, I think Angular didn't want to go too far away from AngularJS. So they built the new good concepts like components and how services now function with TypeScript and injectables and so on. But actually the core concept kind of remained the same. The syntax changed a bit in the template. because of how you have to use ng-templates and so on. But the core idea was the same. And it was a good decision at that time because they were dropping Angular. They were dropping this new thing, but it is in the spirit of the old thing. And then it continued its evolution and embraced new things. And as it embraced new things, it became apparent that this choice that made perfect sense like back then, can be now subject to some discussion, right? So I think it's still a good decision, but we need to wait and try it out in the field to know for sure. I am for it, to be clear. I don't think it's ugly. It's a bit weird,

 

Subrat:

Yeah.

 

Armen:

is all.

 

Subrat:

Yeah, I would like to be a devil's advocate here for some time and just

 

Armen:

Yeah.

 

Subrat:

one thing is coming to my mind is like suppose now we have this structure of control flow with curly braces and but when you create your own structure directive and add a star something because they are not extending this to at least till now it's extending this to implement it. So when newcomer will come. For them, it's two different thing to learn now. Maybe if and else it's common. So they still have to learn how to use star and all those things means at least need to understand the behind the scene and how it works. And if you're exposing your whole application as a framework suppose like a CSS library, which has supports for multiple components and all. using Angular elements or something. So then you can also expose a structure and detect it to that. In those scenarios, might confuse a new newcomer in my point of view.

 

Lucas Paganini:

I think that's an interesting point. I had made a note about this. I thought about going into this in the pros and cons, but I guess we're already there.

 

Armen:

We are on the cons

 

Lucas Paganini:

It's,

 

Armen:

now.

 

Lucas Paganini:

yeah,

 

Subrat:

Yeah.

 

Lucas Paganini:

which is... And that's a pro and a con at the same time. So in one side, it's easier to understand this new built-in control flow structure than it is to understand structural directives. It's easier. It just feels more natural. It feels like,

 

Subrat:

Yeah.

 

Lucas Paganini:

oh, okay, it's a building operator. I'm going to use that to do that. Okay,

 

Subrat:

Mm-hmm.

 

Lucas Paganini:

good. But you're also reducing the exposure that developers have with structural directives. Like everybody had already this vision that structural directives, so I'm talking about any directive that has an asterisk in the beginning. So ngif, ngfor, all those directives in which you use an asterisk in the beginning, they are called structural directives. So there was already a preconception from some developers that didn't look at the docs and didn't study that properly that those directives were special. They are things that I can't create. They just exist by the Angular team, and I just use them. And then as you get more exposure to that, and then you realize that there are libraries that expose directives that you use with that asterisk, then you start wondering, hey, I can create that? Like, what does that do? And then you go on and you search and then you learn. But now you're gonna have less exposure to it, which in a way, it might actually be a good thing because... Now, when you see structural directives, you're not gonna think that they're so special, which might trigger you to actually try to understand what that asterisk does. Because right now, you might think that this asterisk is just because, oh, it's an Angular native directive. That's why there's this asterisk. I'm not even gonna bother. But now, you're not gonna see that in the Angular everywhere, you're not going to see them everywhere. So maybe that actually increases the curiosity. Huh, that's funny. I'm kind of debunking my own point while I was thinking about it. But yeah, there's actually a thing. I was thinking that people were going to have less exposure and then they would not learn about structural directives, and they're super powerful. By the way, if you're listening to this episode and you don't know what are structural directives, we had... an entire, like more than one episode just about directives and all their superpowers in Angular. So be sure to go back a few episodes and listen to that because there are a lot of hidden gems there, a lot of things to learn that will make you an advanced Angular developer. But yeah, I was afraid of people not learning about structural directives, but now I actually think that it's going to be the opposite. It's going to encourage people to research them more. because they're not gonna think it's a native special thing.

 

Armen:

It's so funny because the Twitter space that I mentioned had the exact same course of discussion. Someone suggested that, you know, but people won't learn about structural directives. And I don't know who was that. Maybe it was even me. I just don't remember. It was a two and a half hour to the face. And we arrived to the conclusion that, oh, but maybe people will learn more about structural directives. You know, they won't think that this is some obscure building thing. Also, fun fact, if you just drop an asterisk on any HTML element, just an asterisk, it will become an ngTemplate. Structural directives is just... Directives are not structural, essentially. Any directive that you put on an ng-template is in the end of the day, can just access to that template ref. Because why not? I can access the element ref, right? When I drop it on some button, for example. Why not access the ng-template? And this is a weird thing from one perspective, because we are using ng-templates a lot. It makes sense to have a shorthand like syntactic sugar, but with this syntactic sugar now it becomes kind of the situation that people think that this asterisk is the part of the directive or what makes it structural. But actually I can just drop that on any directive, right? It will work. I mean, it will not work because the element will become invisible after that. But if it's just an attribute directive, right? But what makes a directive structural is that you do not call it on an ng-template, essentially. If you call it on an ng-template, then it's a structural directive. Because when we write asterisk ng-if, it just translates into ng-template, ng-if with the brackets equals whatever condition, right? So asterisk is just a shorthand. they could have just as easily said, oh, you know, if you want to display HTML elements conditionally, you have to use ng-template. If they did that, even that would have a justification because templates are valid HTML elements and templates are created for this sole purpose of displaying something dynamically or conditionally, right? So if they did that, we wouldn't be having this discussion today. People would just say, oh, that's great, I don't have to write an ngTemplate now to be able to do something conditionally. So, essentially, this asterisk here is what kind of creates this debate. And with this template syntax, I would also not have to wonder how I put several HTML elements in a conditional block, but I can, it's separated from templates. whatever, there are different concerns like if you aim for 100% valid HTML or if you aim to be compliant to whatever code you are compiling because everything that you are writing in an Angular template just gets compiled to JavaScript in the end. So if previously it puts an ng-if sort of marker. some element it would see that it's an ng-if and it will call apply that directive so if we are familiar with how IV compiler works it compiles into commands right it says if you have some HTML it will say oh start with this element then advance to this other element then this element oh there is a directive on it apply this directive to this element ref and so on so with ng-if what happened there was just that oh you came down and then oh apply this and whatever Angular will, this directive there will handle it. Now, I mean, I'm pretty positive that it will just compile to an if statement in JavaScript. Because if you have seen compiled output of a component, the template part, is just a function that takes the render flag, it's either first render or it's a detected change, right? And it just... go through those commands. Those commands are very smart commands. It doesn't work in the same way like React does. In React with virtual DOM, it just spits out an object, a big virtual DOM object that is getting compared to the actual DOM, which is even bigger. And they have lots of optimization. It works fine. React is very performant. But Angular does it in a different way. It says it creates some functions that kind of go over the DOM and apply changes. Okay. And in the future, those functions will get more granular and your change detection will start at lower levels, not from the core and go on and see if anything changed. But essentially right now, you see that something in the component changed, you start doing stuff on that component. But that is different stuff from what React is doing. React is doing rendering, creating virtual DOM and then passes it to... somewhere where it gets compared to the actual DOM. In Angular, it goes the kind of opposite direction. It goes through the actual thing and asks if, oh, I found the binding here that has changed. Okay, I'm updating this, I'm finding this, I'm finding this. Maybe in the long run, especially with signals and if we go zone list, this will be even further optimizable. In this context, it would be better if you look at the source code of ngif. It's not super hard, but... it does a bunch of stuff. It says it itself listens to the change from above in the sense that it has an input and if there is an input it decides if I should remove this block, embed this block and so on but here it will change. Here it will change because it will be inside the compiled function. So maybe again I'm speculating, I'm no expert of how like internally everything functions but I think this might possibly be more performant in the runtime, but don't quote me on that. I'm not sure, but it's possible. It definitely won't be less performant, but maybe it would be even better than ng-if. Who knows.

 

Subrat:

Yeah, I guess if as you told if it is not falling back and checking to all the chain detection and everything it might increase the rendering flow maybe.

 

Lucas Paganini:

Now, there is one very real cons. Oh, well, okay. Not a cons because it doesn't exist now, so we're still getting something from it, but like there is something that people are definitely gonna ask, and some of them we want to do, and they won't be able, at least now, which is creating your own operators for this new syntax. So... In the RFC, they are very explicit that right now, they are not looking to allow people to create their own, extend and create their own versions of those operators. So for example, if you want to create, I can't even right now think about a specific one that I would do, but like, I don't know, maybe I want to implement. virtual scroll. So I want to have a loop that already does virtual scroll somehow. So I want to do a built-in control flow structure that already does this virtual scrolling. So virtual four. I don't know. I can't. So that might be a little bit annoying, but I don't think it's that much annoying because we don't even have that right now. I'm not really gonna miss something that I don't have and I can still do it with structural directives. But yeah, I think eventually people are gonna start asking for ways in which they can create their own or is the answer like just if you want to do your own thing, just do a structural directive.

 

Armen:

Actually, it's a bigger concern, but not in the sense of... We cannot extend this syntax. What other libraries, like most famously RxAngular did with their reactive directives, right, the virtual scroll, I believe, and so on, I didn't use RxAngular, but I read about it a lot. references to ng-if and so on in the code. They use the ng-if essentially. And, you know, the thing is again, you still can build directives like this. It won't be a problem. Again, ng-if is a directive itself right now and it uses some angular functionality, namely template refs creating embedded views and view container ref. Those two are the foundational part of Angular. They won't go anyway. So you can just build an NG if using those tools without having the NG if. Maybe just, the word just isn't very good because it's still a complex process, but you can do it. So it's not like cutting off 100%. What's the problem right now is that, well, we could extend NG if, but we cannot extend this. So. And because this is the official approach, people would be less likely. If you know that ng-if is a directive or ng-for is a directive, you are more likely to use an erics-for, for example, or some custom-for, because you know, well, that's a directive. Angular ng-for has some concerns or has some capabilities that I don't want or... misses some capabilities that I want. Okay, I'm going to use some other four. It looks the same, it's just different letters. I will say, you know, people are using this. But with this new syntax, obviously people will be less likely to use the directive for control flow, because, well, it's not the official way. And that is a concern for library creators and so on. So, if we would be able to extend this control flow, that would be cool. Although, although... This control flow, especially with signals, when we can inject and call functions and so on in the template, they could work really well with this new syntax because, look, one application of building upon ng-if was creating custom directives for, I don't know, checking permissions and so on. I have an article, I think we discussed this on another episode. can build a structural directive that can check for permission with just the name and work as an ngif without the need to import the permission service, the store, or whatever we're using for that state management. In this scenario, you can actually kind of do the same thing. If you have a store from which you can select the signal, you can just create a function because you now can build functions that inject dependencies. You can use the very simple function that is called hasPermission and that receives this argument and returns you a Boolean or an observable of a Boolean or whatever and you then just inject that function you use an injection token for this function you inject it into your component that's one line of code and then you write if hasPermission do this do that whatever so this will just give And these new approaches might be actually kind of better because we talked about putting business logic in the directive and it's still a valid thing. But this is something that needs more explanation for other people. Like, why is this directive doing this huge things with the business logic? Why is it injecting all those services and so on? Because, for example, when we talk about components, we say, oh, you know, don't bring your business logic into. You just select the state if you are using state management or whatever and render the template everything else belongs somewhere But in the case of directives we are saying oh, it's okay to do directives like this Some people might disagree with us some people say oh no, it's not okay there too But then they will also obviously not be using directives like that, right? So it's not that this new syntax is kewing off all those approaches. It's just changing them. We will have new approaches to doing this sort of things, sort of business logic. Essentially, everything revolves around the template. This is good that the Angular team is looking into the template, because templates in projects are usually the messiest place. You can have this shiny component, which TypeScript file is so clean, it's so understandable, then you go into the template. It's nested blocks, nested, I don't know, ng-if, ng-force, ng-templates. and so on and custom logic and whatever. If we can sort that one also through, that would be cool.

 

Subrat:

yeah I think I would have a different approach like I just told that we were about the Lucas thing like what I'm thinking is it's not they should not allow this will not allow to extend this as I create your own directive because like you told suppose someone is using Rx Angular so they should have they should have conscious decision to use the Rx Angular And instead of ng-if, if they are using Rx-if, that means they know that this is going to do something different than what Angular is doing. So I would not say it will make much difference. But for newcomers, they might say, OK, this is not the usual way to do. But if someone is taking a conscious decision and they found a better framework which is doing something. good for their scenarios, then they might use a regular structural directive like RxAngular.

 

Armen:

I think we won't be able to cover the other topic too because Angular also introduced deferred loading. No, it is going to introduce with another RFC.

 

Subrat:

Yeah.

 

Armen:

And it is related to this one. So maybe next time we have a panelist episode, we should discuss lazy loading and

 

Lucas Paganini:

This

 

Armen:

the

 

Lucas Paganini:

is

 

Armen:

new

 

Lucas Paganini:

the

 

Armen:

deferred

 

Lucas Paganini:

teaser.

 

Armen:

loading. Yeah.

 

Lucas Paganini:

Yep.

 

Subrat:

yeah

 

Lucas Paganini:

Yeah, I think this

 

Subrat:

hey

 

Lucas Paganini:

deserves its own episode.

 

Subrat:

lazy

 

Armen:

Yeah,

 

Subrat:

loading

 

Armen:

definitely.

 

Subrat:

is coming guys

 

Armen:

I was

 

Lucas Paganini:

Yeah.

 

Armen:

working on something today with lazy loading and realized I don't really know how it works, because I mean, when I say lazy loading, I mean like deferred loading of a part of a template, not routing lazy loading. And I realized I don't really know how to do that because I didn't use that in like real applications. And it's not as simple and Angular is looking forward to simplify it. So yeah, that's definitely a big topic.

 

Lucas Paganini:

Speaking as someone who knows how that works, deeply, deeply knows how that works and play with it and had to create a website that renders different languages and with server-side rendering and also uses dynamic components, I'm going to tell you that I'm very anxious for a better solution to this because... Every other developer that works in this project, they need like three or four days to understand my code. And it's really well-documented. It's just a lot of things happening for it to work properly. So if we can simplify that, then I'm all for it. I think this deserves a lot of simplification. But any case, if you're interested in that, then maybe you're listening from the future in the episode... is already recorded. So stick around, keep listening to Adventures in Angular, and then we are going to bring this information to you. OK? Until then, let's start wrapping up this episode. But before we do, let's talk about what we are working on. So I'm going to start, and then we can all do our own. In my case, I'm going to just mention my company, Unvoid. So we are specialized in Angular development, and we also do design work. So basically, if you either want to outsource your project or you want to bring in external consultants, external developers to help you on your project, but you don't want to fully outsource, in either case, you are in good hands by hiring Envoy. And also, if you're an If you don't feel like you're in good hands, then I'm just going to tell you that. And we're not going to work together because honestly, we only get clients where we are sure that we can provide you with the quality levels that we want to be known for. So we only really say yes to projects that we feel that we can do really well. So if that's something that you might be interested in, then go check out unvoid.com and you can go into the contact us section and have a meeting directly with me and then we can discuss your needs and see if it makes sense for us to work together. So this is gonna be my promotion for today. Armin, how about you? Anything you'd like to promote?

 

Armen:

I will tease as always but I will say that I will promote a big thing in one month, fairly big thing, when I'm allowed to market it. But right now I would say if anyone enjoyed this episode I also suggest maybe go and listen to the Twitter space I mentioned several times today. It was a really good discussion. J. Cooper Bell, also GD on Angular was there. It was Daniel Glaesner's Twitter space. Lots of people joined in. We discussed it in way more detail and I believe we also touched on the case of businesses migrating from old code bases and so on. And it was completely all about the templates, this new syntax. So if you're interested also, you can give a listen to that Twitter space too. It's a really nice discussion. So yeah, I think that that's what I would like to promote today.

 

Lucas Paganini:

Awesome. How about you, Sivarit?

 

Subrat:

Yeah, I would like to promote my YouTube channel which is fun of heuristic Please go and watch that. I know I haven't put any videos since long, but now my vacation is over I am back to Amsterdam and Hopefully I start recording again So please go ahead and watch that and I would just like to say that people are saying Angular like in my videos not in two three videos like it's Angular is going towards React. And if you listen to this episode, you know that Angular is not going towards React. So now you're clear.

 

Lucas Paganini:

Also, even if it's been a while since you haven't uploaded videos, there are so many valuable videos in your channel that I think people should go check out either way. There's a lot to learn there. So Brett has done many, many videos already and they're all free. Come on, this stuff should cost millions. It's really, really well thought out content. So yeah, go check out those two and... Also, maybe connect with or follow Armin on LinkedIn. That way you will know when he finally tells us what he's been up to. All right. Okay, so thanks everyone. Have a great week and I'll see you in the next episode.

 

Subrat:

Thanks. Bye-bye.

 

Armen:

Thanks everyone.

 

Subrat:

Thank you.