# Stateless Functional Components

by [ kirupa](https://www.kirupa.com/me/index.htm) | filed under [Learning React](https://www.kirupa.com/react/index.htm)

Let's face it. The components we will be writing aren't going to be changing the world. The bulk of the components we are going to write will do a few simple things, all of which revolve around taking some props and spitting out some markup. For these simple components, is all the complexity we have to deal with when defining them necessary? Probably not.

In the following sections, we are going to look at a greatly simplified syntax for defining components that should look very familiar to you.

Onwards!

## Getting Back to Functions

The syntax we have been using so far for defining components has looked as follows:

```jsx
class LightningCounter extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      strikes: 0
    };

    this.timerTick = this.timerTick.bind(this);
  }

  timerTick() {
    this.setState({
      strikes: this.state.strikes + 100
    });
  }

  componentDidMount() {
    setInterval(this.timerTick, 1000);
  }

  render() {
    var counterStyle = {
      color: "#66FFFF",
      fontSize: 50
    };

    var count = this.state.strikes.toLocaleString();

    return (
      <h1 style={counterStyle}>{count}</h1>
    );
  }
}
```

This syntax is not terrible. It is great for allowing you to define complex stateful components that define large parts of our app logic. For doing all of that, you need the full power classes provide. You want to extend the `Component` base class to have access to the state API, lifecycle methods, and other React features. Now, here is a wrinkle. What if your component doesn’t do a whole lot? What if your component will be purely presentational where it just takes some props and spits out some JSX kinda like the following?

```jsx
class SimpleMessage extends React.Component {
    return (
      <p>Message is: {this.props.message}</p>;
    );
  }
}
```

For the many components you create that fall under this bucket, you can define a component as just a plain old function:

```js
function SimpleMessage(props) {
  return <p>Message is: {props.message}!</p>;
}
```

Defining these ***functional components*** or ***stateless functional components*** looks ridiculously simple, and it totally works. Behind the scenes, when using this syntax, React still creates a proper component with all the hooks in all the right places. The way you call this component doesn't change either. Here is the `ReactDOM.render` call for our `SimpleMessage` component:

```jsx
ReactDOM.render(
  <div>
    <SimpleMessage message="Functions are back in style!"/>
  </div>,
  document.querySelector("#container")
);
```

What you can't do with this approach are things like using lifecycle methods, initializing default values in a constructor, defining state, and performing other tasks that are only suited for the formal structure of the class based approach.

#### Stateless Functional Components and their Arguments

In this function-based world, the `props` object is passed in as the first argument:

```jsx
function HelloSomething(props) {
  return <p>Hello, {props.target}!</p>;
}
```

This shouldn't be a total surprise, for we've already seen that in the snippets earlier. One detail to note is that you can set any name you want to refer to the first argument. It doesn't have to be **props** like we've seen so far. It can be something like **jello**:

```jsx
function HelloSomething(jello) {
  return <p>Hello, {jello.target}!</p>;
}
```

In more advanced (and possibly rare) cases, you may need to access the context object from inside your component. You can do that using this function-based approach easily, for the context object is passed in as the second argument:

```jsx
function HelloSomething(props, context) {
  return <p>Hello, {props.target}!</p>;
}
```

Just like with our props, you can set this argument's name to whatever you like as well.

## Kicking it up a Notch!

With this syntax, because you are working with functions, you can go a little crazy and take advantage of newish JavaScript techniques you have at your disposal. For example, if you are someone who finds the existence of the `function` keyword and `return` statement to be offensive, you can go even more compact and use arrow functions:

```jsx
var SimpleMessage = (props) => <p>Message is: {props.message}!</p>;
```

The end result is the same. But why stop here? If you are not a fan of having to rely on your `props` object each time you want to access a property on it, you can take advantage of destructuring:

```jsx
var SimpleMessage = ({ message }) => <p>Message is: {message}!</p>;
```

I am sure there is more dark magic you can invoke to make our component definition even more compact, but you get the idea. Functions give you a lot more flexibility than the more structured class based approach when it comes to using the latest EcmaScript features.

## Conclusion

Everything I have shown you here is entirely optional. If you like defining all your components using the class syntax, you can totally do so. You won't be negatively impacted - at least not now. This is a subtle detail to keep in mind, for the React team has stated they may optimize components created using the function-based syntax. I don't think they've done too much yet, but that could change at any point.

Lastly, even if you never decide to define stateless functional components, you should familiarize yourself with them and some of the variations we've seen. Many examples you will see in the wild may use this syntax extensively, so you need to know how to work with them and not get tripped up. This has been a public service announcement.

**Next tutorial:** [Setting Up Your React Dev Environment Easily](https://www.kirupa.com/react/setting_up_react_environment.htm)