Possible to use bare classes as mixins?
See original GitHub issueFor example,
Suppose I have a class,
class Transformable { ... }
I can easily extend that,
class ThreeDeeObject extends Transformable {}
Now suppose I want ThreeDeeObject
to have characteristics of Transformable
, EventEmitter
, and TreeNode
, which let’s suppose are all plain classes just like Transformable
,
class EventEmitter { ... }
class TreeNode { ... }
Would it be possible to make the mixwith
API accept these plain classes as arguments to with()
, so that
class ThreeDeeObject extends mix(/* class {} */).with(Transformable, EventEmitter, TreeNode) { ... }
?
The reason I ask is because I also like the option of extending one of those classes directly, not being limited to using them as mixins. For example:
class ThreeDeeObject extends mix(/* class {} */).with(Transformable, EventEmitter, TreeNode) { ... }
class SomethingElse extends EventEmitter { ... } // extend EventEmitter directly.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:6 (1 by maintainers)
Top Results From Across the Web
Provide mixins for list-bare and list-inline · Issue #419 - GitHub
By extracting the CSS of the list-bare and list-inline to mixins, we can give users the possibility to use just the mixins in...
Read more >Is there a way to generate interface from class in D using mixin ...
It is possible to write such mixin but that will create a circular dependency issue - being able to generate an interface but...
Read more >Mixin - Wikipedia
In object-oriented programming languages, a mixin (or mix-in) is a class that contains methods for use by other classes without having to be...
Read more >Composing Angular Components with Typescript Mixins
The way Mixins are created with Typescript is simple: we define a function that takes as argument a class and extend the newly...
Read more >Mixins or composition? | Pages from the fire
Composition is great for handling complex functionality by insulating individual parts into their own classes and just exposing the bare ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Can I suggest that you put this workaround:
somewhere in the documentation for
mixwith
(or in the excellent blog post which spawned it … or both)?I think it’s an essential pattern for a significant percentage of people who want to use mix-ins (not every class has a parent), and it’d be nice if others didn’t have to dig through the issues to find it.
P.S. Thanks for pioneering this technique; IMHO it should be the one true pattern for doing mix-ins in JS.
After thinking about #14 (and not liking the implementation, though I like the outer API), I think what I’m going to do is try an onion-like approach like what you’ve got (instead of branching), except that I want to be able to pass vanilla classes (not parameterized class factories) into the
multiple()
(ormix().with()
) call.If possible, what I’d to do is take the vanilla classes passed as input, then build internal class factories that accept parameterized superclasses, then use those class-factories internally in the implementation so that the end user does have to even know about the class-factory pattern.
So, the idea is this, if possible:
This way (if possible) plain vanilla classes remain vanilla classes that don’t have to be used with any extra patterns, so the end class designer does not need to use a mixin pattern (class factories), and needs not make any API calls when extending a single class (unlike currently, where a class-factory requires an API call even if extending from only a single mixin class). For example, if I just want to extend
Lorem
from above, I only need to use plain ES6 class syntax:I would not have to do any of the following just to extend a single class:
So, basically,
Alright, I’m going to go try and implement it…