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
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.