React ⚡️

Formatting
Naming
Props
Tags
Functions
Project Structure
- Components / Screens
Component Props
- Containers
- Hooks
Tests

Formatting

Use soft-tabs with a two space indent.
Limit each line of code to fewer than 130 characters.
End each file with a newline.

Enforce the closing bracket location for JSX multiline elements (learn more)

// Bad
     
<Hello
  lastName="Smith"
  firstName="John" />;
     
// Good
     
<Hello firstName="John" lastName="Smith" />;
     
<Hello
  firstName="John"
  lastName="Smith"
/>;

// Bad
     
{showButton &&
  <Button />
}

// Good
     
{showButton && (  
  <Button />
)}
          
{showButton && <Button />}

Naming

Use jsx extensions for components, screens etc.
Use PascalCase for files with the jsx extension:
```
components/
├── Button/
│   ├── index.jsx
screens/
├── Home/
│   ├── index.jsx
```
index.jsx is the only exception to this rule as it represents the folder root. This filename can also be omitted in import statements: import Button from '../Button/'.

Use camelCase for all other files with a js extension:

lib/
├── requestManager.js
helpers/
├── userHelper.js

Use camelCase for variables and functions:

// Bad
let form_params = {};
  
function FetchParams() { 
  return {};
}

// Good
let formParams = {};
  
function fetchParams() { 
  return {};
}

Use PascalCase for classes:

// Bad
class product_form {}
class productForm {}
  
// Good
class ProductForm {}

Use SCREAMING_SNAKE_CASE for constants:
```
// Bad
const fetchLimit = 25;
  
// Good
const FETCH_LIMIT = 25;
```
This formatting is somewhat inherited from Ruby but is widely accepted in the JS community.

Use PascalCase for components and camelCase for their instances:

// Bad
import menuCard from './MenuCard';
  
// Good
import MenuCard from './MenuCard';
  
// Bad
const MenuIten = <MenuCard />;
  
// Good
const menuItem = <MenuCard />;

Use camelCase for prop names and PascalCase if the prop value is a React component:

// Bad
<Foo
  UserName='hello'
  phone_number={ 12345678 }
/>
  
// Good
<Foo
  userName='hello'
  phoneNumber={ 12345678 }
  Component={ SomeComponent }
/>

Props

Omit the value of the prop when it is explicitly true:

// Bad
<Foo
  hidden={true}
/>
  
// Good
<Foo hidden />

Always include an alt prop on tags. If the image is presentational, alt can be an empty string or the must have role=’presentation’:

// Bad
<img src='hello.jpg' />
  
// Good
<img src='hello.jpg' alt='Me waving hello' />
  
// Good
<img src='hello.jpg' alt='' />
  
// Good
<img src='hello.jpg' role='presentation' />

Avoid using an array index as key prop, prefer a stable ID:

// Bad
{ todos.map((todo, index) =>
  <Todo
    {...todo}
    key={index}
  />
) }
  
// Good
{ todos.map(todo => (
  <Todo
    {...todo}
    key={todo.id}
  />
)) }

Functions

Use arrow functions to close over local variables.

function TaskList(props) {
  return (
    <ul>
      {props.tasks.map((task, index) => (
        <Item
          key={task.key}
          onClick={() => someFunc(task.name, index)}
        />
      ))}
    </ul>
  );
}

In the constructor, Bind event handlers for the render method, Otherwise it creates a whole new function on every single render and reduces performance.

// Bad
class extends React.Component {
  onClickDiv() {
    ....
  }
  
  render() {
    return <div onClick={this.onClickDiv.bind(this)} />;
  }
}
  
// Good
class extends React.Component {
  constructor(props) {
    super(props);
  
    this.onClickDiv = this.onClickDiv.bind(this);
  }
  
  onClickDiv() {
    ....
  }
  
  render() {
    return <div onClick={this.onClickDiv} />;
  }
}

Be sure to return a value in render methods.

// Bad
render() {
  (<div />);
}
  
// Good
render() {
  return (<div />);
}

Project Structure

After working on several React projects, we settled down on the following file organization (this structure is closed to the general JS application structure):

adapters/
├── product.js
components/
├── Product/
│   ├── index.jsx
├── ProductList/
│   ├── index.jsx
constants/
├── product.js
contexts/
├── auth.js
helpers/
├── formatProductDescription.js
reducers/
├── product.js
screens/
├── ProductDetails/
│   ├── index.jsx
services/
├── googleMap.js
tests/
├── components/
│   ├── Product/
│   │   ├── index.test.js

adapters/: the classes in charge of making network and/or async tasks. We usually create one file per API resource.
components/: the stateless and reusable React components.
constants/: the reducers types under this directory. The organization of this directory should match the folder structure of the reducers.
contexts: creating contexts and context providers.
helpers/: Any utilities used in the project.
reducers/: the Redux reducers. The organization of this directory should match the folder structure of contexts and constants.
screens/: the page specific components which are in charge of rendering all other stateless components to build any specific page.
services/: the service classes used in the project. By definition, these classes should encapsulate one single process of the app.
tests: Unit tests for components, screens, helpers etc.

Components / Screens

Use a folder structure with an index file (and other files when required):

// Bad
components/
├── Button.jsx
screens/
├── Product.jsx

// Good
components/
├── Button/
│   ├── index.jsx
screens/
├── ProductDetails/
│   ├── index.jsx

This is both a future-proof measure and a mean to break down components into small meaningful modules:

components/
├── Button/
│   ├── index.jsx
│   ├── loading.jsx
│   ├── propTypes.js
screens/
├── ProductDetails/
│   ├── index.jsx
│   ├── header.jsx
│   ├── gallery.jsx

Component Props

React PropTypes are a critical part of creating re-usable components with a clear API.

Use the right PropType that matches the expected data type for each prop:

  Button.propTypes = {
    /**
     * Holds the text to display in the button.
     **/
    text: PropTypes.string,
  
    /**
    * Select the style type.
    **/
    styleType: PropTypes.oneOf(['default', 'primary', 'secondary']
  )};

Define which prop is required:

Button.propTypes = {
  /**
   * Holds the text to display in the button.
   **/
  text: PropTypes.string.isRequired,
  
  /**
   * Disabled state
   **/
  disabled: PropTypes.bool
};

Use PropTypes.shape to define complex props:

/**
* Available action creators.
**/
actions: PropTypes.shape({
  /**
   * When a ticket is selected.
   **/
  pickTicket: PropTypes.func.isRequired,
  
  /**
   * When a ticket is unselected.
   **/
 unpickTicket: PropTypes.func.isRequired

  /**
   * Click event handler.
   **/
  onClick: PropTypes.func,
}).isRequired
  
/**
 * Holds the search store.
 * */
search: PropTypes.shape({
  /**
   * Holds the origin city.
   **/
  origin: PropTypes.string.isRequired,
      
  /**
   * Holds the destination city.
   **/
  destination: PPropTypes.string.isRequired
}).isRequired

The definition of PropTypes allows for complex type structure between components:

components/
├── Product/
│   ├── index.jsx
│   ├── propTypes.js
├── Feed/
│   ├── index.jsx
│   ├── propTypes.js

In Feed/propTypes.js:

import PropTypes from 'prop-types';
import productPropType from '../Product/propTypes';

export const feedPropType = PropTypes.shape({
  products: PropTypes.arrayOf(productPropType).isRequired,
  ...
});

Do not use accessKey on elements. eslint: jsx-a11y/no-access-key

Reason: Inconsistencies between keyboard shortcuts and keyboard commands used by people using screen readers and keyboards complicate accessibility.

// Bad
<div accessKey="h" />

// Good
<div />

Containers

Use a single file structure:

// Bad
containers/
├── ProductDetails/
│   ├── index.jsx

// Good
containers/
├── ProductDetails.jsx

Since very logic should be placed in containers, a single file structure forces to keep the complexity to a minimum.

Hooks

Eslint plugin for react hook: eslint-plugin-react-hooks

This plugin is developed by React team. It’s simple and consists only a couple of rules

Avoid calling hooks inside loops, conditions, and nested functions

This would ensure that Hooks are being called in the same order each time a component renders. That’s what allows React to correctly preserve the state of Hooks between multiple useState and useEffect calls

  // Bad
    
  if (name !== '') {
   useEffect(function persistForm() {
     localStorage.setItem('formData', name);
   }
  });
    
  // Good
    
  useEffect(function persistForm() {
    if (name !== '') {
      localStorage.setItem('formData', name);
    }
  });

Every value referenced inside the effect function should also appear in the dependencies array

For example, the following userInfo component will trigger the exhaustive-deps warning because the userId variable gets referenced inside the useEffect but it’s not passed in the dependencies array

  function ProductInfo({productId}) {
    const [product, setProduct] = useState(null)
    useEffect(() => {
      getProduct(productId).then(product => seProduct(product))
    }, []) // no productId here
    
    return <div>Product detail:</div>
  }

Tests

The tests folder should have unit tests for the application. The folder structure of the tests should be similar to the structure of the application. For example if we have a product.js file in below structure

components/
├── Product/
│   ├── product.js

then the structure in tests folder should be

tests/
├── components/
│   ├── Product/
│   │   ├── product.test.js    

Many of the React formatting conventions derived from the Javascript conventions.