Say goodbye to the medieval class constructor in your React components. While Stateless Function Components (SFCs) are a handy tool in your arsenal, Class Components are still the de-facto way to write React components that utilizes state or lifecycle hooks. ES6 A hypothetical ES6 Class Component might look something like this (over-simplified without error checking, of course). class Foo extends Component {constructor(props) {super(props);this.state = { loading: true };} async componentDidMount() {const data = await loadStuff();this.setState({ loading: false, data });} render() {const { loading, data } = this.state;return ({loading ? <Loading /> : <View {...data} />});}} We initialize our in the , asynchronously load our data in , and render our component based on the state. A pretty standard pattern — at least for me, if you’ve been following my work. state constructor componentDidMount View loading Class properties We’ve all been taught that the is where we initialize our instance properties, in this case. And if you are saying to yourself, “Exactly!”, then you would be absolutely correct… if not for the upcoming ES.next , currently in stage 3. constructor state class properties proposal With it we can now define class properties directly, like this. class Foo extends Component {state = { loading: true };...} will transpile your code and add a for you behind the scenes. Here is the output from Babel when we transpile the code snippet above. Babel constructor Note that Babel is actually passing all args — not just — down to . It is also taking ’s return value and passing it back to the caller. Both may be a bit overkill, but exactly what it should be doing. props super super There’s still a constructor, you just don’t see it. Binding methods Another reason that we’re taught to use the is for binding methods to , like so. constructor this class Foo extends Component {constructor(props) {super(props);this.myHandler = this.myHandler.bind(this);} myHandler() {// some code here that references this}...} Some people ignore this all together by assigning a function expression to a class property, but that’s a different story all-together. Read more about this in my other ES6 React Classes article . Demystifying Memory Usage using ES6 React Classes _Which is more efficient? Binding in the constructor, or using an arrow function as a class property?_medium.com Demystifying Memory Usage using ES6 React Classes Let’s assume for a moment that you are in the camp (and even if you’re not, bear with me). We’ll need to bind in the , right? Not necessarily. We can do the same thing that we did for class properties above. bind constructor class Foo extends Component {myHandler = this.myHandler.bind(this); myHandler() {// some code here that references this}...} Initializing state with props What about when you need to derive your initial from , say for initializing a default value? Surely we need the for that? state props constructor class Foo extends Component {constructor(props) {super(props);this.state = {color: this.props.initialColor};} render() {const { color } = this.state;return (<div>{color}</div>);}} Nope! Again, class properties to the rescue! We have access to both and . this props class Foo extends Component {state = {color: this.props.initialColor};...} Data fetching Maybe we need a to fetch data? Hardly. As we saw in our first code sample, any data loading should be done in . But why ? We do it there so that the fetch isn’t performed when running the component on the server — as is the case when doing Server Side Rendering (SSR) — as is performed server side. constructor componentDidMount componentDidMount componentDidMount not Conclusion We’ve seen that for setting our initial , we no longer need a (or any other instance property for that matter). We also don’t need it for binding methods to . Same for setting initial from . And we would most definitely never fetch data in the . state constructor this state props constructor Why then would we ever need the in a React component? constructor Well… you don’t. [However… If you find some obscure use case where you need to initialize something in a component, both client-side and server-side, you still have an out. There’s always _componentWillMount_ . Internally, React calls this hook right after “newing” the class (which calls the _constructor_ ) on both the client and the server.] So I maintain that for React components: The constructor is dead, long live the constructor! Further Reading Well, not reading, but has a on class properties that you may want to read, um… watch. Kent C. Dodds nice video tutorial You can also read a bunch of (including some on Hooks in React 16.7, {…❤️} Spread Love, and React Best Practices) on the AmericanExpress.io Technology Blog. React based articles I also write for the American Express Engineering Blog. Check out my other works and the works of my talented co-workers at AmericanExpress.io . You can also follow me on Twitter .

American Express

BUNCH

Fetch

Super

Twitter

ReactAF: Always Fresh (or As F&#%!)

Reduce, Reuse, React

Too Long; Didn't Read

Make resilience your competitive advantage

The constructor is dead, long live the constructor!

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Slack Pro Tips

The complete guide to Object Oriented Programming

Javascript inheritance behind the scene proto, [[prototype]] and prototype

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

Slack Pro Tips

The complete guide to Object Oriented Programming

Javascript inheritance behind the scene proto, [[prototype]] and prototype

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps