Hi Andrei, thanks for reading!

I think creating helper methods through a service (or maybe better, helper methods imported as functions?) is a viable solution with no clear downsides: I should have probably mentioned it!

It’s always a good idea to put logic outside of the component if this is reusable:

  • via services/helper methods
  • pipes

Regarding the downsides you mentioned, which is understandable:

  • the fact that the components share a lot of properties is a sign that you should break up the component in multiple smaller components
  • I don’t think there’s a specific number of props (inputs, outputs, methods) to keep in mind, it always depends on the context

When I start architecting a component, I think:

  • can this component be split into multiple components?
  • can I offload some of the methods’ logic to reusable pipes?
  • if no (for whatever reason): can I split the class into multiple classes and share them together?
  • if no (for whatever reason): can I extend 1 time and 1 time only this component?

At the end of the day, having to repeat a few times some components (for example, compose a few components in different templates) is still a better solution than having a big, highly configurable, inevitable messy component, which is what usually class inheritance may lead to.

Giancarlo Buomprisco

Written by

UI Consultant, VP @barclays & Blogger. I write about JS, TS, Rx, Angular & all things Front End 🇬🇧 🇮🇹 — write me at gc@frontend.consulting!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade