Recently, I found myself in charge of upgrading our Angular application from version 12 to 15. In my current role, which I've held for just over a ...
For further actions, you may consider blocking this person and/or reporting abuse
One thing I've seen from more than one person (all of which had an extensive Java background) is a mistaken understanding of what it means to do type assertions, especially at system boundaries. Often they tend to model the response from some REST endpoint with a class and write methods and then consume some JSON with the HttpClient, asserting it conforms to said class, and wonder why the JSON which they actually got is not serialized into an object of the class and the method calls yield a runtime errors (but, but, but the compiler said was correct!!!1!). Well, just like every marine is a rifleman first, every TS dev is a JS dev first.
That's a good one 😄
Oh, I got you. My problem is that our codebase is in Angular 6. Yeah, and a lot of mixed dependencies with non well separated components that also generates UI inconsistencies. All that to wait for a 1+ hour build. Beyond that it was built on top of JHipster and the company intends to keep it.
It'll be a hell of an extensive work but, TBH, I'm pretty willing to do it.
Ouch, that is painful 😵 And how is it possible to make it a 1+ hour build? 😄
I think the biggest pain points will be upgrading to angular 13 and 16.
Angular 9 introduced the Ivy compiler and in Angular 13 it deprecated the View Engine, so everything is Ivy now.
In Angular 16, they deprectaed ngcc and now all the 3rd party libraries, that are not built with Ivy, are not compatible anymore. That's the reason I stopped at 15, because there are 3 npm packages that we still need to figure out what to do with them.
But overall, I enjoyed it more than I hated it. It was a great learning experience.
I believe we'll start all over from the begining with angular 16. But this time thinking about components as they should be planned and designed, and trying to use all of the new stuff angular brings to our benefits.
Yeah, 1+ hour build sounds like a crazy thing but the application is very large and is very far from being optimized in any level. There's a lot of code duplication, which I'll be sooooo glad to get rid off.
I'm also focusing on the learning experience and that's why I'm so eager to start this huge update.
Starting over might be indeed a good idea. You can check out my previous article on structuring the app. But if it's a big project, maybe Nx is a better fit.
I am also fond of the container/presenter pattern in Angular, as it makes reading and understanding the data flow much smoother.
What fresh hell of a third-party library is able to hold you hostage 10 major versions behind? Since these libs must be both valuable, stable and more or less abandoned, have you considered to fork or inline them? I found the transition to Ivy rather smooth. But frankly, with that setup, I would run ng new and copy & adjust the app file by file.
Actually it wasn't me. When I got hired they said I would help them to update Angular 'cause they got stuck in there like forever. It still works so I guess they took the "if it's working, don't touch it" too seriously lol.
"if it's working, don't touch it"Up to the moment they either get hacked or audited.
It looks like we are working at the same place :)
Different company, different app, same problems!
😄
With the last one I would argue that you're breaking other principles related to OOP rather than just not following composition over inheritance: you're breaking the SRP (Single Responsibility Principle) as you're giving too many responsibilities to the base class, when it shouldn't.
Your solution is the correct one for this case, but even if you'd have other behavior that should be inherited (and not only a dependency as your example) you could create another abstract «derived» class from the base class that extends it and that could be inherited by the final component. There'sre multiple ways to work things around and they are very dependant on the context. Inheritance has its place and can and should be used, but always with the correct criterion.
Good article.
Cheers.