App Structure

The app was initially built as a Create React Application and is, thus, structured as such. However, we are ever evolving and adopting standards from the whole React community.

General Principles

  • We MUST not add any more code into the /app directory.

Specific Directory Contents

  • /components - An older foler, the plan is to move all these to /shared-components

  • /components2 - An older foler, the plan is to move all these to /shared-components

  • /constants - Any shared constants, queries, fragments or other values

  • /context - React context

  • /generated - queries, mutations, documents generated from the operations.graphql file

  • /hooks - Any custom hooks used in multiple places

  • /pages - The specific page mapping to the specific route (see more below)

  • /routing - Top level routing

  • /shared-components - Any new reusable components that will be used in the app (e.g. Button) should be built into here now.

  • /testing - Any resuable testing functionality.

  • /types - Any types shared across the codebase

  • /utils - Any utils shared across the codebase

/Pages

We are adopting the Next.js philosophy where the /pages directly should directly map to a route in our application.

e.g. pages/dashboard.js โ†’ https://pathway.vetspire.com/dashboard\

The file structure should look something like this

  • /pages

    • /dashboard # Lowercase directory name, this MUST match the route*

      • /components # These will be components that are only used within this page

      • Dashboard.tsx # The top level file at this route

      • /graphql operations.graphql # Local operations file for queries/mutations only used at this route generated.tsx # Generated file only to be used at this route types.ts # local types

      • /hooks # Any custom hooks only used at this route

      • index.ts # Index file MUST export from main component i.e. export * from "./Dashboard"

      • /styles # Any local styles

Important notes

  • Routes MUST match EXACTLY (with the exception of routes with ids), this means for routes like https://staging.vetspire.com/forgot_password, the equivalent codebase path is: pages/forgot_password, even though this is snake_case, it's important we abide by this

  • Ids are the exception. For IDs we have decided to use the format of the singular postfixed with Id. This means that for example a route like this: https://staging.vetspire.com/clients/26205 would look like this as a path: pages/clients/clientId. So taking the dashboard example from above, clients and clientId would look like the following:

  • /pages

    • /clients

      • /components

      • Client.tsx

        • /clientId

          • /components

          • ClientId.tsx

          • /graphql operations.graphql generated.tsx types.ts

          • /hooks

          • index.ts

          • /styles

      • /graphql operations.graphql generated.tsx types.ts

      • /hooks

      • index.ts

      • /styles

  • The component name MUST match the route exactly. e.g. Client.tsx MUST be exported as export const Client

  • Nothing should be imported from pages/** with the exception of the route. This means that if have any place where we are doing something like the following: import { util } from "pages/dashboard/utils" this indicates a code smell. The solution in this instance would be to pull the util out to our top level shared utils Obviously we should be importing the top level route into our main routing file. So import { Dashboard } from "pages/dashboard" is desirable.

  • Import with relative paths when working within the same directory. When you moving a file from one directory to another VS code helpfully updates the route, however the route will always be updated to an absolute one. So, take the ClientId example above. When you are importing a component into ClientId from the local /components file it is recommended to do import { SpecificClientIdComponent } from "./components as opposed to import { SpecificClientIdComponent } from "pages/clients/clientId/components"

Last updated