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 referencesa 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 - IfFluxListenerMixin 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 abad time.

If you want to useReact.createClass(), be my guest - but you're probably going to have abad time.

Do this instead

Maybe you want to prevent unnecessary re-renders withPureRenderMixin 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 - usingPreRenderMixin is going to cause you to have abad time. So what can you do?

Just use theshallowCompare 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 usesPureRenderMixin, 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 abad 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."