In this article, I will do my best to explain why I believe having BaseComponent in your Angular project is a bad option for code sharing. And the ...
For further actions, you may consider blocking this person and/or reporting abuse
I agree with the main point of this article but there is no need to reject the Angular components inheritance in all cases. For example, there is nothing wrong with creating a base component class for a given feature component (not a global one for all possible components).
Consider a situation where you have multiple similar components like with some kind of a form, and all of them have the same form setup etc., but they do have additional different fields. If that would be for example a BaseInvitationComponent, the child components actually are InvitationComponents, so it sticks to what you have mentioned that object A is a subtype of object B, and not the case where a piece of unrelated functionality is needed.
@dmrowiecpl The article is mostly focused on the umbrella
BaseComponentthat tends to accumulate many utility methods (an sometimes even domain logic methods) over time, needed by different unrelated components/modules in your app that have no hierarchical connection between them.I'm not strictly against using inheritance in Angular. As any other technique it can serve you well when used in the right place for the right type of component relationship, like in your case.
But at the same time, even in such cases framework offers a lot of powerful alternatives that promote composition over inheritance. And these usually allow you to achieve the same goals, making code more flexible at the same time.
Well, you need to maintain clear approach with your entire team, because: when class is starting to seem that it could use Input(), then it have decorator on top of it, then you decide to move to OnPush, then your base class is not just an sugary “abstract” class meant for extension anymore - it’s a separate compilation and hence requires “super” calls in every “overriden” method, then it becames a complete mess. Angular team guided us with an article “composition over inheritance”. They know pitfalls of framework and try to keep us from pattern, which is unusable in our context.
Thinking of Angular like template-first approach guarantees us very stable developer experience.
yes the fact that it starts its whole arguments saying "if you use inheritance wrong its not good", so its basically a strawman blog, if you're using class extension as a way to import generic functions, you are doing it wrong but thats not a good argument not to use component Inheritance correctly.
I have tables, and forms and modals that need inheritance, I need ALL the functionality, I may need to override one or two function for edge cases or add extra logic before I call super.ngOnInit.
a huge grossness in JS that is completely solved by this is input hell mixed with endless ifs to make a single component dynamic enough if(isEdgeCase) do extra step here.
over ride one function of a working form/table/modal to cater for your niche edge case component is much cleaner than adding more and more inputs to handle different scenarios that are one off, that happen as an app grows
Whenever I see any component extending another class, I tremble.
Global inheritance always leads to issues, nice article!
What if we make BaseComponent as a directive and use it as
hostDirectives: [BaseComponent]?@pankajparkar I think it solves some of the problems outlined, but not all of them. You still don't get to choose what to inherit, still creates stronger coupling in the app...
Also, even when
hostDirectivesis the right tool to use for your shared feature, I see no reason why not prefer splitting the shared logic into separate directives. Gives you more flexibility in any case:hostDirectives: [SharedLogicDirectiveA, SharedLogicDirectiveB]Completely agree with you.
Very well explained 👏🏽👏🏽👏🏽
This article is saying inheritance is bad by using the worst examples of inheritance that no one should ever use. That's not a reflection on inheritance, it's bad programming.
Why in the world would anyone put form or validation logic in a BaseComponent?
This is terrible. First of all, having a base component doesn't mean that's all you have. in other words, by actually DESIGNING a class structure (having other classes BETWEEN the base component and app components) the proper components get to share methods without polluting anything. Delving into a proprietary way to do what's been done with conventional OO just means you get to be an Angular expert instead of a JS code expert. THEN you advocate polluting VIEWS with domain knowledge about roles! A properly designed application using HATEOAS principles doesn't even need to know what role a session user is in the browser code. I stopped reading at that point. You have a lot to learn about programming. You should be reading instead of writing. Strive to be a better programmer instead of striving to be famous at programming.
This is what we get when script kiddies and HTML coders try to pretend they are developers by "learning" things like Angular and calling themselves "front end developers". No actual understanding of core underlying software development concepts.