What is a mixin? As per version , TypeScript now supports the concept of a mixin - a function that can take a class, extend it with some functionality, and then return the new class, allowing other classes to extend from it - allowing classes to mix and share functionalities! 2.2 How it works? The concept is fairly uncomplicated - if we are familiar with inheritance, higher-order classes/functions and their syntax, we can jump right into them. Here is the example from the TypeScript documentation itself: Point { ( ) {} } Person { ( ) {} } Constructor<T> = (...args: []) => T; {}>>(Base: T) { Base { _tag: ; ( ) { (...args); ._tag = ; } } } TaggedPoint = Tagged(Point); point = TaggedPoint( , ); point._tag = ; Customer Tagged(Person) { accountBalance: ; } customer = Customer( ); customer._tag = ; customer.accountBalance = ; class constructor x: , y: public number public number class constructor name: public string type new any < < function Tagged T extends Constructor return class extends string constructor ...args: [] any super this "" const let new 10 20 "hello" class extends number let new "Joe" "test" 0 As we see, we use a function here to create an enriched version of another class, which can be used both to instantiate new objects and to extend other classes. In a sense, this now allows for multiple inheritance - if some of our classes are only needed to share functionality ( class), then we can write it inside a function, so it can be mixed with other classes for further composition. abstract How can this be used? Imagine a usual Angular application with different pages, some of which have forms in them. All is well, then one day we decide, that from now on, if the user has touched a form, but tries to leave the page without submitting it, a window will be displayed, asking the user to confirm if they really want to leave the page (a very standard feature). Of course, the first thing that comes to mind is a . Because our app is designed in a good fashion, (but all!) components with forms in them have a generic field, which is an instance of . Of course, from then we can check the field of the property and find out whether it is necessary to show a prompt. The guard can look like this: Guard most of the not form AbstractFormControl touched form FormTouchedGuard CanDeactivate<{form: AbstractFormControl}> { canDeactivate(component) { component.isFormTouched() ? confirm( ) : ; } } export class implements return 'Are you sure you want to leave?' true Of course, this looks good on paper, but in reality, as mentioned briefly above, not every single page works like this - some pages have multiple forms, some pages have forms inside their child components, some have both. Of course, we want the guard to work in the same way for each component, and we also want to be very precise and consistent. So here is a thought: from now on, every component that should have this guard on it, should implement a special method called , which will return a to tell the guard if it has to show the prompt or not. Here is an example of a more complex component, who has a form inside itself and another form inside its child, and how it implements the method: isFormTouched boolean FormCheck { isFormTouched(): ; } ({...}) SomeComponent FormCheck { ( ) nested: SomeOtherComponentWithForm; isFormTouched() { .nested.form.touched; } } interface boolean @Component export class implements @ViewChild 'nested_component' return this Of course, this is great, but for most components (like, 90%) the method comes down to just this: isFormTouched ({...}) SomeComponent FormCheck { form: FormGroup; isFormTouched() { .form.touched; } } @Component export class implements return this Of course, we can copy and paste this method to each and every component in which we need it, but that action in itself already smells fishy, right? Another reason we don't want a solution like this is because one day, it may be also required to check if the form has already been submitted (using an property on the same class, for example). Of course, that would require us to rewrite of code. And if we miss one - it may be ages before someone finds out such a minor bug. So, naturally, we want a solution which lets us write that particular method , but still sharing it among all our components that need it. Obviously, inheritance comes to mind - but here are three fundamental downsides to it: isSubmitted lots just once Idiomatic: inheritance is meant to represent an relationship (as in "a horse is an animal"), rather than share functionality. Dependency injection or object composition are used for that. is-a Paradigmatic: what should this class even represent? In some OOP languages a concept called a is present, which allows such things, but in JS we don't have such a feature, so our classes should represent something, not just contain one simple method. trait Practical: what if in the future we need to extend our component from another base class? Our hands would be tied in that case. Mixins to the rescue Take a look at this function: {}>>(Base: T = ( {} )) { Base FormCheck { form: FormGroup; isFormTouched() { .form.touched; } } } < < function WithFormCheck T extends Constructor class as any return class extends implements return this As you see, this function takes a simple class (which can also be an Angular component) and returns another component, which extends from it and also has the method implemented on it. We can than do this simple thing: isFormTouched ({...}) SomeComponent WithFormCheck() { } @Component export class extends // other code Here is how this functions solves all of the three issues mentioned above: Because it is named , it now represents a class (which it can get as an argument - or without it, notice the line, which basically means that if no class is given, en empty one will be extended) that was enhanced with some additional features. WithFormTouchedCheck Base: Constructor<T> = (class {} as any) This function is not a class in itself and only represents a functionality that it adds to an existing one - granted it implements a certain interface. Because it accepts another class as an argument, it now allows us to extend our component from other classes too. As a matter of fact, as long as we keep this format, we can have as many classes as we want! Mixing thing up I am sure many of us have heard the scary stories about , and how we can avoid them by using the operator. Of course, we would also need to create a specific for that, and send a notification inside our method. In fact, here is the code: zombie subscriptions takeUntil Subject next ngOnDestroy HasSubscriptionComponent OnDestroy { destroy$ = Subject< >() ngOnDestroy() { .destroy$.next(); } } export class implements new void this Of course, many of our components may have subscriptions inside them, and of them should implement this same functionality, so it makes sense to make it a mixin: all {}>>(Base: T = ( {} )) { Base OnDestroy { destroy$ = Subject< >() ngOnDestroy() { .destroy$.next(); } } } < < function WithDestroy T extends Constructor class as any return class extends implements new void this Of course, a component that uses our previous mixin may also need this new one, but it is extremely easy to combine them: HasSubscriptionComponent WithDestroy(WithFormCheck()) { } export class extends // other code : we implemented the method in our mixin: if you are going to use it in a class that will also itself implement the method, be sure to call inside it! Be careful ngOnDestroy ngOnDestroy super.ngOnDestroy() Cons Of course, every approach in programming may have some downsides to it. Most of them in our case are related either to some Typescript compiler specific issues, or to Angular build issues. Here I present two of them, which may be the most frustrating ones. 1. issue: Decorators are not valid here If we try to use a decorator inside our mixin like this: {}>>(Base: T = ( {} )) { Base { () ; } } < < function WithInputs T extends Constructor class as any return class extends @Input type We will get an error which says . This is in fact an with Typescript compiler. Here is a workaround: Decorators are not valid here issue {}>>(Base: T = ( {} )) { Temporary Base { () ; } Temporary; } < < function WithInputs T extends Constructor class as any class extends @Input type return Somehow Typescript is only okay when we put decorators on a named class. 2. Angular Inputs issue: If we include a decorator on one of our mixin classes to, for example, define an property on the class, it will work as intended when we our application, but will throw an error during a production build. This is related to this . A workaround for this is a bit messier: Input ng serve issue ({ inputs: [ ], }) SomeOtherComponent WithInputs() { } @Component // other metadata 'type' export class extends // other code This is of course more work to do on a child component, and Angular's own style guide does not approve the usage of the array in the decorators, but this is still a workaround. I personally don't mind it, until the Angular team provides us with a solution. inputs Conclusion Typescript mixins are a great way to enhance our Angular app with shared functionality without breaking any flow. While this technology still has some small downsides, I personally believe its benefits vastly outweigh them.
