-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixins and ES6 #15
Comments
No, mixins in Blaze Components were designed to work well with ES6 and JavaScript. As described in the README:
We decide to simply use a system on top of what JavaScript provides, without any mingling of JavaScript internals. See the diagram in the README. Also, it is an optional feature. You do not have to use mixins. You can vanilla JavaScript or ES6. If that is good enough for you, great. If not, Blaze Components offer a non-intrusive API to provide mixins for you. It is mostly there so that if community develops mixins that those mixins can interoperate, instead of each implementing some fake ways manually. So mixins as they are in Blaze Components are "real in ES6". They work with ES6. Maybe they should be named something else, just to not confuse things when there will be official mixin support in ES2099. But what is here is now and working, and behaves as a mixin. If there will be some mixins in the future, they will be not conflicting with these mixins (except in the name). Also, mixins are not the core reason this package exist. This package exist mostly to make UI in Meteor more reusable. If there will be other mixins available, then that will be just another way to provide more composability. And we can always then just make internal implementation of Blaze Components mixins use official mixins. I also talked with Dave Herman about ES6 and mixins do not seem to be anywhere near. So I do not think we should worry about this now. And in meantime we can use these non-intrusive mixins. :-) |
So mixins are offered now because nothing better exists. But you can decide not to use them and use only inheritance. I think that for UI composability is better, but we will see how things will go. This is the idea of the project. To create a community developing reusable components. And we will all learn what works and what does not. How you compose or inherit event handlers? How you compose or inherit animations? How you compose or inherit template content? Still many open questions. But at least now we have a space around which we can start trying things out. |
(Closing as answered, but discussion can continue.) |
First of all, 👍 for this. I haven't got time to use it yet, but the docs and demo/tutorial look impressive etc.
I totally understand the possibilities of mixins, but I'm hesitant about it because there's no real ES6 way for this yet, and as we know ES6 is here. I wonder if you have any thoughts on this issue and if you're worried that some core functionality will be rewritten as things take shape (or worse, a project is abandoned because of it).
Some references;
https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750
remix-run/react-router#659
Cheers
The text was updated successfully, but these errors were encountered: