Along with traditional OO hierarchies, another popular way of building up classes from reusable components is to build them by combining simpler partial classes.\nYou may be familiar with the idea of mixins or traits for languages like Scala, and the pattern has also reached some popularity in the JavaScript community.
\nThe pattern relies on using Generics with class inheritance to extend a base class.\nTypeScript’s best mixin support is done via the class expression pattern.\nYou can read more about how this pattern works in JavaScript here.
\nTo get started, we’ll need a class which will have the mixin’s applied on top of:
\n\ntsclassTrySprite {\nname = \"\";\nx = 0;\ny = 0;\n\n constructor(name : string) {\n this.name =name ;\n }\n}
Then you need a type and a class which
\n\nts// To get started, we need a type which we'll use to extend\n// other classes from. The main responsibility is to declare\n// that the type being passed in is a class.\n\ntypeTryConstructor = new (...args : any[]) => {};\n\n// This mixin adds a scale property, with getters and setters\n// for changing it with an encapsulated private property:\n\nfunctionScale <TBase extendsConstructor >(Base :TBase ) {\n return classScaling extendsBase {\n // Mixins may not declare private/protected properties\n // however, you can use ES2020 private fields\n_scale = 1;\n\nsetScale (scale : number) {\n this._scale =scale ;\n }\n\n getscale (): number {\n return this._scale ;\n }\n };\n}
With these all set up, then you can create a class which represents the base class with mixins applied:
\n\nts// Compose a new class from the Sprite class,\n// with the Mixin Scale applier:\nconstTryEightBitSprite =Scale (Sprite );\n\nconstflappySprite = newEightBitSprite (\"Bird\");\nflappySprite .setScale (0.8);\nconsole .log (flappySprite .scale );
In the above form, the mixin’s have no underlying knowledge of the class which can make it hard to create the design you want.
\nTo model this, we modify the original constructor type to accept a generic argument.
\n\nts// This was our previous constructor:\ntypeTryConstructor = new (...args : any[]) => {};\n// Now we use a generic version which can apply a constraint on\n// the class which this mixin is applied to\ntypeGConstructor <T = {}> = new (...args : any[]) =>T ;
This allows for creating classes which only work with constrained base classes:
\n\ntstypeTryPositionable =GConstructor <{setPos : (x : number,y : number) => void }>;\ntypeSpritable =GConstructor <typeofSprite >;\ntypeLoggable =GConstructor <{
Then you can create mixins which only work when you have a particular base to build on:
\n\ntsfunctionTryJumpable <TBase extendsPositionable >(Base :TBase ) {\n return classJumpable extendsBase {\njump () {\n // This mixin will only work if it is passed a base\n // class which has setPos defined because of the\n // Positionable constraint.\n this.setPos (0, 20);\n }\n };\n}
Previous versions of this document recommended a way to write mixins where you created both the runtime and type hierarchies separately, then merged them at the end:
\n\nts// Each mixin is a traditional ES class\nclassTryJumpable {\njump () {}\n}\n\nclassDuckable {\nduck () {}\n}\n\n// Including the base\nclassSprite {\nx = 0;\ny = 0;\n}\n\n// Then you create an interface which merges\n// the expected mixins with the same name as your base\ninterfaceSprite extendsJumpable ,Duckable {}\n// Apply the mixins into the base class via\n// the JS at runtime\napplyMixins (Sprite , [Jumpable ,Duckable ]);\n\nletplayer = newSprite ();\nplayer .jump ();\nconsole .log (player .x ,player .y );\n\n// This can live anywhere in your codebase:\nfunctionapplyMixins (derivedCtor : any,constructors : any[]) {\nconstructors .forEach ((baseCtor ) => {\nObject .getOwnPropertyNames (baseCtor .prototype ).forEach ((name ) => {\nObject .defineProperty (\nderivedCtor .prototype ,\nname ,\nObject .getOwnPropertyDescriptor (baseCtor .prototype ,name )\n );\n });\n });\n}
This pattern relies less on the compiler, and more on your codebase to ensure both runtime and type-system are correctly kept in sync.
\nThe mixin pattern is supported natively inside the TypeScript compiler by code flow analysis.\nThere are a few cases where you can hit the edges of the native support.
\n#4881You cannot use decorators to provide mixins via code flow analysis:
\n\nts// A decorator function which replicates the mixin pattern:\nconstTryPausable = (target : typeofPlayer ) => {\n return classPausable extendstarget {\nshouldFreeze = false;\n };\n};\n\n@Pausable \nclassPlayer {\nx = 0;\ny = 0;\n}\n\n// The Player class does not have the decorator's type merged:\nconstplayer = newPlayer ();\nplayer .;\nProperty 'shouldFreeze' does not exist on type 'Player'.2339Property 'shouldFreeze' does not exist on type 'Player'.\n// It the runtime aspect could be manually replicated via\n// type composition or interface merging.\ntype shouldFreeze FreezablePlayer = typeofPlayer & {shouldFreeze : boolean };\n\nconstplayerTwo = (newPlayer () as unknown) asFreezablePlayer ;\nplayerTwo .shouldFreeze ;
#17829More of a gotcha then a constraint.\nThe class expression pattern creates singletons, so they can’t be mapped at the type system to support different variable types.
\nYou can work around this by using functions to return your classes which differ based on a generic:
\n","headings":[{"value":"How Does A Mixin Work?","depth":2},{"value":"Constrained Mixins","depth":2},{"value":"Alternative Pattern","depth":2},{"value":"Constraints","depth":2},{"value":"Decorators and Mixins #4881","depth":4},{"value":"Static Property Mixins #17829","depth":4}],"frontmatter":{"permalink":"/docs/handbook/mixins.html","title":"Mixins","disable_toc":null,"oneline":"Using the mixin pattern with TypeScript"}},"prev":null,"next":null},"pageContext":{"id":"mixins","slug":"/docs/handbook/mixins.html","repoPath":"/packages/documentation/copy/en/reference/Mixins.md","lang":"en","modifiedTime":"2020-08-07T17:00:36.339Z"}}}tsfunctionTrybase <T >() {\n classBase {\n staticprop :T ;\n }\n returnBase ;\n}\n\nfunctionderived <T >() {\n classDerived extendsbase <T >() {\n staticanotherProp :T ;\n }\n returnDerived ;\n}\n\nclassSpec extendsderived <string>() {}\n\nSpec .prop ; // string\nSpec .anotherProp ; // string