ksquareincmx / react-guidelines Goto Github PK

Title: State-related interfaces should have the following structure I[Component]State
Date: 26/02/2019
By: Rodrigo Mendez

Motivations

I see that you already have a similar rule for Prop-related interfaces, why not add one for State-related ones?

I know that we are favoring Functional Components over Class-based, but anyway we may need to use Class-based, and in that case we should also pass a State interface.

Sources

Personal experience

Title: always use template string
Date: 27/02/2019
By: Michell Ayala

Motivations

The plus operator (+) has implicit type casting, and you have to use special characters to represent blank spaces (\t, \n, etc).

Examples

String interpolation

// string concatenation
const name = 'Juan Perez'
console.log('Hello, my name is ' + name)

// template string
const name = 'Juan Perez'
console.log(`Hello my name is ${name}`)

Blank spaces

// without template strings
const message = 'Hello,\nHow are you?'
console.log(message)
// Hello,
// How are you, I'm fine.

// with template strings
const message = `Hello,
How are you?`
console.log(message)
// Hello,
// how are you?

Sources

How To Work with Strings in JavaScript

Title: favor object shorthand syntax
Date: 27/02/2019
By: Michell Ayala

Motivations

From eslint: ECMAScript 6 provides a concise form for defining object literal methods and properties. This syntax can make defining complex object literals much cleaner.

Examples

Variables and properties with the same names

// without object shorthand
const name = 'Juan Perez'
const user = {
  name: name
}

// with object shorthand
const name = 'Juan Perez'
const user = {
  name
}

Sources

ESlint docs

Title: Prefer destructuring for access to functions props and properties in objects
Date: 27/02/2019
By: Daniel Basulto

Motivations

1. Better understanding of functions interfaces.
2. Explicit better than implicit.
3. Avoid the use of the . for access to object properties.
4. In general contribute to code readability and maintainability.

Examples

// For props with "one nested level"

const user = {
 name: "John Doe",
 age: 50
};

// Good
const useUserInfo = (user) => {
  const { name, age } = user;
  //...
} 

// Better
const useUserInfo = ({ name, age }) => {
  //...
} 

useUserInfo(user);

// For props with "many nested levels"

const user = {
 name: {
    first: "John",
    last: "Doe"
 },
 age: 50
};

// Good
const useUserInfo = (user) => {
  const { name: { first, last }, age } = user;
  //...
} 

// This is the best for small objects
const useUserInfo = ({ name: { first, last }, age }) => {
  //...
} 

// This is the best for any size I think
const useUserInfo = ({ name, age }) => {
  const { first, last } = name;
  //...
} 

useUserInfo(user);

// For arrays

const carsList = [
  {
    brand: 'ferrari',
    type: 'sportscar',
    engine: {
        horsepower: 600,
        liters: 4,
        fuel: 'gas'
     },
     wheels: 4
  },
  {
    brand: 'porshe',
    type: 'sportscar',
    engine: {
        horsepower: 455,
        liters: 6,
        fuel: 'gas'
     },
     wheels: 4
  },
];

const [ferrari, porsche] = carsList;

Sources

ExploringJS. Destructuring
ES6 Destructuring: The Complete Guide
Destructuring MDN

Title: Factory Functions conventions
Date: 05/03/2019
By: Michell Ayala

Motivations

There are a few ways to create objects in javascript, one of those is Factory Functions (FF for short). We need some rules to differentiate FFs from classes and other methods.

Examples

The name of the function should be equal to the model they create.
For example, if we have a function that creates users, the user ff should be just named user.

// good
const user = () => ({
  name: 'John Doe'
})

// bad
const createUser = () => ({
  name: 'John Doe'
})

To differentiate them from classes FFs should be in camelCase

// good
const superUser = () => ({
  // ...
})

// bad
const SuperUser = () => ({
  // ...
})

Sources

JavaScript Factory Functions with ES6+

Title: Come up with a standard for using Redux
Date: 26/02/2019
By: Rodrigo Mendez

Motivations

We are using Redux in several projects internally, and I've seen a preference for the ducks standard, maybe we should standardize for using this standard? I know that Comoto has experience in this.

Sources

https://github.com/erikras/ducks-modular-redux
https://medium.freecodecamp.org/scaling-your-redux-app-with-ducks-6115955638be