This project is read-only.

Using typeof for mixins

Topics: General
Aug 23, 2013 at 6:40 PM
I just realized the new typeof operator works great for mixins, as you can just use it to get the signature of functions outside the current class.

Did a test with Backbone importing the mixins from underscore, and it works great, imports all overloads at once and doesn't require us to keep track of overloads when the dependent library changes.
class Model {
    keys: typeof _.keys;
    values: typeof _.values;
The only thing is that it imports the declaration as a property instead of a method, but that doesn't affect anything.

In the roadmap, it states that mixins are planned for after 1.0. I was wondering, what else are you guys planning for mixins for the future?
Aug 25, 2013 at 10:25 AM
Additionally one may wish to import a mixin class entirely:
class Foo {
  public getFoo(){}

class Bar {
 private mixin foo = new Foo();

var bar  = new Bar();
bar.getFoo(); // okay

Aug 26, 2013 at 1:29 PM
Edited Aug 26, 2013 at 1:29 PM
Right, a simpler way to include mixins for implementations.

I'm not sure if naming the mixin would be a good idea. It could be used to save a reference for naming conflicts, but in this case you could just do what you just did without the "mixin" keyworkd, it would be an ambiguous feature.

Here is an idea:
class Bar {
    mixinMethod() { }

class Foo {
    mixin Bar;
    ownMethod() { }
Foo would be compiled to something like:
var Foo = (function () {
    function Foo() {
    // appear before own class methods, can be overriden just by creating a method with the same name
    Foo.prototype.mixinMethod = Bar.prototype.mixinMethod;
    Foo.prototype.ownMethod = function () { };
    return Foo;
In this case, mixins would be imported in the order they are declared, before own methods, doesn't matter when the mixin keyword appear in the class implementation.

This could work this way:

Import all members
mixin ClassName;
Import only specific members:
mixin ClassName { methodA; methodB; methodC; }
This syntax would work fine for interfaces as well, without requiring instantiation.

You could add private or public before those, but I suppose the idea of a mixin is to get methods from other places to expose them as part of your own class. Private mixins don't make much sense to me. If you want to use them internally, just use the library directly, there is no need to make them part of the declaration.
Aug 26, 2013 at 5:34 PM
@nvivo, it's not as simple as that. Consider:
    class Bar {
        name = "bar";
        mixinMethod() {

    class Foo {
        name = "foo";

    Foo.prototype["mixinMethod"] = Bar.prototype.mixinMethod;

    var foo = new Foo();
    foo.mixinMethod(); // Alerts "foo" instead of "bar"
Basically, Bar won't be able to reference any of its instance members in its own methods.

Also what if we want to pass in constructor arguments to Bar?

The mixin strategy is
  • A one-off copying of the mixin methods onto the target's prototype.
  • The mixin is instantiated in the target's constructor and the mixin instance properties are copied into the target instance.
See also:
Aug 27, 2013 at 5:08 PM
I don't see why I would use a mixin if I need to track a different state than the object I'm in. I'd just instantiate a private member then.
You may be trying to solve a different problem, that is of automatically encapsulating methods of an instance in your class.

The idea of a mixin is to add functionality that is not part of your class implementation, but still be the same class. They should make use of the same state, or if they need extra stuff, they should create the state members they require.

Also these methods must be suitable for mixin. You don't want to mixin random methods of libraries that require lots of private variables to work and were never meant to work outside. So, if a mixin overwrites a private variable, you should know that before mixin that function. Typescript won't be able to check if the variable the mixin depends should exist on the class or is specific to the mixin.

I think using instances complicate too much.
Let's first go with we have been doing in javascript, that is to copy method around and make it simple so typescript can see their signatures and check for errors.
Aug 27, 2013 at 8:12 PM
I follow what you're saying, but I'm rather not in favour of that because it would introduce a tight coupling between the mixin and the target.

It makes it necessary to have to document the mixin along the lines of "In order to use this mixin, the target must define a property called 'foo'" etc. This smacks of an old school JavaScript hack.

For someone reading the target class in isolation it would not be clear of the purpose of the "foo" and other properties, defined there purely for use by the mixin.

The solution is to define an extends method that takes an instance of the mixin. A good developer would keep the mixin very simple, but the compiler can help by perhaps warning if any properties are in danger of being overwritten.

Contrary to your claims this is how mixins are understood in the outside world. Mixins are generally defined as object literals, but because we're dealing with types in the TypeScript world, we need to substitute with an instantiated class.