✅ Coding standards

On this page

Naming Conventions Jump to heading

The objective of this document is to help when naming things and make the codebase consistent and easier to read.

Name Rules Jump to heading

🥳 Names should be always be Descriptive & Succinct. 🎉

😑 Names should not be Obscure or Abbreviated ❌

File Names Jump to heading

Name	Convention	Example
Index file	index.(ts/js)	index.ts
React component	ComponentName.(tsx/ts/js/jsx)	Button.tsx
Test file	ComponentName.test.(tsx/ts/js/jsx)	Button.test.tsx
TypeScript types	File.models.ts	Button.models.ts
Styles (CSS-in-JS)	ComponentName.styles.(ts/js)	Button.styles.ts
Storybook	ComponentName.stories.(tsx/ts/js/jsx/mdx)	Button.stories.tsx

HTML Jump to heading

Name	Convention	Example
Data Attributes	kebab-case	data-testid="button-element"
path	kebab-case	www.fairfx.com/this/is-a-path/

TypeScript Jump to heading

Name	Convention	Example
interface	PascalCase	interface DescriptiveInterfaceName
variables	camelCase	const descriptiveVariableName
function	camelCase	descriptiveFunctionName(){ ... }
class	PascalCase	class DescriptiveClassName { ... }
type	PascalCase	type DescriptiveTypeName
enums	PascalCase	enum DescriptiveEnumName { CONSTANT_A, CONSTANT_B, CONSTANT_C }
constant	CONSTANT_CASE	DESCRIPTIVE_CONSTANT_NAME

React Jump to heading

Name	Convention	Example
Component Props Interface	PascalCaseProps	ComponentNameProps
Component State Interface	PascalCaseState	ComponentNameState
Component Copy Interface	PascalCaseCopy	ComponentNameCopy

Function Component Jump to heading

import React, { FunctionComponent } from 'react'

const DescriptiveComponentName: FunctionComponent<IDescriptiveComponentNameProps> = (
  props
) => {
  return ()
}

    

Class Component Jump to heading

import React, { Component } from 'react'

class DescriptiveComponentName<
  IDescriptiveComponentNameProps,
  IDescriptiveComponentNameState
> extends Component {
  render () {
    return ()
  }
}

    

Code Structure Jump to heading

The objective of this document is to help when structuring your code, to make the codebase more consistent, reusable and easy to read.

This is a guide on how to structure your code.

Linting and code styling 💅 Jump to heading

• ❗️Code to be formatted using prettier
• ‼️ All code should follow the TypeScript standard and always make use of types

React Jump to heading

Composability Jump to heading

Components should ideally be composable, this makes them more flexible and reusable.

General rules about writing new components 🚦 Jump to heading

A standard practice is to avoid having too much functionality in one page with gigantic renders.
Each file should have 1 set of functionality.
Everything else should be broken into a new component and be included as a child.

Generic Jump to heading

Imports Jump to heading

Avoid * imports, it’s best to explicitly define what you want to export.

Types Jump to heading

Avoid a type of any it is normally not allowed.

Spread Syntax Jump to heading

Use nested spread syntax when appropriate. Code should be readable, don’t use nested spread syntax if it becomes hard to read.

Preferable Example ✅ Jump to heading

class MyComponent extends Component {
  public render() {
    const {
      myProp,
      nestedProps: { myNestedProp },
    } = this.props
  }
}

    

Also Good ✅ Jump to heading

class MyComponent extends Component {
  public render() {
    const { myProp, nestedProps } = this.props
    const { myNestedProp } = nestedProps
  }
}

    

Ok, if it’s only referenced once ✅ Jump to heading

class MyComponent extends Component {
  public render() {
    return this.props.nestedProps.myNestedProp.myMoreNestedProp
  }
}

    

File Structure rules 🚨👮 Jump to heading

Description ℹ️ Jump to heading

These rules must be followed by all team members in order to have a consistent and well structured codebase.

Pages Jump to heading

/src/client/pages
    /PageName
        index.ts
        PageName.tsx
        PageName.test.tsx
        PageName.schema.json
    /OtherPageName
        OtherPageName.tsx

    

Components should by default be placed in /components directory.

Components should be grouped into folders logically. If they are only used once and they are used within another component, they should be colocated with their parent component.

Example: Jump to heading

components/
├─ ComponentName/
│  ├─ __tests__/
│  │  ├─ ComponentNameView.spec.tsx
│  │  ├─ ComponentNameContainer.spec.tsx
│  ├─ ComponentName.operations.middleware.gql // Graphql queries
│  ├─ ComponentName.messages.ts // i18n content
│  ├─ ComponentName.models.ts // TS types
│  ├─ ComponentNameView.tsx // "dumb" React component
│  ├─ ComponentNameView.stories.tsx // Storybook stories
│  ├─ ComponentNameContainer.tsx // "smart" React component. fetches data etc
│  ├─ index.ts
│  ├─ README.md

    

👩🏻‍🏫 Storybook Jump to heading

Components should be built and tested with a ComponentName.stories.tsx and have a README.md file included.

👩🏻‍🔬 Test Jump to heading

Where possible ComponentName.test.tsx other files like utils will need a UtilName.test.ts.

💁🏻‍♀️ Styled Component Jump to heading

Separate styles from the main code, styles should live in ComponentName.styles.ts.

👷🏻‍♀️ Models Jump to heading

Separate interfaces and types from the main code, models should live in ComponentName.models.ts

---

← Back home