question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

feature request: support for mixins composed from other mixins.

See original GitHub issue

Search Terms

Suggestion

At the moment, it seems to be very difficult to compose mixins from other mixins.

Here’s an example on StackOverflow: https://stackoverflow.com/questions/56680049

Here’s an example on playground.

The code:

type Constructor<T = any, A extends any[] = any[]> = new (...a: A) => T

function FooMixin<T extends Constructor>(Base: T) { 
    return class Foo extends Base { 
        foo = 'foo'
    }
}

function BarMixin<T extends Constructor>(Base: T) { 
    return class Bar extends FooMixin(Base) { 
        test() { 
            console.log(this.foo) //  PROBLEM: this.foo is 'any' =(
        }
    }
}

Use Cases

To make it simpler to make mixins (and compose them) like we can in plain JavaScript.

I’m porting JavaScript code to TypeScript, and the JavaScript makes great use of mixins (including composing new mixins from other mixins), but the composition ispractically impossible to do in TypeScript without very tedious type casting.

Examples

Here is the plain JS version of the above example:

function FooMixin(Base) { 
    return class Foo extends Base { 
        foo = 'foo'
    }
}

function BarMixin(Base) { 
    // BarMixin is composed with FooMixin
    return class Bar extends FooMixin(Base) { 
        test() { 
            console.log(this.foo) // this.foo is obviously inherited from FooMixin!
                           // ^--- This shoud not be an error!
        }
    }
}

It seems to me, that the type checker can realize that the class returned from FooMixin(Base) will be a typeof Foo. The type system could at least be able to allow the Bar class to use methods and properties from Foo, despite not knowing what the Base class will be.

You can also imagine this problem gets worse with more composition, f.e.

    return class Bar extends Foo(Baz(Lorem(Ipsum(Base)))) {

It should also be possible to constrain the constructor to inherit from a certain base class. For example, the following doesn’t work:

(EDIT: this part may actually be moved to a separate issue) (EDIT 2: this part seems to be resolved)

// Think about Custom Elements here:
function FooMixin<T extends typeof HTMLElement>(Base: T) { 
    return class Foo extends Base { 
        test() {
            this.setAttribute('foo', 'bar')
        }
    }
}

playground link

As @dragomirtitian pointed out on SO, there are workarounds, but they appear to be very complicated and impractical.

Here’s a more realistic example of what I’m doing in JS (and trying to port to TS): I’m using a Mixin() helper function, as a type declaration for the following example, which in practice implements things like Symbol.hasInstance to check if instances are instanceof a given mixin, prevents duplicate mixin applications, and other features, but the types don’t work:

type Constructor<T = any, A extends any[] = any[]> = new (...a: A) => T

type MixinFunction = <TSuper>(baseClass: Constructor<TSuper>) => Constructor<TSuper>

// this function does awesome: ensures mixins aren't applied
// more than once on a prototype chain, sets up Symbol.hasInstance so that
// instanceof checks works with any mixin application, etc.
declare function Mixin<T extends MixinFunction>(
    mixinFn: T,
    DefaultBase?: Constructor
): ReturnType<T> & {mixin: T}

function FooMixin<T extends Constructor>(Base: T) { 
    return class Foo extends Base { 
        foo = 'foo'
    }
}

const Foo = Mixin(FooMixin)
type Foo = typeof Foo


function BarMixin<T extends Constructor>(Base: T) { 
    return class Bar extends Foo.mixin(Base) {
        bar = 'bar'

        test() {
            this.foo = 'foofoo' // should work!
        }
    }
}

const Bar = Mixin(BarMixin)

class Baz extends Bar {

    test() {
        this.bar = 'barbar' // should work!
        this.foo = 'foofoo' // should work!
    }

}

const f: Foo = new Bar()

playground link

Is there a way to do this currently, that we may have missed? (cc: @justinfagnani)

Checklist

My suggestion meets these guidelines:

  • This wouldn’t be a breaking change in existing TypeScript/JavaScript code
  • This wouldn’t change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript’s Design Goals.

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:1
  • Comments:15 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
sandersncommented, Jun 27, 2019

There’s a hard-coded requirement the mixin’s type must be an object type, which Ctor<{}> is, but T extends Ctor<{}> is not – it’s a type parameter.

Using Ctor<{}> directly may be enough for you; T extends Ctor<{}> is treated like Ctor<{}> inside FooMixin, and when you call FooMixin, anything assignable to T extends Ctor<{}> is also assignable to Ctor<{}>.

The only reason you’d need a type parameter is to make other parameters of FooMixin use type T. For example, if you wanted to mixin two things, you could make those two have the exact same type: function FooMixin<T extends Ctor<{}>>(Base1: T, Base2: T). That’s weird! Although, there might be more believable examples.

1reaction
trusktrcommented, Jun 30, 2019

Thanks for your hints about T extends Ctor<{}>. That helped a lot. I’ve gotten my mixins working (after many permutations of tinkering to understand how the type checker works), however it still requires a cast because the base class “is not a constructor function type”. I found it easier to write my own Constructor helper, with default T = object, which is what I need in most cases.

Basically, here’s what a simplified version looks like:

type Constructor<T = object, A extends any[] = any[]> = new (...a: A) => T

function FooMixin<T extends Constructor>(Base: T) { 

    class Foo extends Base { 
        foo = 'foo'
    }

    return Foo as typeof Foo & T
}

function BarMixin<T extends Constructor>(Base: T) { 

    class Bar extends FooMixin(Base as unknown as Constructor) { 
        test() { 
            console.log(this.foo)
        }
    }

    return Bar as typeof Bar & T

}

playground

The as Constructor cast doesn’t seem intuitive, but needed when using T in order to return the mixin type combined with the passed-in constructor type.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Documentation - Mixins - TypeScript
The mixin pattern is supported natively inside the TypeScript compiler by code flow analysis. There are a few cases where you can hit...
Read more >
Multiple inheritance and mixin classes in Python
The main problem lies in the fact that inheritance can directly delegate to only one other class (the parent class), as opposed to...
Read more >
How to use mixins and custom functions in Vue
Vue mixins and directives allow you to further extend your application and write more readable code by minimizing moving parts.
Read more >
Mixins and more in TypeScript 2.2 - SitePen
Our Favorite Update: Support for mixins and composable classes! ... This change provides a significant improvement for our development of Dojo 2.
Read more >
Implementing Layered Designs with Mixin Layers
A mixin class of [34] can define other mixins that can be composed with it, inherit some mixins when composed, and cancel inherited...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found