snappy-guidelines.md

Snappy Guidelines

Naming conventions

Variable naming

• Variable name should reflect the data it contains & the purpose
• Use camelCase for plain variables that contain data [functions, arrays, objects, ...]. (Incorrect: variable_name, _variable, VariableName)
  • For class use PascalCase.
  • For global constants use UPPER_CASE.
• Other rules are inherited from https://github.com/airbnb/javascript#variables

FS naming

• If the file/directory contains a React component - use PascalCase.
• If the file/directory contains a typescript / javascript code - use camelCase.
• Try to avoid longDirectoryName as much as possible, usually 1 word is enough

React component folder structure

components/
-- SmartHint/
-- -- data/
-- -- -- hints.json
-- -- assets/                   (or assets/?. For not common icons / images)
-- -- -- icon.svg              
-- -- index.ts                 (Just reexports SmartHint.container.tsx)
-- -- SmartHint.tsx            (contains Only UI logic / view)
-- -- SmartHint.styles.ts(x)
-- -- SmartHint.stories.tsx    (Storybook?)
-- -- SmartHint.container.tsx  (contains comonent business logic, redux / apollo)

Resolving modules

Path

• Do not include extension if it is in default resolved extensions (by webpack / CRA): ./file over ./file.ts
• Do not write index in the path: ./dir over ./dir/index
• Do not duplicate naming in path: ./button over ./button/button (use index file for reexport)

Import / Export

• Prefer named exports over default exports

Using aliases (@app/)

• When resolving is outside your current scope (../../../smth/...) - use aliases. Prefer @app/smth/...
• When resolving is inside your current scope (./components/ from @app/page/Home) - Don't use aliases. As you would prefer a relative path, then you are not relying on app structure (directory @app/page/Home could be easily moved somewhere)
  • One exclusion from this rule is common resolvings. For them prefer aliases. Example: @app/config instead of ./config

React

Components

• Use functional components instead of class components
• Components should expose as less controls as it should. (Use useImperativeHandle to expose component API. Never expose internal variables unless really needed)
• Avoid code duplication as much as possible. (More code = more errors)
• Use useCallback / useMemo for performance optimizations wisely.
• Event names:
  • handleItemClick - when you define event handler (usually in a container)
  • onItemClick - when it is a prop
• Prefer useRef over useState when you don't need visual component update (redraw)

Other

Redux

• Prefer using @reduxjs/toolkit instead of reselect

Styling

• For styling components use styled-components library
• Styling components should be done in a separate files with .styles.ts extension
• [TODO: Michael]