Disallow the use of console

Using console.log during development is fine, but you shouldn't use console.log in production code.

In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console should be stripped before being pushed to production.

// bad
console.log('bad');

Require following curly brace conventions

Always wrap the block of code in curly braces when using conditionals.

JavaScript allows the omission of curly braces when a block contains only one statement. However, it is considered by many to be best practice to never omit curly braces around blocks, even when they are optional, because it can lead to bugs and reduces code clarity.

// bad
if (foo) foo++;

while (bar) baz();

if (foo) {
  baz();
} else qux();

// good
if (foo) {
  foo++;
}

while (bar) {
  baz();
}

if (foo) {
  baz();
} else {
  qux();
}

Require === and !==

Use strict equality or inequality operators.

It is considered good practice to use the type-safe equality operators === and !== instead of their regular counterparts == and !=. The reason for this is that == and != do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm. For instance, the following statements are all considered true:

• [] == false
• [] == ![]
• 3 == 03

// bad
a == b;
foo == true;
bananas != 1;
value == undefined;
typeof foo == 'undefined';
'hello' != 'world';
0 == 0;
true == true;
foo == null;

// good
a === b;
foo === true;
bananas !== 1;
value === undefined;
typeof foo === 'undefined';
'hello' !== 'world';
0 === 0;
true === true;
foo === null;

Disallow Null Comparisons

Use strict equality/inequality when checking null values.

Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

// bad
if (foo == null) {
  bar();
}

while (qux != null) {
  baz();
}

// good
if (foo === null) {
  bar();
}

while (qux !== null) {
  baz();
}

Disallow Early Use

Define the variable or function before using it.

In JavaScript, prior to ES6, variable and function declarations are hoisted to the top of a scope, so it's possible to use identifiers before their formal declarations in code. This can be confusing and some believe it is best to always declare variables and functions before using them. In ES6, block-level bindings (let and const) introduce a "temporal dead zone" where a ReferenceError will be thrown with any attempt to access the variable before its declaration.

// bad
alert(a);
const a = 10;

f();
function f() {}

function g() {
  return b;
}
const b = 1;

// good
let a;
a = 10;
alert(a);

function f() {}
f(1);

const b = 1;
function g() {
  return b;
}

Use const instead of let when a constiable is never reassigned.

If a variable is never reassigned, using the const declaration is better. const declaration tells readers, "this variable is never reassigned," reducing cognitive load and improving maintainability.

// bad

// it's initialized and never reassigned.
let a = 3;
console.log(a);

let a;
a = 0;
console.log(a);

// `i` is redefined (not reassigned) on each loop step.
for (let i in [1, 2, 3]) {
  console.log(i);
}

// `a` is redefined (not reassigned) on each loop step.
for (let a of [1, 2, 3]) {
  console.log(a);
}

// good

// using const.
const a = 0;

// it's never initialized.
let a;
console.log(a);

// it's reassigned after initialized.
let a;
a = 0;
a = 1;
console.log(a);

// it's initialized in a different block from the declaration.
let a;
if (true) {
  a = 0;
}
console.log(a);

// it's initialized at a place that we cannot write a variable declaration.
let a;
if (true) {
  a = 0;
}
console.log(a);

// `i` gets a new binding each iteration
for (const i in [1, 2, 3]) {
  console.log(i);
}

// `a` gets a new binding each iteration
for (const a of [1, 2, 3]) {
  console.log(a);
}

Suggest using template literals instead of string concatenation

Use template literals instead of string concatenation.

// bad
const str = 'Hello,' + name + '!';
const str = 'Time: ' + 12 * 60 * 60 * 1000;

// good
const str = 'Hello World!';
const str = `Hello, ${name}!`;
const str = `Time: ${12 * 60 * 60 * 1000}`;

No unescaped entities

This rule prevents characters that you may have meant as JSX escape characters from being accidentally injected as a text node in JSX statements.

// bad
<MyComponent
  name="name"
  type="string"
  foo="bar">  {/* oops! */}
  x="y">
  Body Text
</MyComponent>

// good
<MyComponent>{'Text'}}</MyComponent>

DISABLE missing React variable when using JSX

This is rule is turned "off" because we use React as a global variable.

DISABLE prop types validation

This is rule is turned "off" because prop types are not generally used in our projects.

Detect raw text outside of Text component

All strings in React Native should be wrapped with a Text component.

// bad
<View>some text</View>

const text = 'some text';
<View>{`${text}`}</View>

// good
<View><Text>some text</Text></View>
const text = 'some text';
<View><Text>{`${text}`}</Text></View>

No Single Element Style Arrays are allowed

These cause unnecessary re-renders as each time the array's identity changes.

// bad
<View style={[{height: 10}]} />

// good
<View style={{ height: 10 }} />