Props

• Always use camelCase for prop names.

  // bad
  <Foo
    UserName="hello"
    phone_number={12345678}
  />
  // good
  <Foo
    userName="hello"
    phoneNumber={12345678}
  />

• Omit the value of the prop when it is explicitly true. eslint: react/jsx-boolean-value

  // bad
  <Foo
    hidden={true}
  />
  // good
  <Foo
    hidden
  />
  // good
  <Foo hidden />

• Always include an alt prop on <img> tags. If the image is presentational, alt can be an empty string or the <img> must have role="presentation". eslint: jsx-a11y/alt-text

  // 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" />

• Do not use words like “image”, “photo”, or “picture” in <img> alt props. eslint: jsx-a11y/img-redundant-alt

  Why? Screenreaders already announce img elements as images, so there is no need to include this information in the alt text.

  // bad
  <img src="hello.jpg" alt="Picture of me waving hello" />
  // good
  <img src="hello.jpg" alt="Me waving hello" />

• Use only valid, non-abstract ARIA roles. eslint: jsx-a11y/aria-role

  // bad - not an ARIA role
  <div role="datepicker" />
  // bad - abstract ARIA role
  <div role="range" />
  // good
  <div role="button" />

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

  Why? Inconsistencies between keyboard shortcuts and keyboard commands used by people using screenreaders and keyboards complicate accessibility.

  // bad
  <div accessKey="h" />
  // good
  <div />

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

Why? Not using a stable ID @robinpokorny/index-as-a-key-is-an-anti-pattern-e0349aece318">is an anti-pattern because it can negatively impact performance and cause issues with component state.

We don’t recommend using indexes for keys if the order of items may change.

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

• Always define explicit defaultProps for all non-required props.

  Why? propTypes are a form of documentation, and providing defaultProps means the reader of your code doesn’t have to assume as much. In addition, it can mean that your code can omit certain type checks.

  // bad
  function SFC({ foo, bar, children }) {
  return <div>{foo}{bar}{children}</div>;
  }
  SFC.propTypes = {
  foo: PropTypes.number.isRequired,
  bar: PropTypes.string,
  children: PropTypes.node,
  };
  // good
  function SFC({ foo, bar, children }) {
  return <div>{foo}{bar}{children}</div>;
  }
  SFC.propTypes = {
  foo: PropTypes.number.isRequired,
  bar: PropTypes.string,
  children: PropTypes.node,
  };
  SFC.defaultProps = {
  bar: '',
  children: null,
  };

• Use spread props sparingly.

  Why? Otherwise you’re more likely to pass unnecessary props down to components. And for React v15.6.1 and older, you could pass invalid HTML attributes to the DOM.

  Exceptions:

• HOCs that proxy down props and hoist propTypes

  function HOC(WrappedComponent) {
  return class Proxy extends React.Component {
    Proxy.propTypes = {
      text: PropTypes.string,
      isLoading: PropTypes.bool
    };
    render() {
      return <WrappedComponent {...this.props} />
    }
  }
  }

• Spreading objects with known, explicit props. This can be particularly useful when testing React components with Mocha’s beforeEach construct.

  export default function Foo {
  const props = {
    text: '',
    isPublished: false
  }
  return (<div {...props} />);
  }

  Notes for use:
  Filter out unnecessary props when possible. Also, use prop-types-exact to help prevent bugs.

  // bad
  render() {
  const { irrelevantProp, ...relevantProps  } = this.props;
  return <WrappedComponent {...this.props} />
  }
  // good
  render() {
  const { irrelevantProp, ...relevantProps  } = this.props;
  return <WrappedComponent {...relevantProps} />
  }