Mixins
DO NOT USE MIXINS.
That's it! Seriously that's all there is...
Okay, okay - I won't waste your time here. So why don't we use mixins according to the AirBnB React/JSX style guide?
"Why? Mixins introduce implicit dependencies, cause name clashes, and cause snowballing complexity. Most use cases for mixins can be accomplished in better ways via components, higher-order components, or utility modules." -AirBnB
The style guide references a great blog post from the Reactjs.org that you can check out if you want. Let me save you the trouble of having to go all the way over there and read it yourself.
So back when React was just starting to do its thing, Facebook engineers would be accustomed to writing certain patterns to solve certain compositions and they wouldn't want to give up their tried and true methods. Since React (influenced by functional programming) was entering an object oriented programming field, React had to make it easier for engineers to adopt.
Certain escape hatches were created to help with these composition issues, and mixins were one way this was implemented. They would allow one to reuse code for composition problems that they weren't sure how to solve.
There are more component libraries like React, developers are more confident in React, and building declarative user interfaces with mixins now sucks! Here are reasons why:
Mixins cause name clashes - If
FluxListenerMixin
andWindowSizeMixin
both usehandlechange
, your screwed! You can't do this and you also can't usehandlechange
in your components. Bummer dude.Mixins cause snowballing complexity - The blog post says:
"A component needs some state to track mouse hover. To keep this logic reusable, you might extract handleMouseEnter(), handleMouseLeave() and isHovering() into a HoverMixin. Next, somebody needs to implement a tooltip. They donβt want to duplicate the logic in HoverMixin so they create a TooltipMixin that uses HoverMixin. TooltipMixin reads isHovering() provided by HoverMixin in its componentDidUpdate() and either shows or hides the tooltip.
A few months later, somebody wants to make the tooltip direction configurable. In an effort to avoid code duplication, they add support for a new optional method called getTooltipOptions() to TooltipMixin. By this time, components that show popovers also use HoverMixin. However popovers need a different hover delay. To solve this, somebody adds support for an optional getHoverOptions() method and implements it in TooltipMixin. Those mixins are now tightly coupled."
FAILCITY
Never, ever, ever ever use mixins again - Just kidding though...
Now React doesn't mean that mixins are deprecated, they just forgot to pizza when they should have french fried, so they ended up having a bad time.
If you want to use React.createClass()
, be my guest - but you're probably going to have a bad time.
Do this instead
Maybe you want to prevent unnecessary re-renders with PureRenderMixin
because the props and state are shallowly equal to the previous props and state:
var PureRenderMixin = require('react-addons-pure-render-mixin');
var Button = React.createClass({
mixins: [PureRenderMixin],
// ...
});
What's that? You guessed it - using PreRenderMixin
is going to cause you to have a bad time. So what can you do?
Just use the shallowCompare
function instead! Easy nuff, right? Let's see how that works:
var shallowCompare = require('react-addons-shallow-compare');
var Button = React.createClass({
shouldComponentUpdate: function(nextProps, nextState) {
return shallowCompare(this, nextProps, nextState);
},
// ...
});
No? Not really? You don't like all that typing? Wow, developers are so hard to please.
Just don't call me when you have to ship on Friday afternoon and you can't get your code to work because the new junior dev just sent over a pull request for his NavBar component that uses PureRenderMixin
, because he just wants to write code like you do and he left for the day so now your stuck at the office until Saturday trying to figure out why your having a bad time.
So today we learned
Don't use mixins!
It is time to find our peaceful zen meditation and reflect on this very short rule for the day.....
"Listen Sariputra,
Matter is not different from emptiness,
And emptiness is not different from matter."
Top comments (0)