Let’s make it clear that mixins are not technically deprecated. If you use React.createClass(), you may keep using them. We only say that they didn’t work well for us, and so we won’t recommend using them in the future.

… but your point is well taken . I guess that means someone should get cracking on a react-meteor-data PR:

Heh - I think the post is more arguing that you shouldn’t use mixins to organize your app code - I’d say using it internally in a library doesn’t have any of the downsides Dan was talking about. But sure, it would be cool to remove the mixin from the package entirely.

Summary of Facebook’s blog post -> If you don’t write good code, it’s confusing for other people to read/ modify later. We can accomplish the same end goal that mixins help achieve using higher order components.

Granted, if the community is moving away from something and moving towards a different paradigm as a best practice it’s in everyone’s best interest to follow the flow. It’s just funny to me how harsh the title of the post is given it’s basically just saying mixins encourage disorganized development when working in large shifting teams.

The good thing is that there is even clearer direction now for community best practices. And, I greatly appreciate Dan taking the time to elaborate on not only why mixins were causing issues at Facebook, but also how to achieve the same goals using other methods that lead to more maintainable code.