-
-
Save ryanflorence/a93fd88d93cbf42d4d24 to your computer and use it in GitHub Desktop.
var pureRender = (Component) => { | |
Object.assign(Component.prototype, { | |
shouldComponentUpdate (nextProps, nextState) { | |
return !shallowEqual(this.props, nextProps) || | |
!shallowEqual(this.state, nextState); | |
} | |
}); | |
}; | |
module.exports = pureRender; | |
/////////////////////////////////////////////////// | |
var pureRender = require('./pureRender'); | |
class Foo extends React.Component { | |
render () { | |
return <div>this ain’t so bad</div> | |
} | |
} | |
pureRender(Foo); // don't return so you know its mutative :( | |
module.exports = Foo; | |
@aputinski you get a gold star for simplest possible solution :-)
In any cases that are more complex than a single lifecycle hook, this doesn't work as well.
@RickWong methods on es6 classes aren't enumerable, but you could do Object.assign(Object.create(Foo), {should...})
Does the latest gist work without any issues? Hard to tell by the comments. :)
@aputinski +1
Won't be easier just extending Component?
class PureRenderComponent extends React.Component {
shouldComponentUpdate () {
return React.addons.PureRenderMixin.shouldComponentUpdate.apply(this, arguments)
}
}
class Foo extends PureRenderComponent {
render () {
return (<div>Pure</div>)
}
}
Sorry to pile on, but this is one of the top hits when searching for PureRenderMixin in ES6, my two cents:
const pure = function (target) {
target.prototype.shouldComponentUpdate = React.addons.PureRenderMixin.shouldComponentUpdate;
return target;
}
@pure
class Test extends React.Component { }
Hi, is the code provided by @aputinski still works? I'm using react 15.0.1 and it doesn't work for me.
import PureRenderMixin from 'react-addons-pure-render-mixin';
class FooComponent extends React.Component {
constructor(props) {
super(props);
this.shouldComponentUpdate = PureRenderMixin.shouldComponentUpdate.bind(this);
}
render() {
return <div className={this.props.className}>foo</div>;
}
}
You need to install the addon as well.
@brigand
Can you elaborate on your statement "In any cases that are more complex than a single lifecycle hook, this doesn't work as well".
What exactly are the drawbacks to this same approach that is also now listed in the official React docs?
How do you feel about this approach?