# React Code Guidelines

## Component Composition

When declaring a React component, be sure to make it as discrete as possible to maximize its reusability potential. This includes not having another class method to render DOM elements. It should be its own discrete component so that other parts of the application can potentially reuse this component, instead of having it pegged to a top level component as a class method. All components, even top level class components, should never have `render` functions more than 25-35 lines long. If it needs to be longer than that, then you need to recheck your code and see how you can break things down further into more discrete components. Consider the following **anti-pattern**:

```jsx
import React, { Component } from 'react'

class Todo extends Component {
  constructor(props) {
    super(props)
  }
  renderTodoItem = () => {
    return (
      <li>I am a Todo item</li>
    )
  }
  render() {
    <div>
      <p>Hello World!</p>
      <ul>
        { this.renderTodoItem }
      </ul>
    </div>
  }
}

export default Todo
```

Instead, what should be done is the following:

```jsx
import React from 'react'

const TodoItem = (props) => {
  return (
    <li>
      { props.text }
    </li>
  )
}

export default TodoItem
```

You then `import` this component to the top level class component to render. This ensures maximum reusability and sane structural organization of components. Which brings us to the next point, most of your components should be discrete _stateless functional components_. You should avoid handling state internally within a component as much as possible. Why? Because it ensures a sane downward state flow pattern which is easy to both build tests for and to understand the overall movement of data throughout your application.

On top of that, by rendering components through class methods, you strip away all of the special optimizations catered to stateless functional components. There are performance optimizations specific to stateless functional components that avoid unnecessary checks and memory allocations.

## Stateless Functional Components

With the advent of ES6 syntax, it is now possible to declare components as _stateless functional components_. Consider the following:

```jsx
import React from 'react'

const SignUpForm = (props) => {
  return (
    <form onSubmit={props.onSubmit}>
      <input type='text' name='username' onChange={props.onChange} />
      <input type='email' name='email' onChange={props.onChange} />
      <input type='password' name='password' onChange={props.onChange} />
      <button>Sign Up</button>
    </form>
  )
}

export default SignUpForm

```

Here, we have declared a stateless functional component that handles all the form DOM elements. It doesn't have an internal state at all, which keeps things concise and far easier to reason about when we import it to the following top level class component:

```jsx
import React, { Component } from 'react'
import { Link } from 'react-router'

import SignUpForm from '../components/SignUpForm'

class SignUp extends Component {
  constructor(props) {
    super(props)

    this.state = {
      username: '',
      email: '',
      password: ''
    }
  }
  handleInputChange = (e) => {
    this.setState({
      [e.target.name]: e.target.value
    })
  }
  handleSubmit = (e) => {
    e.preventDefault()

    // dispatch state data to API endpoint here
  }
  render() {
    return (
      <div>
        <SignUpForm onSubmit={this.handleSubmit}
          onChange={this.handleInputChange} />
        <span>
          Already have an account?
          <Link to='/login'>Log In</Link>
        </span>
      </div>
    )
  }
}

export default SignUp
```

By setting a `name` to the DOM element, it allows us to abstract the `<input>` handler into a single class method, rather than making a new class method for each `<input>` element. This is just an example of how you should strive to abstract and modularize your code in the most concise way possible.

## Component Styling

Never inline component styles at all. **Ever**. They should be kept in their own respective CSS/LESS/SASS files.