#Component Best Practices (Hierarchy and Extending/Implementing)

52 messages · Page 1 of 1 (latest)

lofty panther
#

I have inherited a Frontend tool and it it a mess in SO many ways but I'm looking for suggestions on this particular piece.

I'd love to have a voice chat to talk this out if anyone is available and interested in being my rubber ducky.

I am a beginner-to-moderate skill level with Angular so I know lots of vanilla best-practices for coding and JavaScript but getting a little confused with some of what I think are Angular specific things. I've probably just been staring at this bad code for so long that I'm losing sight of how where to start and how to stop the bleeding.

my app directory:

manage-rules/ clone-rule/ clone-rule.component.ts add-rule/ add-rule.component.ts edit-rule/ edit-rule.component.ts manage-rules.component.ts

Each of these components is made by implements OnInit no actual extending of a base class or anything like AddRuleComponent implements ManageRulesComponent or AddRuleComponent extends ManageRuleComponent which is I think what I was expecting to see.

How would you go about arranging this structure or implementation? The actions for each of these can be assumed by the names of the components and I don't think I need to go into more detail for this example. There is SO MUCH duplicated code between these three or four components and I want to condense and eliminate duplicate code.

My gut reaction is that I want to refactor so that ManageRules is the base class and the others implement or extend the base class.

Ping me if someone is interested in talking it through with me - again I'm not very good at writing a concise problem statement when there is so much bad code going on.

sly belfry
#

It is generally recommended not to use inheritance for components.
Even outside of Angular "inheritance for code-reuse" is usually considered an anti-pattern.

How to best "DRY this" would depend on what the duplicated code does. Some possibilities are:

  • Moving the code to a service
  • Moving the code to one or multiple directives
  • Moving shared code to one or multiple shared components
  • Merging components (for example an "add new" and "edit existing" form can often be the same).

But it really depends on what the code does.

lofty panther
lofty panther
#

The functions in these are also very similar - CRUD type functions to a database for "rules" in this case. I'd like to combine them all but that feels a little too big of a lift so I want to try and move duplicate code to a shared component.

sly belfry
lofty panther
#

Could ConfirmDialogs be moved to a common component? Or is there some juggling with rendering on the correct rendered page?

sly belfry
lofty panther
#

There are HTML files for each of these components as well. Part of the problem.

sly belfry
lofty panther
#

I like that example of directives. I will read into it more and try and utilize those where I can. Perhaps a way to use the same input form between Add/Edit/Clone but have the directive set which CRUD function is taking place?

sly belfry
#

Not sure why you would need a directive for that. You could just write an input. If it really is the same form, why not this:

<!-- edit existing instance -->
<app-foo-form [existing]="existingInstance" [mode]="'edit'" />
<!-- clone existing instance -->
<app-foo-form [existing]="existingInstance" [mode]="'new'" />
<!-- create new blank instance -->
<app-foo-form [mode]="'new'" />
lofty panther
#

I'm still learning the code I've inherited - it's a beast. I'm finding some minute differences in the checks and validation between the forms and it's unclear yet if it is just poorly maintained and updated or if it is different with a purpose behind it

#

I think I might just have to smash them together like this and test the heck out of it to validate functionality is the same

lofty panther
sly belfry
#

Yes, what I wrote above is perfectly possible. Not to be too blunt, but if you don't know what inputs are in Angular you are probably not in a position to refactor any code. They are a fundamental concept

lofty panther
#

Understood - again beginner to Angular here, willing to learn and keep moving forward. Just drinking from a hose is what it feels like at the moment

#

I'm just not aware of all it can do yet and it is clearly a lot! Excited if it can do all that

sly belfry
#

Have you worked with a different frontend framework before?

lofty panther
#

More vanilla than anything else. Some Meteor back when that was more popular.

sly belfry
#

Okay. You should definitely go through like... the basics on https://angular.dev/essentials then, because it is pretty different from doing vanilla js dom manipulation

lofty panther
#

I've done more backend than frontend but I've had some sprinkles of a couple different frameworks. Like Bootstrap and React (also very little)

sly belfry
#

If you've used React you should know the term "props". Inputs in Angular are the same idea.

lofty panther
#

I see - I grok what you mean in that they are properties of an element or some similar jargon. It's harder to context switch than I imagined though

sly belfry
#

Well, they are really more like inputs, they tell the component what to do

lofty panther
#

I'm getting an impression that these Components in Angular can be much more granular than my inherited app is using them today. There are being used almost like on single a page-by-page basis and nothing smaller than that.

sly belfry
#

Yes that is definitely not the way to go

#

You should make components as small as they can be and as large as they need to be, which is kind of a vague statement

lofty panther
#

Should a "page" even need to be defined as a Component? Like as a Component made up of smaller (possibly) reusable Components?

sly belfry
#

Yes, anything in Angular is a component

#

You cannot put stuff on the page in Angular without writing a component.

#

You have a root component (usually named AppComponent and selected via <app-root>). That contains your entire app

#

Then if you are using the Angular router there will be one (or possibly multiple) components per route (read "page") and those will almost always use other components within them

lofty panther
#

I see ok so that is still a backbone concept - these other devs just never explored more DRY proctices beyond parent-most component idea that it would seem.

sly belfry
#

For example, if you have a button that follows your CI, that would be a component

#

And everywhere you need a button, you use that component instead of copy-pasting its markup

lofty panther
#

Would it be good practice to keep all components in their own individual files? Or do other devs define multiple like-components in one file?

sly belfry
#

I haven't seen multiple components in one file outside of small demos.
But in theory nothing is stopping you from doing that.

lofty panther
#

I see - I just want to try and not repeat mistakes and create more for readability and organization.

sly belfry
#

There is a style-guide, which is a good thing to follow https://angular.dev/style-guide
Note that it was recently updated, so most likely the app you inherited does not follow it, especially regarding the name of files.

lofty panther
#

I have a sense of what I would do - but I'm working alone on this so I want to align with what others do in the industry that use Angular if I can

lofty panther
delicate belfry
#

note: nothing in that post is set in stone, you can organize a project however you like. but it's a sensible approach that should work for most projects

lofty panther
#

Thank you @delicate belfry ! Adding this to my read list as well

sly belfry
#

That's a great post, from skim-reading it this is roughly how I've been doing it anyways

delicate belfry
#

Yeah, it's kind of a unofficial community standard. Many people have adopted similar approaches

delicate belfry
lofty panther
#

The real-world-example app is really helpful too - thank you again for that link. I think I have the capability to do a lot of this stuff and rework this app with some autonomy it is just going to take a lof of work and time to do so.

#

The kind of work that you really really want to nuke it and start from scratch but I'm sure I can't do that

sly belfry
#

Yeah technical debt is not fun, but "nuke it" is almost never a better option

lofty panther
#

Yeah I've made that mistake before - felt good in the moment but I know better now how it's more harm than good. Good learning experience here in my current situation too!