Coding Conventions

JavaScript

• Arrow functions params

  • Zero params: () => {}
  • One param: x => {}
  • Multiple params: (x, y) => {}

• Arrow functions implicit returns

  • () => true;
  • () => { return true; };

• if, for, else, ...

  • if () { something; }

• Semicolons not optional

• Naming camelCase

  • Except components and classes, those are PascalCase

• Destructuring

  • In functions
    • function something(arg) { const {a, b, c} = arg; ...}
  • In local code
    • const {a, b, c} = this.props;

• Imports

  • import x from './something';
  • import * as x from './something';
    • x.a()

• Requires

  • const x = require('./something');

• Exports

  • export default value;
  • export default function;
  • export const f1 = () => {...} export const f2 = () => {...}
  • function f1() {...} function f2() {...} module.exports = { f1, f2 }
  • module.exports = value;
  • module.exports = function;

• Async/await everywhere

React

• Components are folders with two files - ComponentUi.js and index.js

  • UI component is stateless functional component that defines UI
  • Container component renders UI component and attaches handlers, state and connects it to Redux IF NEEDED

• Functional components

  • destructuring
    • const Comp = ({p1, p2}) => {...}

• Code organization

  • Components
    • Component
      • ComponentsUi.js
      • index.js
  • Screens
    • module
      • submodule - concrete screen in module
        • Component1
          • Component1Ui.js
          • index.js
        • Component2
          • Component2Ui.js
          • index.js
        • ModuleScreenName
          • ModuleScreenUi.js
          • index.js
        • index.js

• Render method

  • When using conditionals, use this form:
    • something && something && Component ... Component

• Event handlers

  • When onsomething use handlesomething
    • onClick={handleClick}

Redux

• Separate properties for "data", "state" and "screens"?

Translations

• Naming must be done so it reflects what it is used for, not from technological point of view, but instead from user point of view
  • If there is a text that acts like a button, it should be named like it is a button or a link since from users point of view, that is a button or link, not a text
• Naming must be done so that name itself is enough to know what it represents on a screen, without opening screen every time to check
  • linkButton is not a good name since it doesn't have enough info on what this button links to — it should be something like changeEmailButton, even if this is the only button on the screen
• Global namespace should be used only for reusable, generic translations. Email is translated as Email, OK is translated as OK
  • But if there is an action dialog with two options (success and discard actions), it might be better to have dialogSuccessButton and dialogDiscardButton translations instead of global ok and cancel ones, even if the text is the same for those two
    • Think and choose what makes more sense for every use case
• Translations should be divided into module per screen with one global module
  • Inside a module, all translations should be flat without additional nesting
• Buttons
  • somethingButton
• Inputs
  • somethingInputLabel
  • somethingInputPlaceholder
• Messages
  • somethingMessage
  • somethingText
• Header
  • somethingHeader