Concepts
Naming Conventions

Naming Conventions

Definition of Case types:

  • kebab-case
  • camelCase
  • PascalCase
  • snake_case

NextJS Pages

Pages are components so: PascalCase

Components

  • Component name should be PascalCase

  • Component property names should be camelCase

    • Use 'on' prefix for event handlers. Example 'onClick' (corresponding function should be called 'handleClick')

  • Folder structure for UI components

src/some-feature/ComponentName/
  |- ComponentName.tsx - main component file
  |- ComponentName.stories.tsx - Storybook stories
  |- Componentname.spec.ts - Unit tests
  |- index.ts - export everything from main file (and possible other places)

Naming Components

When adding and naming components, have a look at UI Components Handbook (opens in a new tab). It contains good information on naming conventions for many common components and their properties.

Typescript Types

  • Preferable use Interfaces when defining object shapes
  • Interfaces names prefixed with capital i. And followed by PasacalCase name Examples: IUser, IUserState

Functions

  • camelCase
  • functions that are event handlers should use the 'handle' prefix. Example: 'handleClick' (for handling the onClick event)

Branch names

Branches should be lower case only. Dash for space (kebab-case). Prefixed by type + forwardslash. Followed by issue number (if avaailble) and then short descriptive name.

Example: fix/24-storybook-image-component

If you don't have an issue number, which you should try to have, just leave it out:

Example: refactor/bump-storybook-to-version-7

Possible types:

  • fix: Bug fixes
  • feat: New features or functionality
  • refactor: Code upgrades or refactors, bumping dependencies
  • docs: Documentation changes or additions
  • style: Minor changes that does not affect functionality
  • refactor: refactoring production code, eg. renaming a variable
  • test: Adding missing tests, refactoring tests; no production code change
  • chore: Updating editor settings, build scripts: no production code change

Pull Requests names and commit messages

Should include type, issue number and short name. Spaces in description are ok.

Example: fix[24]: Storybook Next component fix

Example without issue number: refactor: Bump Storybook to version 7

Issues

Issues should have a short clear description. Add labels to specify type of issue.

TestingArchitecture