React .14 introduced a simpler way to define components called stateless functional components. These components use plain JavaScript functions. Here’s the before and after in ES6:

![](https://hackernoon.com/hn-images/1*zyaxLgvQHfgaDjMoP90XAw.png)

27 lines vs 21 lines isn’t the big story… Also, note that the nested \`sayHi\` function on the right should admittedly be avoided for performance reasons. See comments for why.

The differences above may seem subtle at first glance, but cutting the noise is a **_big_** win.

Here’s why.

**No Class Needed  
**Frankly, I think [the drama around ES6 classes is overblown](https://medium.com/@housecor/in-defense-of-javascript-classes-e50bf2270a95#.92qa3ous7). But I do agree that plain functions are generally preferable, and eliminating the class related cruft like extends and the constructor in the example above are a nice win.

**No this Keyword**  
As you can see above, the stateless component is just a function. Thus, all the annoying and confusing quirks with Javascript’s **this** keyword are avoided. The entire component becomes easier to understand without the **this** keyword. Just compare the click handler in each approach:

onClick={this.sayHi.bind(this)}>Say Hi</a>  
onClick={sayHi}>Say Hi</a>

Note that the bind keyword isn’t necessary for the stateless component. Dumping classes eliminates the need for calling bind to pass the **this** context around. Given how confusing JavaScript’s **this** keyword is to many developers, avoiding it is a nice win.

Oh, as a side note, there are five different ways to handle binding in React. [Here’s a short post on the merits of each approach](https://medium.freecodecamp.com/react-binding-patterns-5-approaches-for-handling-this-92c651b5af56).

**Enforced Best Practices  
**Stateless functional components are useful for [dumb/presentational components](https://gist.github.com/chantastic/fc9e3853464dffdb1e3c). Presentational components focus on the UI rather than behavior, so it’s important to avoid using state in presentational components. Instead, **state should be managed by higher-level “container” components, or via Flux/Redux/etc**. Stateless functional components don’t support state or lifecycle methods. **This is a good thing.** Why? Because it protects from laziness.

See, it’s always tempting to add state to a presentational component when you’re in a hurry. It’s a quick way to hack in a feature. Since stateless functional components don’t support local state, you can’t easily hack in some state in a moment of laziness. Thus, stateless functional components programatically enforce keeping the component pure. You’re forced to put state management where it belongs: in higher level container components.

**High Signal-to-Noise Ratio  
**As you can see in the image above, stateless functional components require less typing. This translates less noise. As I discuss in “[Writing Code for Humans](https://www.pluralsight.com/courses/writing-clean-code-humans)”, great code maximizes the signal-to-noise ratio. The 27 line component became 21 lines, a ~20% reduction. You can go a step further on simple components. With a single line return statement, you can omit the return and curly braces. If you do this and also use ES6 destructuring on props, the result is nearly all signal:

It’s a function that takes a parameter and returns markup. Nice. Seriously, could this feasibly be any cleaner?

**Code Completion/Intellisense**  
If you destructure your props in ES6 as I did in the example above, then all the data you use is now specified as a simple function argument. This means you also get improved code completion/intellisense support compared to class-based components.

**Bloated Components and Poor Data Structures Are Easily Spotted**  
We all know [a function that takes a lot of parameters is a code smell](http://app.pluralsight.com/courses/writing-clean-code-humans). When you use ES6 destructuring with your stateless components, the argument list clearly conveys your component’s dependencies. Thus, it’s easy to spot components that need attention. In this case, you can either break up the component or rethink the data structures you’re passing around. Sometimes a long list of props can be easily resolved by passing an object instead. But if the props aren’t logically related enough to justify a single object, then it’s likely time to refactor the component into multiple separate components.

**Easy to Understand  
**As we’ve just seen, when you see a stateless functional component, you know it’s simply a function that takes props and spits out HTML. Even if it contains a lot of markup and nested functions inside the render, it’s conceptually simple. It’s a pure function. This leads to the next big win…

**Easy to Test  
**Since it’s a pure function, your assertions are very straightforward: Given these values for props, I expect it to return this markup. So for the example HelloWorld component, I can assert that when the render function is called with the value of ‘Cory’ for props.name, it returns a div with ‘Hi Cory’ inside.

> With React’s stateless functional components, each component can be easily tested in isolation. No mocking, state manipulation, special libraries, or tricky test harnesses are needed.

**Performance**  
Finally, stateless functional components may soon offer improved performance as well. Since there’s no state or lifecycle methods to worry about, the React team plans to avoid unnecessary checks and memory allocations in future releases.

**Update**: With React 16.6+, you can declare “pure” functional components via [React.memo](https://reactjs.org/docs/react-api.html#reactmemo). And with Hooks in 16.7, functional components transpile smaller too.

Even today, functional components transpile down to less code than class components, which means functional components = smaller bundles:

![](https://hackernoon.com/hn-images/1*NnDFmlvSb99eUlPCoqk9Qg.png)

Class components compile down to at least 20 lines of code. The equalivent functional component requires only 6 lines of code. Result? Smaller bundles.

Improved performance with superior syntax, testability, and readability? Sign me up!

### Any downsides?

Yep. See my other post, “[7 Reasons to Outlaw React’s Functional Components](https://medium.freecodecamp.org/7-reasons-to-outlaw-reacts-functional-components-ff5b5ae09b7c)”, for the potential downsides to consider.

### Summary

For all these reasons, **we should strive to use stateless functional components wherever possible**. Stateless components are just the latest reason why [I love teaching React](http://www.pluralsight.com/author/cory-house). React stateless functions offer the most elegant approach I’ve seen for creating a reusable component in any popular framework. Yes, even [including Angular 2](https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51#.19cm9gx8c).

Are there other wins I’m overlooking? Downsides to consider? Chime in via the comments below.

**_Cory House_** is principal consultant at [reactjsconsulting.com](http://reactjsconsulting.com). He is the author of “[Building Applications with React and Redux in ES6](https://app.pluralsight.com/courses/react-redux-react-router-es6)", “[Building Applications with React and Flux](https://www.pluralsight.com/courses/react-flux-building-applications)”, “[Clean Code: Writing Code for Humans](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiK1pXx89nJAhUujoMKHeuWAEUQFggcMAA&url=https%3A%2F%2Fwww.pluralsight.com%2Fcourses%2Fwriting-clean-code-humans&usg=AFQjCNEBfkBoN-IgCn_1jFUqWDAUIxcmAw&sig2=Ub9Wup4k4mrw_ffPgYu3tA)” and multiple other courses on Pluralsight. He is a Software Architect at VinSolutions and [trains software developers internationally](http://www.bitnative.com/training/) on software practices like front-end development and clean coding. Cory is a Microsoft MVP, and founder of [outlierdeveloper.com](http://www.outlierdeveloper.com).

Google

Microsoft

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

React Stateless Functional Components: Nine Wins You Might Have Overlooked

Too Long; Didn't Read

People Mentioned

Companies Mentioned

@housecor

RELATED STORIES