José Ignacio Santa Cruz is a Fullstack engineer at Newfire Global. He joins the show to talk about his article," Upgrading an enterprise app to Angular 16". He begins by explaining the level of difficulty you might experience in upgrading your app. He talks about its importance, its process, common pitfalls you might encounter, and many more!

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

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

Lucas Paganini:

Hey, welcome to Adventures in Angular, the podcast where we keep you updated on all things Angular related. This show is produced by two companies, Topend Devs and Unvoid. Topend Devs is where we create topend devs who get topend pay and recognition while working on interesting problems and making meaningful community contributions. And Unvoid, which offers remote design and web development services with specialization in Angular for companies that truly care about quality. José Ignacio Santa Cruz, aka Santa, is our guest for today. And he wrote a recent article about his experience upgrading an enterprise app to Angular 16. So that's what we are going to talk about today. Mainly, is it worth it? So we all know that enterprise apps have a lot of complications. And Angular 16, although it wasn't released yesterday, still pretty recent. So. The main question is going to be, is it worth it? And what are the most common pitfalls you're going to have to be aware of if you decide to go down that path? My name is Lucas Paganini. I am the CEO of Envoyed and your host in the podcast. Joining me in today's episode is Armin Vardanian.

 

Armen:

Hey everyone, nice to be back for another episode.

 

Lucas Paganini:

Subrat Misha.

 

Subrat:

Hello everyone!

 

Lucas Paganini:

and Santa, José Ignacio Santa Cruz.

 

Jose Ignacio Santa Cruz:

Hello everyone.

 

Lucas Paganini:

I'm very happy to have all of you here and Jose, so let's get started. So why don't you first tell us the main question, which is how hard would it be for somebody to upgrade an Angular, an enterprise application to Angular 16 nowadays? And also... How much easier it would be if we just waited like 6 months? Or maybe even a better question. How long do you think we should wait for this to actually become extremely easy?

 

Jose Ignacio Santa Cruz:

Okay, well, it's not a simple question to answer, but let me try. How hard it is to update an Angular, an existing enterprise Angular application? It will mostly depend on the Angular version that this application is running. For example, if the application is running, let's say, an old version of Angular. Let's say, for example, Angular 13. Migrating to Angular 16 may be a little difficult because there are many things that were deprecated on the libraries. There are many advised practices that most Angular 13 applications do not apply. And the other thing is the libraries that this application may be using. And here we have the link with the other question that how difficult would it be to upgrade. For example, if this enterprise application is using some legacy libraries, or let's say that was created for Angular 9 or even older versions, but the code is actually right. In the enterprise application, I tried to make this update. We are using a library that's called TextMask. And, well, it's... That's... you have a form and in the inputs you place a directive with some defined text mask and the text is masked accordingly. And the library is not supported by Angular 16. And this is because this library was created using view engine. And now Angular 16 throw the view engine to the garbage and only supports Ivy. So lots of warnings, lots of, lots of, this library is not supported. What can you do? Let's check the code. And as we are using open source libraries, the code is available. We looked at it and there's no problem with the code. So if the code's not wrong, what is wrong with it? With the library itself. And those are the dependencies declared on the package JSON. This library was created with an old Angular version. and it's not supported anymore.

 

Lucas Paganini:

Even in those cases, there is a dirty workaround that I have used in the past when I needed to upgrade an Angular version. And there was a dependency that was misbehaving. And when I say misbehaving, it's like, I actually need to replace this dependency later. But I don't want to do it now because for whatever reason, we need to deliver the Angular upgrade as soon as possible. One option, assuming that the library is open-sourced, and I'm assuming that most of the libraries that we are gonna be using as developers are open-sourced, and if they aren't, then they probably should be updated because there is a company getting money and updating it. But if they are open-sourced, then you can in most cases just port the source code from the library to your source code, and then you're going to build it as if it were your source code, not an external code, and then it works because it will be building using the current version of Angular that you are using. So it's a very dirty workaround because you are copy and pasting... source code from another library into your source code. And even in terms of ESLint, things just get terrible. It's like you open it up and there's a, you are drowning into red lines because everything is not complying with your particular style conventions. But other than that, it's fine because it works. And then you can deal with this later. So this is a strategy that I have employed. in the past when I really needed to upgrade an Angular version quickly and deal with the misbehaving dependencies later. Is that also something that could be used here or in this particular case, as you were saying, it was using something that was completely removed? So I'm guessing that if you just copy and paste the code, it still probably wouldn't work, right? make changes to the source code of the library, or not.

 

Jose Ignacio Santa Cruz:

Well, that actually works, at least for this library. But there are some libraries that use angular internals. And by internals, I mean that they're using some libraries that have this strange charater starting strings for the names. And those, those libraries are not really meant to be used by,

 

Armen:

The theta

 

Jose Ignacio Santa Cruz:

by Yeah.

 

Armen:

thing, yeah, it's the Greek theta. I don't know, I will ask my Greek friends how it's pronounced, but yeah. But is it possible to use them? No.

 

Jose Ignacio Santa Cruz:

in certain cases you can,

 

Armen:

Oh.

 

Jose Ignacio Santa Cruz:

but if the next Angular version does any modifications that can affect those internal libraries things will stop working. plainly. So,

 

Armen:

Yeah.

 

Jose Ignacio Santa Cruz:

and that's a real pain when developing or trying to upgrade an Angular version that is using legacy libraries, or not legacy libraries, but libraries built over old or too old Angular versions.

 

Subrat:

Yeah. Here.

 

Jose Ignacio Santa Cruz:

And

 

Subrat:

Yeah,

 

Jose Ignacio Santa Cruz:

okay.

 

Subrat:

sorry, go ahead. And what I was saying is here is I think is a crucial part of software development comes into the picture like Like we just go ahead and blindly select a library, which is open source, not checking how the library behave, what are the supports. For example, it's little off topic from Angular. Like if you go and check Express, it's not supported now from long. So that's why people are moving to Firstify. And that's the reason like how, why you should select which library. but if it is already done from past and like what you have explained, one of the best approach I can think of like, just go ahead and update that library, create a Git repository and use as a Git repository for NPM and it should work for you, but it's better to get rid of the library if you have time and money to do that. But yeah, I think this one thing is coming to my mind, like not to be in a hurry to develop and release the thing to the client or to the world and just use anything which is available in the open source without checking them.

 

Lucas Paganini:

Just one note on that. I once got into a very weird discussion because I was using a library in a code base that I had created a library. So I have some public libraries published on NPM. And I knew exactly how it was built. So I knew it was safe to use. But... a colleague was arguing that we should remove that because he was using Angular internals. And I was like, what? What are you talking about? And he was saying that he was debugging somethings, and then using the Chrome DevTools, he was using the debugger statements and stepping into to understand the code flow. And then at some point, it landed in... inside of my library code, and he was able to see that it was referencing Angular internal variables, so those variables starting with the Teta symbol. But actually, the source code was not referencing those. It was injected there after the build process. So just one note, in case you see... code from a library that you're using, from one of your dependencies, and it is referencing Angular internals, it doesn't necessarily mean that the library is unsafe and that you need to remove it because it's referencing Angular internals. Sometimes in the compilation process of the library during Angular's ahead of time compilation, it injects those symbols in the final build. and then you'll be able to see them there. But if you look at the library source code, it's not referencing them. So just a small note, because if we just tell people, hey, be aware of how the library is doing things, if they're referencing Angular internals, then be careful. And I think this is really good advice, is just make sure that you're checking the source code.

 

Armen:

I wanted to ask another question and it's more about the scenario that Lucas said like you can copy paste the source code of the library if it's not a very big one and if we can and we can't do that but if we do that if we can take the code and put it into our project and it takes some effort Would it really be more effort if we took that library which is clearly not being maintained at this point because It doesn't upgrade with the version of angular for what three years? IV not three years almost five years because IV came out in 2019 I believe right So it's almost It's four years and the library isn't being maintained. And if it is small enough that we can kind of copy paste its source code into our project and use it. Would it make sense, would it be more effort if we just created a separate project and put that library code there with a newer version and fix the issues that may arise? The same issues that we would have and then publish it separately. Maybe if we are concerned about all these things mentioning that the authors worked on this and we just ported it to use after Angular 16 to use it without NGCC, what do you think about something like that?

 

Jose Ignacio Santa Cruz:

It's almost the same effort, in my opinion, because it may be easier to fork the project and start a project using the latest Angular version or the current Angular version and take the code and copy paste that on this brand new project and compile it using the current version in order to avoid this IVs not supported in these library issues. And that will work. The thing is that in that case, you should probably need to publish that library as a fork and keep the references for the old library just to be

 

Armen:

I'm...

 

Jose Ignacio Santa Cruz:

open source friendly.

 

Armen:

Yeah, you're right about that. I'm more into the thing that rather than starting becoming a maintainer of this library now, because you have the actually working fork, I'm more like, we don't touch the code as much as it's possible not to touch, and we kind of make a promise not to touch it. We don't change anything. take the readme file and just add a big red thing on top saying that this is the working fork of the original project and it works with Angular, whatever version we need. And everything else is the same, even the readme is the same. So just read the readme and read the docs and they will stay the same. Of course, this will only work with small projects. I don't think, for example, if Godforbreath, ngRx, stop. having any support no one could really... definitely not one person could take and make a working fork of it but small things like the one that you mentioned and there are lots of libraries like that and lots of them are really useful and kind of popular. I remember I have seen some package that had an image cropper for angular and it was and it had lots of downloads like in the 100 thousands something like that on npm and I didn't even read this doc to understand it's very old because it was called ng2-something imagecropper so ng2 is like a convention where people just added the letter the number 2 when they came up with angular library so it's very possible it was started Like way back when we had angular really version 2 so Yeah, for example if such a Community project stopped being supported and it's a singular finite thing Yeah, maybe then making such forks would make sense

 

Lucas Paganini:

I think that first, I don't agree that it is the same effort, but also I'm not saying that to discourage people from doing that because I think that if more people did that, it would be way, way better than everyone just copy and pasting the code into their own code base and nobody sharing what they have learned or the bugs that they have fixed. And also, if you fork, you can just PR into the original repository from your fork, and then the owner of the original repository, this person may not be available to maintain the library, but if your PR is there, sitting and working, then if it's an easy merge, then maybe you can actually get it to update the original library, which would be even better for the entire community. So that is great. The part that I don't agree that it's the same effort is the part about learning how the build and the publish process of the library work. If you're just copy and pasting the source code of the library into your own code base, then you ignore how it is built and how it is deployed. And when I say deployed, if we're talking about a library and talk about publishing to NPM or something like that. Why do you ignore that? Because you don't need the library on npm because you're just referencing from your local source code. And you also don't need to understand the build process because you're gonna use your own current code base build process to build the code. And that part, I think to me at least, takes

 

Jose Ignacio Santa Cruz:

Thanks for watching!

 

Lucas Paganini:

either the same time that it takes to update to understand the problems of the library make changes to the source code or even more. Like in most cases, I would say that trying to understand how the build process and the publish process of an open source library works, takes me way, way longer than just copying the source code and putting it into my code base and having it there. So that part is the one that I think would be the hardest one. And I think it would take a lot of effort, but I think it would be extremely honorable and really good for the entire community if more people did that. Or if they at least maybe you don't do the, don't understand the build and the publish process, you just do the fork, make changes to the source code and that's it. But then how do you know if it's working, if you don't even know how to build? So you've got to know how to test it to make sure that it's actually working. So I think it's a lot more effort than.

 

Armen:

but there is also another angle to that. Like if you are publishing something or maybe posting PRs to upgrade then you learn something but when you copy paste some code into your project then you're committing a war crime.

 

Subrat:

Yeah, I think like it's like I will be aligned with Lucas here. It might not be the same effort or it but it all boils down to how much liberty we have for a lot of projects. We don't have that much bandwidth. And also we don't have that much money to build a developer to do all the other changes and all if I'm saying if it is small projects but if it is a bigger enterprise is doing and they can raise a PR to fix the library which will benefit everyone else then it makes sense to go that way but and whoever is listening now if you are in a hurry to do the things fix it as quick as possible then I think the first way will be the easier one but it's the dirty one of course so i think while we are discussing we are negating some part of the user who are like just need to fix it tomorrow so for them going through a pr and everything is not possible and but they if you have bandwidth fix it first then go ahead and your PR might help you later on a project. So that's the only one thing I would like to focus on.

 

Lucas Paganini:

Yeah, so in summary, I'm guessing it's like proposed to the

 

Subrat:

Yeah.

 

Lucas Paganini:

client or the company or whatever. And if you get them to accept, then great. And if they don't, you can also do that in your free time if you want to contribute to the open source community. And in terms of learning something new, yes, there's this aspect, although I gotta say I'm a bit more skeptical about this because I, for one, I am somebody that reads a lot and still I haven't... I can't say that I have read most of the things that I think I should read, for example. And when I say that, I'm not talking about reading every article in media or some crazy... impossible metric like this. But I'm saying like I use Node a lot and I have been recently pushing myself into reading the entire documentation of Node.js. I have never read, I have read bits and pieces but I have never stopped, seated and read the entire raw API docs for Node.js. I have read the entire API docs for Angular multiple times, and I tried to reread it on every major version. But there are other things like that. For example, MongoDB I use extensively. I have never read the entire API docs. It's not to say that I don't feel proficient in it, but if I have to choose how I use my time in a way that is most effective to learn a new technology, If I want to learn more JavaScript, ATML, CSS, web technologies in general, I would rather binge read Mozilla Developer Network docs than trying to understand a particular open source library. But yeah, that's just how I would tackle the problem of learning in the most effective way. It's not to say that you don't learn something when you try to fix an open source library. You always do, and it's always significant, especially because you're actually doing something, so you fix that knowledge in your mind. I'm just saying that maybe we don't know how much influence we have on the developers that are listening to us, and maybe there's somebody in a junior or trying to get into the area and trying to figure out the best way to learn. I wouldn't say that... trying to fix open source libraries is the best way to learn. I think that reading the official docs for the technologies that you plan on becoming proficient is the most efficient way to do it. Yeah,

 

Subrat:

Yeah, but I think...

 

Lucas Paganini:

we went really off topic.

 

Subrat:

Yes,

 

Armen:

I think, yeah,

 

Subrat:

I would...

 

Armen:

we really took a detour on this.

 

Lucas Paganini:

Yeah.

 

Subrat:

I would just like to add one more thing, just wait with me. But by doing this way, they will learn how to deal with others' mistakes. So if you just read the docs and all, you will learn the language, you will learn the framework. But you will not learn how to fix other human mistakes. By fixing something, we will learn that. And I think that's the very big part in... development carrier because you will not, it will be very few times we'll have a luxury to start a project from scratch. We all, it's always 99% of the time you'll work on someone else's code, try to fix something, try to build something else. So if you do anything, it's a win-win situation for both of the scenarios.

 

Armen:

I have a more on topic question.

 

Subrat:

Okay, yeah, go ahead.

 

Lucas Paganini:

Please.

 

Armen:

So, what's interesting for me is I haven't upgraded to 16 any of my enterprise projects, the stuff that I work at my regular job. I upgraded something like my personal website or whatever, but those are all small things. And what's interesting to me is when you have a large application and with Angular 16, you We have lots of new features, not really like changes, but like really new things like required inputs and improved server side rendering and so on. So when you upgrade to Angular 16, in your experience, what's the strategy of adopting these new things? Like which ones do you recommend to start with first? Which ones would you recommend to avoid, for example?

 

Jose Ignacio Santa Cruz:

Okay, well, when I'm reading any Angular application, first is to see what features do you really consider useful for this application. For example, I would love to have signals on certain parts of the Enterprise app just to, for example, try to... I'm not saying this is the best strategy to do it, but to make a certain estate management in a extremely easy way. just like AngularJS root scope, when you modify the variable and place it on the root scope and it was available for all the application. Signals for my taste work in that way, or are really near the AngularJS root scope way of working. There's a variable that's changed somewhere, and in another place you can retrieve its value without making... many efforts or having a state management library. That's one of the uses I would love to see in this Angular Enterprise application. And use signals for it will be great. It will really simplify many, many tasks that are done injecting behavior subjects in a wrong way or subscribing or oversubscribing to certain events. That will be really great. But the question is, can you do it in a short lapse of time? Because time is money. Time to market is perhaps the most important things for CEOs. And they want their application to be online on the shortest time possible. And here I'm going back to the first question we were talking about, that is it worth it? Is it worth all the effort that may imply making this huge Angular version upgrade? Because most of the application is not thought to be used using signals. may probably not be set to be developed using standalone components. I'm going there to Angular 15. And there are many, many things that the development flow would have dragged as a probable technical because things were not developed the right way. So the question is, do you really have to be on the bleeding edge? And I'm talking about the bleeding edge because the edge, if it's like a knife, it will cut and if you cut yourself, you will bleed. And that's the kind of pain. I think developers have to take in mind when making this kind of upgrades that how much pain would you really have or how much time you have to invest doing these upgrades because you would probably do not need all those nice features. And that's the question. And if you really want to upgrade to a latest Angular version. try to make it gradually. um until that point that you can't really do anymore except try to make your first upgrades to the Angular 16 library. See, hopefully there were no libraries, legacy libraries that will cause any problems. So you can keep on going, make it run. See, okay, I can upgrade this. I can make my inputs required for this component. And... see what kind of features are really needed or would be nice to have and try to be upgrading it on a gradual on a step by step. And how much time will this take? That was another, another question on the, on when we started. Um,

 

Armen:

Yeah.

 

Jose Ignacio Santa Cruz:

it can, it can become a huge new project by itself. I mean, this is,

 

Armen:

So you

 

Jose Ignacio Santa Cruz:

this

 

Armen:

are.

 

Jose Ignacio Santa Cruz:

is changing all the, the application to, to another way of, of defining your components or using some attributes. or properties or whatever.

 

Armen:

So you are more on the conservative side of the things. Let's be careful and... which is completely understandable for me although I wanted to discuss more hypothetical like let's say I already upgraded to Angular 16 let's say I have a big project I upgraded I didn't do any changes whatever needed fixing I fixed and essentially the project hasn't changed but now I'm on version 16 so I have all these new features that I can use and some of them aren't as revolutionary as signals which are in developer preview yet so I wouldn't want to use them in production ready code bases anyway. But I have some other new features and my question is more about which of these features in your opinion would be easier to adopt and most useful in that scenario.

 

Jose Ignacio Santa Cruz:

Okay, perhaps aiming towards the inputs on most components, trying to use the input transformers or the required input tag, that will simplify in a certain way how components are defined and how they are used. on the application. That will be a kind of easy task to do.

 

Armen:

Yeah, it makes sense. We had also this pattern of where developers wrote like getters, setters for inputs. I guess it would be quite, it would not be too hard to remove that logic and just use the input transformer function. So yeah, I get where you're coming from. And what about the routing info binding with components? That's a harder one, right?

 

Jose Ignacio Santa Cruz:

Yeah, yeah, harder one because mostly because when something like that was required, at least in our project, it was solved using some kind of workaround. I mean, taking, for example, the router object, turning it into a JSON and parse it and take some custom properties that were not really meant for that but they were used and it worked. So it's not the best way of solving a problem, but in most cases, what the CEO or CTO wants to see is that if there was a problem, it was solved. And I don't really care much. how it was solved, but I wanted it to be solved. And it will be the architect or a team leader that will try to stop these bad practices for being applied.

 

Armen:

Yeah, that's me.

 

Lucas Paganini:

I felt that.

 

Armen:

I actually about the routing thing when we talk about signals I guess if we get signal inputs in the future which we probably will it's in the RFC anyway. When we get that we will also... now that would be a big blow to RXJS. because not in the sense that we will stop using it, but with the routing info being bound to inputs and inputs that are now signals in the future, you just won't need, yeah, like you probably won't need the router in the component unless you are doing like navigation or whatever manually. Like all the info you just can bind to a signal and you will both receive the updates. Like if you want an effect or a computed property or whatever, and you will also receive, like you, you will be able to write an effect and you sort of can do that now with engine changes, but it just doesn't have the same ring to it. It's for all, it's for all, for all input parameters, but with effects. you probably don't need engine changes at all.

 

Jose Ignacio Santa Cruz:

Well, another thing that I guess everyone or most of us are waiting on signals are the signal styled components. where everything is turned into a signal.

 

Armen:

Well, we can have signals like this, sorry, components like this right now if we want. It's just that, it's more about the change detection thing, which is by the way, like in the future, we talked about NGCC being removed, but you realize at some point in the future, they would want to remove zone.js. It is something that they explicitly said that we possibly we are exploring ways and we now chose signals as the way of having granular change detection and not relying on zone.js. So if for example, signals succeed, which they look likely to, because I haven't seen people hating on them. I've seen people contributing to ideas around them, which drives it. like even further as an alternative. So if at some point everyone starts adopting signals, at some point zone.js will become optional like ng-modules have, right? And although if I think about maybe in the future they will remove ng-modules, I just don't see the need for that anyway, removing ng-modules. If at some point they realize no one is using ng-modules That's too far in the future. Not all the projects. There are lots of projects out there. You cannot upgrade to version 13. Like, uh, it was funny for me because at some point, uh, when you were speaking, because say you said, let's say a project that isn't an old version, like 13. But from the perspective of lots of enterprise companies, 13 is fine.

 

Jose Ignacio Santa Cruz:

Yeah.

 

Armen:

Lots of projects are on 13 or even 12 for

 

Subrat:

Yeah,

 

Armen:

that

 

Subrat:

that

 

Armen:

matter.

 

Subrat:

ain't even new.

 

Armen:

Yeah, and so if at some point they decide to do the same thing with zone.js, if signals become popular, everyone is using signals. Most popular and important libraries have switched to signal-based components. At some point, they will get a remove zone.js, right? Again, this is very far in the future and not even a sure thing like maybe it won't happen But let's say as long as is removed. That's even a more catastrophic event than like

 

Jose Ignacio Santa Cruz:

Yeah.

 

Armen:

Throwing NGCC away

 

Subrat:

I think if that's the scenario they might not do directly don't just remove the way what I can think of is all the variable will created that will automatically on the build time will change to signals and referring them they will handle it automatically

 

Armen:

So what about

 

Subrat:

on the build time

 

Armen:

the

 

Subrat:

and

 

Armen:

libraries?

 

Subrat:

then yes yeah about the

 

Armen:

Yeah,

 

Subrat:

they

 

Armen:

that's...

 

Subrat:

need

 

Armen:

they

 

Subrat:

to

 

Armen:

will

 

Subrat:

be updated.

 

Armen:

just have... yeah, if they have built code that just has class properties, like we have now, that we can just write, I don't know, this something equals whatever and it works. So they have code like that and they build it with a slightly older version of Angular, they don't care about signals. And now this is perfectly valid code. I mean, it won't even fail on a build stage because whatever, you can't possibly go around and force developers to make all the properties of a class a signal. Even if you wanted to, you cannot because you have properties that are dependencies that are injected, right? Some other instances. So you can't have everything to be a signal. Some properties won't be signals. There is no way that... compiler can determine which one needs to be a signal and which one not. So if you build this library and you deliver it, it's perfectly valid code and it will perfectly build with your Angular version that doesn't have zone.js, let's say. And now you will build your project and you will run it and you will see like... components that you are using but they won't They won't be Very responsive to change detection like they will work whenever your signals trigger Change detection in some parts right that is related but if they have something internal like for example if you have a If you have a clock right it updates every second and you put this component and it is using some jazz But you don't have some jazz so now You can't be sure that it will be updated every second, right? If everything is a signal and you don't have zone.js. If the user does not do anything that directly changes the state. That's what I'm saying.

 

Jose Ignacio Santa Cruz:

Well, I once did experiment of removing zone from an Angular application. And well, not removing zone, but declaring it as no operation. So it didn't do anything. And everything exploded just like that.

 

Subrat:

I can relate.

 

Jose Ignacio Santa Cruz:

We were using NGX data tables and all tables stopped working. And

 

Armen:

Yeah,

 

Jose Ignacio Santa Cruz:

well,

 

Armen:

of course.

 

Jose Ignacio Santa Cruz:

I understand everything. I mean, the application became instantly unresponsive to every event. So we said, no, not yet.

 

Armen:

If you try to do that, what you really need is you need to make everything an observable, well, or a signal at this point, because you can use the async pipe, it's an impure pipe, so it will trigger change detection by itself, depending on whatever. So without zone.js, this will continue to work. Something will subscribe there and see the change and will go like, please detect changes. Same goes with signals. I tried to remove zone.js in an app that has... very limited functionality and it kind of worked without it. Of course, it really depends. If you use good libraries that all have change detection strategy on push, then you have no problem using components from there. It's like it's the same as if they had signals before that. it will work in that way. But if you have something that is very stateful and it kind of updates itself, which for a third-party library, in my opinion, is kind of a red flag, I mean, I would want reusable components to have change detection strategy on push. And if it's on push, there's no problem. Then it will just wait either for internal events or for input changes. Then there is no problem. we can use signals in our parent components and child components will just work however they used to work. That's because if you have noticed in the RFC, they say that if you mark in the future when they have signal-based components, if you mark its signals true, then you can't even put change-in-section strategy on it, because it completely relies on signals now. There is no point of having on push or not on push. It's essentially all just one... granular state update thing. You don't have like an approach to it because it doesn't really rely on zone.js for updates.

 

Lucas Paganini:

I'd like to propose something before we wrap things up. I realize that we have been talking for a while now, so I don't want to stretch things up too much. But I think I can try to give to the audience a more actionable step-by-step process for someone that wants to upgrade. a code base to Angular 16, given everything that we talked about. So what I would do from a mix of my experience and also everything that we discussed here today in terms of step-by-step, and then I would like all of you to tell me at the end if there's anything that you would change, maybe in the order of things or some step that I'm missing. But basically, I believe that the first thing that... I would do is I would try to enable as many strict TypeScript and Angular flags as possible. So independent on the version that you're at, I don't care. If you're running Angular 6, I don't care. The first thing that I would do is I would enable as many strict flags on the TypeScript compiler and the Angular compiler. as they are available in the current version that you're running. After that, I would start migrating Angular and its library dependencies up until I reach a more recent version of Angular, let's say 12 or 13, that should be enough. So, from below that up until 13, I would probably just focus on enabling as many strict compilation flags as possible and then slowly upgrading the Angular core and its third-party dependencies. Then, from 13 to 16, I would still enable any strict flags that were released in the newest versions of TypeScript and Angular. But I would also... have an effort to modularize everything or remove modules entirely. If your plan is to do that, then you can just go to... Now, I don't recall when was the version that we got standalone components, but whichever version it was, then you can just go to that version and then you just remove... all the ngModules, but if you want to use ngModules, I would start modularizing everything and making sure that all the module dependencies are imported only where they are needed to, so that you make all the dependencies explicit in every single module. Then, after that, I would try to migrate, if you have an intention of using Angular signals, I would... try to migrate things to onPush as much as possible, at least the most critical parts of the application. and then I would do the upgrades and I believe that given that structure it would be way easier for you to upgrade the coveys. So this is kind of like my version of... it's not conservative because I'm still pushing towards the edge, but I am doing that in the most conservative way possible which is what is the least amount of... And how many PRs can I break this process? Let me break into as many as I can. You know, so if I can have 30 PRs to get to the end, that's what I'm gonna do. Instead of just having one PR per version upgrade. But yeah, I think that's mostly what we do and also upgrade the third party dependencies as we go. So for any of you that is listening and trying to come up with a... step-by-step approach, maybe try that. And for your use case, maybe there are some other things that you would like to add or change the order. But I think that for me, and I have done updates on legacy code bases a few times, that has been the general guideline that I followed.

 

Subrat:

Yeah, I think it's a pretty good approach. Uh, uh, one of the funny approach I can say like. Have a weekend hackathon and give everyone Red Bull pizza and just ask them who will do really win some prize and believe me, it will be done in two days.

 

Lucas Paganini:

That's like the opposite

 

Subrat:

He

 

Lucas Paganini:

side.

 

Subrat:

opposed it.

 

Lucas Paganini:

Mine

 

Subrat:

Yeah.

 

Lucas Paganini:

is like, what is the most conservative way to get to the edge? And Subred's suggestion is like, what is the most go fast, break things?

 

Subrat:

Yeah, but jokes aside like, yeah, you your points are valid. I think Santa can give a point here, like what his thoughts on it.

 

Jose Ignacio Santa Cruz:

Oh, well, I, I agree with SubRat approach.

 

Subrat:

Yeah.

 

Jose Ignacio Santa Cruz:

I mean, it's kind of a brute force, compile, destroy, reverse, compile again, destroy again. And it will require, it perhaps requires a lot of effort because you will be triggering all bugs at once. You're not... you're not as following Lucas approach that's quite structured. And it will certainly avoid most explosions on your code before trying to compile again. But I'm with Subrata here that try to do it as a hackathon, try to do it as fast as you can. identify your problems, solve them, and it will be a kind of not organized, but it will certainly add some adrenaline to your development process.

 

Lucas Paganini:

Guys, please invite me to those hackathons. Like, that's the kind of shit that I would love to do in a weekend. Yeah, okay. We talked about a lot, a lot today, and I've also contributed to some off-topic things, so sorry about that. But yeah, overall, I think it was really good, the things that we talked about in terms of... Whoever is working in an enterprise app and looking for a path to upgrade to the edge version of things, I think there's a lot of insights in this episode that are gonna be helpful for you in this journey. And even to convince management that it can be a safe path or safer path. And it can also be... a very fun hackathon if you're into that. So yeah, I think we covered technical tips and also how to convince your manager that this is a good idea. So let's start wrapping things up and let's just do our promos. So Santa, what we do at the end of each episode is we mention the things that we're working on that we would like to. to introduce to the audience and well, kind of this is our place to try to sell something basically and tell what's going on our side of things. So I'm gonna go first just to give you some time to think about what would you like to say. So in my case, I'm just gonna promote my company, Unvoid. So we are 100% focused on everything Angular related. I'm talking... training, vetting candidates, staff augmentation, or if you want to, then full on project outsourcing. So if you have any needs in your company related to Angular, either you want to help hiring new developers for your company, or you don't even want the trouble of hiring. You just want people as fast as possible to help you on it. then be sure to contact me. You can simply go to unvoid.com and there you will have a button in which you can just schedule a meeting directly with me. So yeah, it's as simple as that. So yeah, this is gonna be my promo for today. And Santa, would you like to tell us what you're working on? What would you like to promote?

 

Jose Ignacio Santa Cruz:

Well, I'm working on a health platform project for a company. Well, I recently changed my job. So when this article was written, I was working in another company. But here we're working on a health platform application. It's actually on Angular 13. And they're planning to upgrade it to Angular 15, not 16, 15. And I know what kind of pains they will face, because I already passed through that. And I just seeing the code, I see this is going to have some problems, or well, everything. But it's kind of interesting and entertainment for being there. And collaborating with their code. And just to promote myself, I invite everyone that's interested in Angular or any other full stack topics to visit the, to look for my Medium site at jsantacl.medium.com. That's where I usually write. And most of my latest articles have been Angular related. So if you want to read a little about that and spend some time and give me some claps, that would be nice.

 

Lucas Paganini:

Definitely. All right, we'll put those links in the show notes. Awesome. Iron Man, how about you?

 

Armen:

I don't have anything to sell. I will I will do a promotion next month.

 

Lucas Paganini:

Everybody still curious. Eventually you're gonna tell everyone what you're cooking up. I already

 

Armen:

Yes.

 

Lucas Paganini:

know, or do I? I don't know. But anyways, it's gonna be big news.

 

Armen:

Yeah.

 

Lucas Paganini:

How about you, Subrit?

 

Subrat:

Yes, so finally I am back again to posting videos. So I just posted one video today, means when you are recording while you are listening it might be one week or two weeks ago. But yeah, I am back again I am kind of promising myself to put every week a video. That's I am dealing I know that. But now I will focus on that. started scheduling some guests for my podcast. I think Lucas, you are the first one. I think second one. I am trying to, trying to send mails, emails for to some people. Let's hope I'll get back and most probably be on track again. That's my promotion again. So go ahead and check a fun of heuristic YouTube channel and give some comments.

 

Lucas Paganini:

Awesome. All right. Okay. Thanks, everyone. This was a really interesting discussion. Santa, love to have you on the show. Thank you for coming. Thank you for all the insights and the time that you took to study all this and bring your experience to us. It was highly valuable. And I think it was also valuable to a lot of people listening to the show. So thank you.

 

Jose Ignacio Santa Cruz:

Thanks for the invitation.

 

Lucas Paganini:

You're welcome. All right, everyone have a great week and we'll see you in the next episode.

 

Subrat:

Bye bye.

 

Armen:

Thanks everyone.

 

Jose Ignacio Santa Cruz:

Bye.