# Conventional Guideline

## ESLint
We use ESLint google's template for linting, with added rules as follows:
```
'rules': {
    'indent': ['error', 4, {'SwitchCase': 1}],
    'linebreak-style': 0,
    'global-require': 0,
    'eslint linebreak-style': [0, 'error', 'windows'],
    'max-len': 0,
},
```
- **indent**: with 4 spaces, with added SwitchCase rule.
- **linebreak-style / eslint linebreak-style**: some windows error avoidance.
- **global-require**: 
- **max-len**: avoid because sometimes you need longer lines and line-breaking it would make it uglier.

Once we are done with general styles there are some conventions which helps.

## Request Status
When managing requests statues (need for rendering loader component or proper feedback message), we used to use a simple `{loading: true, success: false, error: false}` Object, but it was visually complex so we chose to create an enum (or equivalent).
```javascript
const REQUEST_STATUS = {
    NONE: 'NONE',
    LOADING: 'LOADING',
    SUCCESS: 'SUCCESS',
    ERROR: 'ERROR',
}
```
Note: the order of the requests are intentional, none -> loading -> success -> error. Why? Because in Redux when we declare action constants we usually create 3 actions for a request:
```javascript
export const AN_ACTION = 'AN_ACTION';
export const AN_ACTION_SUCCESS = 'AN_ACTION_SUCCESS';
export const AN_ACTION_ERROR = 'AN_ACTION_ERROR';
```
Additionally, an action request should not be `AN_ACTION_REQUEST` because its redundant. When we name an action, it should imply there is a request involved. 
Example:
```javascript
export const GET_USER_DATA = 'GET_USER_DATA';
```

## imports and exports
Imports should have two empty lines after them.
```javascript
import './anAwesomeStyleIMade.css';
import {Too, Many, Components} from '../another-module/components';
import {
    some,
    conts,
    iNeed,
} from '../utils/const';


const definedConstant = 'hello';
// etc
```

Exports should also have two empty lines but before them. You might have multiple exports so the first one should have two empty lines, and then separate each export from another with 1 empty line. The file should always have the last line empty.
```javascript
const definedConstant = 'hello';


export someFunction() {
    //...
}

export {
    other,
    things,
}

```

## Switch
Switch can be ambiguos in the details like indentation, so here are the rules we set.
```javascript
switch (type) {
    case 'one': 
        console.log('one');
        break;
    case 'one': break;
    case 'three': return 'three';
    default: break;
}
```

Short cases block code should have no separation, but when we have larger cases its okay to add 1 empty separation line

## Array and objects
When declaring an array or object, we may have them written vertically. When this happens, every item will have a comma at the end. An exception is when the array or object is declared in a single line
```javascript
const myArray = [
    'aaaa',
    'bbbb',
    'cccc',
];
const inlineArray = ['aaaa', 'bbbb', 'cccc'];
```

## Spaces inside {} and []
No space will be used.
```javascript
import react, {Component} from 'react';
import {someFunction, getThings} from '../../utils/useful';


const hello = {hello: 'hello', world: 'world'};
```

## Functional too many props
This should be avoided.
```javascript
const AFunctionalComponent = ({
                                too, many, props, lorem, ipsum, too, many, props, 
                                lorem, impsum, too, many, props, lorem, ipsum, 
                                too, many, props, lorem, ipsum, too, many, props,                            
                            }) => {
    return (
        // everything
    );
}
```
Instead do this. If possible, declare const variables vertically instead of stacking them in a block size, as it will make less readable the code.
```javascript
const AFunctionalComponent = (props) => {
    const {
        too, many, props, lorem, ipsum, too, many, props, 
        lorem, impsum, too, many, props, lorem, ipsum, 
        too, many, props, lorem, ipsum, too, many, props,                         
    }
    return (
        // everything
    );
}
```

## Props variables vs function props
When having variables and functions in props, there should be a way to cleary identify them, and sometimes the variable names doesnt make that clear. Thats why we chose to use this strategy: for variables, they will be declared inside the component like `const name = props.name;` or `const {name, surname} = props;`. For functions, they will NOT be declared and always called like `props.onSubmit()` or `...(e) => props.onChange(e)`.

## i18n structure
This structure will be used mostly to work with i18n Ally vscode extension.
```
/src/i18n/
    index.js
    en.json
    es.json
    ...
```

### i18n Ally?
This vscode extension is very useful extension for managing i18n, and it will help you find incomplete traductions and differences between languages, as well as quickly prompt you new translation or modify them. If you are using i18n and vscode its very recommended.

## React Native styles constant
The style constant is usually very long, and when defining a component, it should be in the end, even after the export section. Note that we will use 2 line empty spaces from export.
```javascript
import asd from './asd';


const MyComponent = (props) => {
    return (
        // render things
    )
}


export default MyComponent;


const styles = StyleSheet.create({
    // styles
}) 
```