Repository navigation
Exposing type and object from class factories. #13798
Description
Activity
- changed the title
[-]Mixin [/-][+]Exposing type and object from class factories.[/+]on Feb 1, 2017 You can almost accomplish this now, but with an extra empty prototype in the prototype chain, if you do:
export class TaggedPoint extends Tagged(Point) {}
Yes, but that's not user friendly... for a library it doesn't make sense...
why not:
export const TaggedPoint: Constructor<Tagged> & typeof Point = Tagged(Point); export type TaggedPoint = Tagged & Point;
Mohamed Hegazy (@mhegazy) yes, you are right, I copy pasted it from the samples in #13743
Anyway, it's not the issue, you still need to export the type :)
a class represents 1. a value, the constructor function, and 2. a type, which is the instance type, you can get the same behavior by exporting a value and a type with the same name. lib.d.ts does this for most declarations e.g.
HTMLElement.Mohamed Hegazy (@mhegazy) Yes, I know that, this is what I demonstrated in the samples.
We now have class factories that the developer need to manually export when using a class factory function...
I can live with the library author doing it... but if the developer has to, its not pretty :)
That's even more of an issue when the mixins are multilpe..
export const MyClass = Mixin(A, B, C, D);
Now you also need to export this type...
This is not specific to mixins, the issue is that there is no convienient way to refers to the return type of a function or a constructor. #6606 Is the issue tracking this.
Mohamed Hegazy (@mhegazy) that's a great issue, I hadn't seen it before. With something like #6606 we could write:
const M = <T extends Constructor<{}>>(superclass: T) => class extends superclass {} type M = typeof M(Object);
and not have to duplicate the class expression in a named interface. That's a big improvement.
Mohamed Hegazy (@mhegazy) #6606 still requires the extra type declaration.
Now that class factories can behaves as classes, the only missing piece is how to expose the runtime + design time result natively as if they were declared as classes.
export class User = RestMixn()
Maybe making it simple
export const User = RestMixn()
If RestMixn() returns a class, automatically set the type as if
export type User = ...;
Was done by the developer....
We really do not like introducing new syntax that can conflict with ES committee future direction (see design goal #4). We do not have a similar issue with the type space though.
I think you do not need to expose additional types, you just
export const TaggedPoint = Tagged(Point);and that is that. your users now can use it as a constructor, e.g.import {TaggedPoint } from "mod"; new TaggedPoint();, and if they choose to talk about the type, they can just refer to it asvar myTaggedPoint: typeof new TaggedPoint();, just 10 characters more, but not too bad.Reacted by Aluan Haddad and Zen CoderMohamed Hegazy (@mhegazy) I agree on the design goal.
But,
- I don't think this is valid:
var myTaggedPoint: typeof new TaggedPoint(); - Even if valid, 10 chars is a lot when its in ctor, methods, etc... alot...
- I need to expose types, these can be assigned as class members, part of interfaces etc...
I understand the limitation, i'm trying to find a solution.
What about internal logic:
export const User = RestMixn()
Seeing that
RestMixin()returns a class, TypeScript can automatically export the type with the same name if such does not exit, it shouldn't break anything, it can be lazy so the type is set once imported or used...- I don't think this is valid:
A
constis not a type, it is a value, and it is possible that there is a type with the same name, e.g. http://www.typescriptlang.org/docs/handbook/declaration-merging.htmlReacted by Aluan HaddadSeeing that RestMixin() returns a class, TypeScript can automatically export the type with the same name if such does not exit, it shouldn't break anything, it can be lazy so the type is set once imported or used...
:)
As we are talking about functions that are called to produce classes parametrically, when it comes to exporting the resulting values along with their types in a convenient and discoverable manner, I think it could be good to look at something like #13231. Since these classes are imperatively defined, exporting them seems like it may well fall under the domain of implementing a module interface.
New runtime
classsyntax as proposed here should be handled by TC39
Following the great mixin implementation by Anders Hejlsberg (@ahejlsberg) (#13743)
Having a mixin function returns a class is powerful but requires manual type declaration.
We can't use
TaggedPointas a type, unless we:Using classes we can
Which exposes the type but forces the developer to
extendtheCustomerclass.My feature request is allowing:
Which will be just sugar for:
Maybe even:
but that's not the main point...
The motivation for this is a more robust mixin mechanism that revolves around the base class and allow mixin's to know about it, using generic it provides powerful combinations.
So I can have
And the return type can have members from Mixin1 knowning about Base, using interfaces one can even set static members of a mixin to return T which is the instance of
RestMixin(Base, Mixin1, Mixin2)all together.