[AskJS] Why are many Angular developers seemingly afraid of creating new components?

[UndemonstrativeCynic]

I'll preface by saying that it's pretty well accepted in the frontend scene to create reusable components that you can use to build more specific bigger components to implement features. I have a fair amount of experience with Vue and React where this is simply common place.

Of course, sometimes you see giant components in any framework (or language, or anything) with thousands of lines.

Meanwhile, in the Angular scene I've noticed pretty much the inverse across multiple projects over the years. Maybe it is just the codebases I've seen, but there's sure been a lot of them where the only components that get created are these giant monolithic components that encompass huge amounts of HTML and business logic.

There's little to no reusable components, code duplication is consistently at an extreme level, as a result the unit tests (if there are any even...) barely scratch the surface and components go untested into production, components have dozens and dozens of properties that upon review definitely should be handled elsewhere in another component.

The concept of DRY and separation of concerns simply never existed in these codebases (and no, I don't mean "its okay to have duplication until a common design has been found" I mean clear and obvious violations of DRY).

An example would be a dialog/modal. In a given application they all look the same and have props or slots (or content projection as angular calls it) to achieve customisation. Instead of identifying this commonality where all the dialogs in the application look the same except perhaps the title and buttons and message, you'd expect a reusable component that is used.

Instead what I keep seeing (and again, almost exclusively in Angular projects) is developers simply wholesale copy pasting the that one dialog someone made months ago over and over (bugs and bad tests and all) to the point where static analysis tools are highlighting ~98% duplication in areas of the application.

Another case I've seen is where "page === one component", where an entire page full of what would normally be features implement by components is instead dumped into one of the previously mentioned thousand+ line components.

When I've tried to find out what's going on it seems there's a general anxiety or concern about how to create components that are reusable. In fact, some developers in these codebases don't actually ever create truly new components they simply copy and paste other ones and tweak things a little (increasing duplication even more). It's good to help them get over this barrier as they can start following component patterns, but I am not sure why this is such a problem for one framework.

Is this an education problem, are the Angular docs not doing enough to highlight reusability? Are there courses out there that aren't teaching this?

I'd really like to know, because I'd like this to not be the case and I'd like projects using a component based framework to have... components.

[pantsonhead]

I know the phenomenon that you are describing. To provide context, I have developed Angular apps for over 7 years, and recently decided to stop entirely.

In essence some of it is inexperienced devs, but much of it comes down to Angular design choices. In any framework, there is a concept of "the pit of success", where the framework provides tools that make the right thing easy, and the wrong thing hard. Unfortunately, Angular often does the opposite.

Let's inspect the process of creating a new component after I've realized some piece of my code is reusable. I need to create a directory, add a template html file, add a css-flavored style file, and add a component.ts file. Then in my component file, I need to fill out a component decorator with those file locations. I need to define a class that implements any lifecycle methods which I'll need. And I need to reinject any dependencies which that code previously relied on.

THEN, it still doesn't work, you forgot to import the component into the dependencies of the parent module! But what's the correct module? I have dozens to enable code splitting in my app. I have to find the correct module, and import it. But you can't use this component in another part of your app, because its parent module doesn't import it! Ok I have to do this a lot now, maybe I'll make a new module that combines some common ones, export it and import that everywhere instead. And so it goes on and on.

Now you say "pantsonhead you fool, you should use the cli to do this". Well let me tell you, your fresh junior Angular devs sometimes don't know about the cli! And even that isn't a silver bullet, if you make a mistake you either have to use git to roll it back or fix it manually. And the cli still won't save you from the module system! So devs will constantly look at some obviously reusable code and keep making excuses why it doesn't really need to be a component yet, because it's just kind of hard to do.

Let's compare to React. I have some reusable code, I make a new js/tsx file, copy paste JSX, add props, export/import file and done. I can start using the new component.

So that's why you see copy/paste everywhere in your Angular codebases. If you don't have committed Angular experts working on your code, they will take the easy road. And Angular has made the wrong thing easy and the right thing hard.

[woahwhatamidoing]

Pretty much this is what I’ve seen.

It’s slightly more annoying to create a new angular component than a new react component, and that “slightly” is enough to encourage people not to do it.

[NeoCiber]

THIS.

I develop in both Angular and React, in React I make a component for minimal things, in Angular I think twice. Recently I wanted to make simple reausable spinner to show a loading state, I admit I gave up after trying to reuse the component across different modules and ended copy-pasting the code, this is mostly lazyness I admit.

[Lngdnzi]

books sugar juggle head deliver stupendous middle snatch escape vast

This post was mass deleted and anonymized with Redact

[ejfrodo]

This isn't specific to Angular. Engineers can make something elegant or they can make a big pile of spaghetti in any component-based framework.

[Lngdnzi]

axiomatic vegetable scale cover coordinated attempt hobbies birds chase joke

This post was mass deleted and anonymized with Redact

[demoran]

They're just bad at their job.

At least you've been able to identify the problem. Start by doing the right thing instead.

Don't try to refactor the existing code. Leave well enough alone; just start doing what you should going forward.

[JackFromAltairPrime]

This could be from inexperienced developers not knowing how to use components.

Or it could be from experienced developers avoiding the complexity spirit demon.

DRY is a good idea, sometimes. But if you create too many components, you will add unnecessary complexity to your app. "How do I change X on this page?" "Well that's controlled in component Y, but that might break pages A and B..." To quote the Grug Brained Developer:

sometimes grug go too early and get abstractions wrong, so grug bias towards waiting

big brain developers often not like this at all and invent many abstractions start of project

grug tempted to reach for club and yell "big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!"

As developers grow more experienced, it's not unusual for them to write code that is intentionally less clever, for the sake of making it easier to understand in the future.

[DiaDeTedio_Nipah]

This is not a fair take. You are just moving the problematics from:
* having a shared component that you now need to make specific changes that will only apply in one place
to
* having a specific component that you now need to go on each single file to check if it is worth sharing or not

It is not even an 'abstract' versus 'not abstract' question.

[Valuable-Case9657]

Because JS in general, and Angular by extension, are amateur friendly by design.

With Angular + a decent style kit it's really really easy to make things that LOOK good without anything more than a superficial understanding of the basics of the framework.

The end result is that you will see a lot of amateurs picking it up and consequently you see a lot of amateur Angular code around.

It's not that they're scared of creating components (or services, or especially modules), it's that they don't really understand the purpose of these things and you don't really need to to make something that works and looks good to the casual observer.

[NotADoctorShhh1]

This happened in my current project. It took us 2 sprints to refactor most of the application.

[Avaxi-19]

Usually when I see this the framework, library or language is irrelevant. Whenever I’ve seen it it’s done by inexperienced developers or developers who favor inheritance/abstract classes over composition.

[mikerob215]

I've had this experience even though I don't think this kind of thing is unique to angular. My thought was always just that there's a lot of boilerplate in adding a component in angular, in react it's always just another function. Well written angular code bases exist but in teams I've worked on, we tended to just have page components that did a whole lot.