Get rid of mixins

[rob0rt]

Right now, mixins are inhibiting a clean migration to es6 components (though a workaround exists with Decorators). Finding a way to get rid of them, or modify them so they don't need to be mixins, would be good.

This came up in conversation on #458.

Edit by @newoga

• click-awayable.js (PR [Core] Remove click-awayable mixin #3360)
• context-pure.js (Umbrella Issue [Core] remove context-pure mixin from components #2837)
• controllable.js (PR [Core] Remove controllable.js mixin #2889)
• style-propable.js (Umbrella Issue [Core] remove style-propable mixin from components #2852)
• window-listenable.js (Umbrella Issue [Core] remove window-listenable mixin from components #3305)
• style-resizable.js (PR [WIP][Core] Remove style-resizable mixin  #2934)
• PureRenderMixin

[rob0rt]

So the problem I see with this is the fact the mixin sets the propTypes as well as introduces other methods to the instance.

A possible solution would just be to move the methods into a helper class and then add the propType it adds directly to the propTypes in the parent component.

[rob0rt]

Another potential solution is making the mixins Decorators, and instead of adding the @mixin decorator to the class, you add something like @Stylable.

[rob0rt]

And a third potential solution is to just use @mixin. This doesn't seem like as bad of an idea to me the more I think about it, since it does essentially exactly what es5 mixins do now. There's not the new learning curve of dealing with custom Decorators, and it doesn't force a codebase-wide refactor of functionality (this is the biggest win with this technique in my opinion).

[oliviertassinari]

And a third potential solution is to just use @mixin.

Adding the fact that we are working on another branch.
I think that's the best way to start the conversion.

[rob0rt]

Ah, my bad. I've got a one track mind at times 😛

[rob0rt]

My current PR uses the third technique. It doesn't exactly get rid of mixins but it does solve the problem of using them with ES6 classes.

[alitaheri]

@BobertForever I kinda have an anti-pattern-phobia. I dislike mixins and love composition, orthogonality, and conventions. A subset of utility methods, HOCs and stuff will easily solve this issue. it's only a matter spending time and actually making it a reality. But I value productivity more than my opinions. Iterations and getting things done will teach your lessons beyond anything you can learn with just conversations. I propose this:

You go on ahead and migrate the classes the fastest way possible (I think that would be @mixin) and I will try to figure out a way to get rid of mixins once and for all :D

I truly appreciate the time you spent making this wish a reality. Thanks a lot 👍 👍

[rob0rt]

I agree about getting rid of mixins and I think your point with utility methods would be good (since a large portion of the mixin is just providing utility around the thing it added to the props). Looking through the mixins though I see a lot of them which rely heavily on the React methods, so moving them out to Utility methods would likely mean everywhere they were used, the class would have to implement those React methods and add in UtilityClass.[method]. That's more explicit and a lot of typing...

I guess potentially you could extend what used to be a mixin? Though that was brought up last time this conversation was had and doesn't really work when a class has multiple mixins.

[rob0rt]

So I ran into an issue with that library I was using, which I explain in PR #2451, and propose a temporary solution. It's basically my second suggestion from above, creating a custom decorator for what used to be a mixin.

[alitaheri]

Almost... 😍

[oliviertassinari]

This issue should have been closed ages ago. We do no longer use mixins 🎉 .