After 11 months, I got my 1st UI story. I've been doing Back-End for the Front-End stories since we're a platform team, so 100% of the code you never visually see in the UI, but they affect how it works, so the Acceptance Tests in Cypress still have to pass.
Anyone who says "Angular's nice because it has a prescribed way of doing things" hasn't been on more than 1 Angular project. I can confidently say this is the 3rd I've seen in 8 years, and it's extremely different than every other Angular 2+ project I've seen. Even Angular itself has multiple ways to do things nowadays, and surprisingly, the testing is the most varied. The documentation on testing has not kept up with the reality of how much the Jest style of "mutate the object directly, with type safety". The Java-esque expectation style with manual steps required to test HTTP is now thankfully not used by most that I've seen.
One thing I've noticed in creating my 1st component in years is it only requires 1 class method; ngOnInit. The rest can just be functions. There is no need for the OOP nonsense that was never really agreed up on regarding "should this be a method, static method, getter, setter, base class override, or abstact base class override". Now it's just "function" to answer all questions where your code goes. If you need state, the class is right there and the functions can just use manual dependency injection if they need access to that state.
I remember the concern with Angular not keeping up with the industry moving away from classes as a core architectural building block. Web Components / Lit are the only ones I've seen embrace this, but they don't have a choice because that's in the spec for how they work, and "extending HTMLElement" is basically here for as long as the internet exists.
Either way, that concern is negated after getting my hands dirty. It feels pointless using a class now, like Scala/OCAML/F# devs using class in a language that is soundly FP and have zero state in them. Beyond that, I can code Angular like I'd code any other framework; mainly pure functions, 1 or 2 with state; test first with unit tests validating where the types leave off, and Acceptance Tests to ensure all the side effects do what they're supposed to do.
The RxJS return types are about as intelligible as React's component types; meaning "I can't read them", BUT as long as you recognize the return value from switchMap and map are different once you start piping things, it feels very much like a Promise.then chain. You end up code that is extremely co-located, and a lot less of it; something that always drove me nuts with class based code: more of it, and spread out, and way too easy no to co-locate things.
I'm not going to admit I'm enjoying it, but I will say it's amazing how much a strong testing culture + strong types + convention of immutability (don't mutate things) can make a huge positive impact on developer happiness regardless of language/framework/implementation details.
The Mocks vs. Stub debate is a whole other rant entirely, but even with that unsolved, like I said, I'm extremely surprised how productive I can be in something that feels extremely dated. If there is 1 thing I learned from getting into motorcycles 2 years ago, it's that what one person views as old/dated technology is "perfect" for someone else. It's just disappointing you often don't get a choice on which tech to use in your career as often as you want.
SOCIAL SHARE CARD GENERATOR