---
# System prepended metadata

title: General Notes

---

# General Notes

## Repo Directory Structure

- `public`
  - `font`
  - `img`
- src
  - `config` - A single point entry for reading config values. All config value reads must pass through here
  - `constants` - For enumerations and magic strings
    - `routes`
    - `statuses`
    - ...other constants
  - `server` - Code that should be ran ONLY on the server lives here
    - `crytpo`
    - `profile`
    - ...other middlewares
  - `modules` - A place for each logical business unit. Typically 1:1 with `~/pages`. Each directory here acts as a logic boundary to keep a clean separation of concerns.
    - `verification`
    - `summary`
    - ...other business units
  - `pages` - These are required by NextJS to couple a `route` to a `module`
    - <routes only>.js
  - `services` - All service/api handlers live here
  - `stories` - Should contain stories ONLY for repo-specific compoents (read: non-common)
  - `utils` - The home for helpers, functions, utils, and any generic small functional units. Expect these to be battle tested and have full test coverage.
  - `shared` - Here you'll find components that are consumed by multiple `module`'s. They should be module-agnostic and not contain any module specific logic.
    - `DatePicker`
    - `Dialog`
    - ...
    - `hooks` - Where you'll find all the common hooks
      - `useThing` - Prefix all hooks with `use`

## Observations & Guidelines:

1. When importing from within the current top level directory:
   1. Use relative imports
      - `import Component from '../path/to/component';`
2. When importing something outside the current top level directory:
   1. Use aliased imports
      - `import Component from 'src/shared/Component';`
3. Use named exports everywhere, _excluding `~/pages` exports_
   1. Why excluding `~/pages`? Because NextJs requires default exports here.
   2. I wrote a post about default vs named exports: https://dev.to/n8io/developer-dark-arts-default-exports-31ia
4. Common data in context should be retrieved using hooks
   1. Why?
      - Hooks are easier to implement
      - Hooks are easier to test
      - Hooks are easier to encapsulate
      - Hooks are easier to move
   2. For every React context there should be a hook to access it
   3. Each hook acts as a selector, kind of like with Redux
5. Component implementation should be contained in a same named folder
   1. For example:
      - Header
        - `index.js`
        - `index.module.css`
        - `index.spec.js` - Spec co-located with implementation instead of in a `__tests__` dir
   2. Why?
      - Reduce overgrown directory contents
      - Co-locate implementation and spec files
6. Testing
   1. Mock child components to reduce noise and focus tests on first party functionality
   2. For presentational components we do a single inline snapshot test
   3. For control flow components we test conditional logic
