Expectations

• Compatible with some RSC/SSR frameworks - fetch requests should exist independently.

• Good invalidation possibilities - prefix and predicate statements defined in one place.

• Axios library (with a simple replacement with native fetch, e.g. in Next.js case).

• There is no way to generate hooks for Your project, e.g. via GraphQL Codegen. See TanStack Docs.

Project structure

• Globally shared hooks

  • One folder to rule them all: ~/src/queries (or separate mutations into their own ~/src/mutations folder).

  • It is somehow similar to the result of a code generator.

• Component-based hooks

  • The main concept is high cohesion - hooks are placed according to usage as near as possible to the components that import them.

  • For more details, see React folder structure.

Each file is named according to its react hook and exports all types, fetch requests and the hook itself (or query option). For example, we have a REST endpoint GET /api/v1/users. Method GET and unique entity name Users are included in the final hook name.

The same naming convention is applied to mutations:

We also need to manage and store query keys and invalidation groups in case of queries. Never define them inside hooks. The whole set of keys EOT will become a mess in this case. Query keys are similar to primary keys in databases, so it is good to normalize them. See database normal forms - 1NF, 2NF, and 3NF (normalization is not required, but it helps a lot).

Query keys and invalidation groups

It is a good idea to define one file that will manage all query keys across an app.

// ~/src/configs/tsq.ts

import type { Query, QueryKey } from '@tanstack/react-query';

type Filters = { [key: string]: string | number | undefined };
type QueryKeyList = { [key: string]: (...args: never[]) => QueryKey };
type QueryKeyPredicate = (query: Query) => boolean;
type QueryKeyInvalidationList = {
  [key: string]: QueryKey | QueryKeyPredicate | ((...args: never[]) => QueryKeyPredicate);
};

/**
 * List of QueryKeys
 */
export const QK = {
  // Examples
  // getSomeEntity:                  ()                                => ['group', 'key'],
  // getSomeEntityWithFilter:        (filters: Filters)                => ['group', 'key', filters],
} as const satisfies QueryKeyList;

/**
 * Query invalidators (by prefix and by predicate)
 * See https://tanstack.com/query/latest/docs/framework/react/guides/query-invalidation
 */
export const QK_INVALIDATION = {
  // Examples
  // prefixKeyFromQK:   QK.getSomeEntity(),
  // prefixKeyCustom:   ['group'],
  // predicateKey:      (query: Query) => query.queryKey.includes('organizationContext'),
  // genPredicateKey:   (pageSize: number) => (query: Query) => (query.queryKey[1] as {[key: string]: unknown})?.pageSize === pageSize,
} as const satisfies QueryKeyInvalidationList;

useQuery template

// ~/src/queries/useQueryGetEntity.ts

import { keepPreviousData, queryOptions } from '@tanstack/react-query';
import { AxiosInstance } from 'axios';
import { QK } from '~/src/configs/tsq.ts';

/**
 * useQuery<MethodEntity>.ts
 *
 * <MethodEntity> | <methodEntity>
 * Choose a method from API: GET, POST, PUT, DELETE, PATCH, ... that represents action.
 * Choose an entity name: User, OrderList, Orders, InstitutionEnum, ... that represents a resource.
 * These names are used to create a name <MethodEntity> for the API endpoints: GetInstitutionEnum, PostUser, ...
 */

/**
 * <MethodEntity>RequestData (optional)
 * Request data - used for a request creation.
 */
export type GetEntityRequestData = {
  id: number;
  queryParams: {
    // Pagination
    page: number;
    limit: 10 | 25 | 50 | 100;
    // Filters
    search?: string;
  };
};

/**
 * <MethodEntity>ResponseData (required)
 * Response data - returned from the server (inside body).
 * This type should not be declared anywhere else and should not use any external type declarations (out of this file).
 * This file is a single source of truth that defines a behavior of the endpoint.
 */
export type GetEntityResponseData = {
  id: number;
  name: string;
  quantity: number;
};

/**
 * <methodEntity>Request (required)
 * Request - stand-alone request. For SSR and RSC pre-fetch purposes.
 * @param axios - Axios client. It is parametrized to allow SSR and RSC to use different Axios instances.
 * @param requestData - Static data used for request creation.
 * @returns Callable function for a request.
 */
export const getEntityRequest =
  ({ axios, requestData }: { axios: AxiosInstance; requestData: GetEntityRequestData }) =>
  () =>
    axios.get<GetEntityResponseData>(`/api/mock/users/${requestData.id}`).then((res) => res.data);

/**
 * <MethodEntity>QueryRequestData (optional)
 * Query options - used for query config creation (server prefetch and client fetch).
 */
export type GetEntityQueryRequestData = {
  requestData: GetEntityRequestData; // required if request is parametrized
};

/**
 * <methodEntity>QueryOptions (required)
 * Query options - used for query creation (server prefetch and client fetch).
 * @param axios - Axios client.
 * @param queryRequestData - Static data used for query creation. Includes request data.
 * @param select - Custom selector.
 */
export const getEntityQueryOptions = <T>({
  axios,
  queryRequestData,
  select,
}: {
  axios: AxiosInstance;
  queryRequestData: GetEntityQueryRequestData;
  select?: (data: GetEntityResponseData) => T;
}) =>
  queryOptions({
    queryKey: QK.enumProducts(),
    queryFn: getEntityRequest({ axios, requestData: queryRequestData.requestData }),
    placeholderData: keepPreviousData,
    select,
  });

// Custom selectors that can be used with query options.

export const selectGetEntityItemsQuantity = (data: GetEntityResponseData) => data.quantity;

useMutation template

// ~/src/mutations/useMutationPatchEntity.ts

import { useMutation } from '@tanstack/react-query';
import { AxiosInstance } from 'axios';

/**
 * useQuery<MethodEntity>.ts
 *
 * <MethodEntity> | <methodEntity>
 * Choose a method from API: GET, POST, PUT, DELETE, PATCH, ... that represents action.
 * Choose an entity name: User, OrderList, Orders, InstitutionEnum, ... that represents a resource.
 * These names are used to create a name <MethodEntity> for the API endpoints: GetInstitutionEnum, PostUser, ...
 */

/**
 * <MethodEntity>RequestStaticData (optional)
 * Request static data - used for a request creation. Data not changing with each request (e.g. ID of the entity).
 */
export type PatchEntityRequestStaticData = {
  id: number;
};

/**
 * <MethodEntity>RequestData (optional)
 * Request dynamic data - used for a request call (e.g. user input).
 */
export type PatchEntityRequestDynamicData = {
  name: string;
};

/**
 * <MethodEntity>ResponseData (required)
 * Response data - returned from the server (inside body).
 * This type should not be declared anywhere else and should not use any external type declarations (out of this file).
 * This file is a single source of truth that defines a behavior of the endpoint.
 */
export type PatchEntityResponseData = {
  id: number;
  name: string;
};

/**
 * <methodEntity>Request (required)
 * Request - stand-alone fetch.
 * @param axios - Axios client
 * @param requestStaticData - Request static data
 * @param () => requestDynamicData - Request dynamic data
 */
export const patchEntityRequest =
  ({
    axios,
    requestStaticData,
  }: {
    axios: AxiosInstance;
    requestStaticData: PatchEntityRequestStaticData;
  }) =>
  (requestDynamicData: PatchEntityRequestDynamicData) =>
    axios
      .patch<PatchEntityResponseData>(`/api/mock/users/${requestStaticData.id}`, requestDynamicData)
      .then((res) => res.data);

/**
 *
 * <methodEntity>MutationStaticData (optional)
 * Mutation static data - used for mutation and request creation.
 */
export type PatchEntityMutationRequestData = {
  requestStaticData: PatchEntityRequestStaticData;
};

/**
 * useMutation<MethodEntity> (required)
 * React hook - used for mutation creation.
 * @param axios - Axios client.
 * @param mutationStaticData - Static data used for mutation creation.
 */
export const useMutationPatchEntity = ({
  axios,
  mutationStaticData,
}: {
  axios: AxiosInstance;
  mutationStaticData: PatchEntityMutationRequestData;
}) =>
  useMutation({
    mutationFn: patchEntityRequest({
      axios,
      requestStaticData: mutationStaticData.requestStaticData,
    }),
  });

Usage

Both templates are almost agnostic and should be suited for each request. Let's say that we have an endpoint for user private projects:

GET /api/v2/users/project?type=private

Our hook is called useQueryUserProjects to make it universal because of the possibility of some public projects, etc. We need static data with a project type, a response type is generated from OpenAPI definition, and there is no need to configure fetch request with each hook call (only request itself, because of server calls):

// ~/src/configs/tsq.ts

import type { Query, QueryKey } from '@tanstack/react-query';

type Filters = { [key: string]: string | number | undefined };
type QueryKeyList = { [key: string]: (...args: never[]) => QueryKey };
type QueryKeyPredicate = (query: Query) => boolean;
type QueryKeyInvalidationList = {
  [key: string]: QueryKey | QueryKeyPredicate | ((...args: never[]) => QueryKeyPredicate);
};

export const QK = {
  // ...
  getUserProjects:  (filters: Filters) => ['users', 'projects', filters],
} as const satisfies QueryKeyList;

// optional
export const QK_INVALIDATION = {
  prefixUsers: ['users'],
  prefixUserProjects: ['users', 'projects'],
} as const satisfies QueryKeyInvalidationList;

// ~/src/queries/useQueryGetUserProjects.ts

import { keepPreviousData, queryOptions } from '@tanstack/react-query';
import { AxiosInstance } from 'axios';
import ApiTypes from '~/swagger-types';
import { QK } from '~/src/configs/tsq'

export type GetUserProjectsRequestData = {
    type?: string;
};

export type GetUserProjectsResponseData =
    ApiTypes.paths['/api/v2/users/project']['get']['responses']['200']['content']['application/json'];

export const getUserProjectsRequest =
    ({ axios, requestData }: { axios: AxiosInstance; requestData: GetUserProjectsRequestData }) =>
    () =>
        axios
            .get<GetUserProjectsResponseData>('/api/v2/users/project', {
                params: {
                    type: requestData.type,
                },
            })
            .then((res) => res.data);

export type GetUserProjectsQueryRequestData = {
    requestData: GetUserProjectsRequestData;
};

export const getUserProjectsQueryOptions = <T>({
  axios,
  queryRequestData,
  select,
}: {
  axios: AxiosInstance;
  queryRequestData: GetUserProjectsQueryRequestData;
  select?: (data: GetUserProjectsResponseData) => T;
}) =>
  queryOptions({
    queryKey: QK.getUserProjects({ type: queryRequestData.requestData.type }), 
    queryFn: getUserProjectsRequest({ axios, requestData: queryRequestData.requestData }),
    placeholderData: keepPreviousData,
    select,
  });

// Component.tsx

import axiosClient = '~/axios';
import { getUserProjectsQueryOptions } from '~/src/queries/useQueryGetUserProjects.ts';

export const Component = () => {
  const { data: dataGetUserProjects, isFetching: isFetchingGetUserProjects } = useQuery(
    getUserProjectsQueryOptions({
      axios: axiosClient,
      queryRequestData: {
        requestData: {
          type: 'private'
        },
      },
    }),
  );

  return <>...</>;
};

The original interface is preserved - it has consistency, and it is easy to extend. At first, it may feel like there is a lot of code for just one simple request - yes, deal with it. It may be shorter, but then it is less extendable, and EOT each request is going to have its own special way of calling it.

Let's assume getting a project with an unknown manager (at least for the first 5 seconds) or just a situation when we work with multiple projects having different managers. It may become a little bit annoying to pay attention to which manager we need.

The ni is a CLI utility that recognizes a project package manager according to its lock file (yarn.lock, package-lock.json, etc.) and uses appropriate commands. At least basic ones that could be unified.

Installation

npm i -g @antfu/ni

Also, it is better to create a config ~/.nirc with default values.

defaultAgent=npm
globalAgent=npm

Usage

Examples below are based on the yarn commands.

ni      # yarn install
ni X    # yarn add X
ni -D X # yarn add -D X
nr dev  # yarn run dev
na      # yarn

A full list is defined at README.md of the library.

It is nothing too special, but it removes a tiny annoying part during app development.

These recommendations aren't a silver bullet for every project. Apart from the "casual one", which is described below, library-structured monorepo projects, micro frontends, etc., have their own issues and requirements. Each project needs to consider complexity, future development, available budget and other aspects.

Let's discuss a project that could become a medium-sized app with hundreds of components. Consider Next.js, AppRouter, without workspaces and a comfortable budget:

• define potential issues to be avoided or reduced,

• define axioms, rules and suitable design patterns,

• go through different use cases with implementation.

Issues to be avoided or reduced

• Variables/functions/components are imported from "random" places in the project, which makes it hard to understand which parts of the app may be affected by changes.

• An unreasonable number of files in one directory makes the whole project messy.

• Exporting everything from everywhere makes it unclear which components can be used without context (e.g. NavItem is dependent on Nav).

• Too high or too low granularity in terms of code per file.

Expectations

• A project can contain hundreds of pages, and it is obvious where components are used.

• Folder structure may be used with or without Next.js.

• Understandable for juniors - a clear structure of folders, files and file naming.

Design patterns & concepts

• Component-based principle – components emphasise a separation of concerns and distribute themselves as a black-box functionality with the possibility to extend.

• Component High cohesion – a component has everything in one place (its file/folder) except shared dependencies or special cases.

• Compound pattern – a JSX component that has its own optional structure (e.g. Card, CardBody) and uses a compound structure (e.g. Card, Card.Body) to prevent confusing exports.

Structural principles

• Application code related to the functionality is inside ./src folder aliased by @/ path (src root).

  • _(.*) are special Next.js folders, _ could be avoided without the framework.

  • @/app is the AppRouter folder containing pages, see Next.js docs.

  • @/**/* files could be divided into 2 groups - React components and "secondary variables" (= constants, utils, hooks, ...).

• ReactComponent is a file or folder having exactly the same interface/behaviour as a file. Both export 1 main component ± secondary variables.

  • File – ComponentName.tsx contains exactly 1 React component and may have secondary stuff. Everything uses named export. However, secondary variables cannot be used without a relation to the component. Otherwise, see Shared Code and Implementation below.

  • Folder – ComponentName has a similar interface as a file – exposes 1 React component and secondary variables via ComponentName/index.ts so that it can replace a file ComponentName.tsx without redefining imports across a project. Besides the component itself, inside the folder, we can define other files/folders that are required for its instance. All imports within the folder are relative.

• Shared Code – everything that needs to be used in multiple parts of the project.

  • Component-related – secondary variables can exported from the file/folder with the main component. These variables should be used only with this component. E.g. Nav also provides NavItem, or some special hooks.

  • Shared between ReactComponents – the shared variable is separated into a stand-alone file, placed into _(.*) folder according to its type and put into the nearest common parent folder. Since separation, all imports of this variable should be absolute @/.

  • Global modules – some items expected to be used everywhere – typically form fields, buttons, auth hooks, GraphQL Fragments, etc. They are placed in root folders ./src/_(.*)/ according to their type.

The project follows the naming conventions described in the cheat sheet.

Implementation

Let's assume that we need to create a blog page. We start with one file and extend a structure step by step.

Pages

Let's begin with a homepage – a list of articles. URI http://localhost/blog, a page file always has page.tsx filename. We assume that routes are auto-detected by Next.js or manually declared with a router library.

./src
└── app
   └── blog
      └── page.tsx

URI http://localhost/blog/article/unique-slug contains chosen article:

./src
└── app
   └── blog
      ├── articles
      │  └── [slug]
      │     └── page.tsx
      └── page.tsx

Pages use default export - Next.js requirement and React Router lazy loading compatibility.

// src/app/blog/page.tsx
const BlogPage = () => <></>;

export default BlogPage;

Simple React component

The blog page renders multiple ArticlePreview components. An article is rendered by Article component.

./src
└── app
   └── blog
      ├── _components
      │  └── ArticlePreview.tsx
      ├── articles
      │  └── [slug]
      │     ├── _components
      │     │  └── Article.tsx
      │     └── page.tsx
      └── page.tsx

All components use named export, which ensures the same component name within an application.

// src/app/blog/articles/[slug]/_components/Article.tsx
export const Article = () => <></>;

Shared React component

We discovered that ArticlePreview and Article need to use the same UI component Rating - let's find the nearest parent folder of both components and create Rating.tsx inside type-related folder (_components).

./src
└── app
   └── blog
      ├── _components
      │  ├── ArticlePreview.tsx
      │  └── Rating.tsx
      ├── articles
      │  └── [slug]
      │     ├── _components
      │     │  └── Article.tsx
      │     └── page.tsx
      └── page.tsx

Rating is an independent component. For ArticlePreview it is a sibling node within /blog/_components folder (main component inside page.tsx) – relative import. For Article it is a component in the upper structure – absolute import.

// src/app/blog/_components/ArticlePreview.tsx
import { Rating } from './Rating';
export const ArticlePreview = () => <Rating />;

// src/app/blog/articles/[slug]/_components/Article.tsx
import { Rating } from '@/app/blog/_components/Rating';
export const Article = () => <Rating />;

Complex React component

Article seems to be too long and needs to be divided into smaller parts – ArticleHeader, ArticleBody. Both of them cannot be used without Article.

At first, we transform the file component into a folder component.

./src
└── app
   └── blog
      └── articles
         └── [slug]
            └── _components
               └── Article
                  ├── Article.tsx
                  └── index.ts

// src/app/blog/articles/[slug]/_components/Article/index.ts
export { Article } from './Article';

Interfaces were preserved. Then we add Article-related components.

./src
└── app
   └── blog
      ├── _components
      │  ├── ArticlePreview.tsx
      │  └── Rating.tsx
      ├── articles
      │  └── [slug]
      │     ├── _components
      │     │  └── Article
      │     │     ├── Article.tsx
      │     │     ├── ArticleBody.tsx
      │     │     ├── ArticleHeader.tsx
      │     │     └── index.ts
      │     └── page.tsx
      └── page.tsx

Usually, the main component should be the only one exported from the folder. In case that ArticleHeader and ArticleBody need to be used outside Article, we may export them with the Compound Pattern (recommended way) or directly from the Article folder:

// src/app/blog/articles/[slug]/_components/Article/index.ts
export { Article } from './Article';
export { ArticleBody } from './ArticleBody';
export { ArticleHeader } from './ArticleHeader';

In this case, we need to handle them as strictly bounded and not use them without Article or, even worse, inside another React Component as a shared one, as we do with Ratings.

Complex React component - Compound Pattern

To prevent exporting useless (on their own) components:

./src
└── app
   └── blog
      └── articles
         └── [slug]
            └── _components
               └── Article
                  ├── Article.tsx
                  ├── ArticleBody.tsx
                  ├── ArticleHeader.tsx
                  └── index.ts

// src/app/blog/articles/[slug]/_components/Article/Article.tsx
import { Rating } from '@/app/blog/_components/Rating';
import { ArticleBody } from './ArticleBody'
import { ArticleHeader } from './ArticleHeader'

export const Article = () => <Rating />;

Article.Body = ArticleBody;
Article.Header = ArticleHeader;

// src/app/blog/articles/[slug]/page.tsx
import { Article } from './_components/Article';

const Page = () => (
   <Article>
     <Article.Header />
     <Article.Body />
   </Article>
);
export default Page;

Additional secondary items (hooks, validations, etc.)

ArticleHeader needs to have a useColoredPart hook. It isn't shared with Article and belongs only to the ArticleHeader. ArticleHeader stops to be a simple file component and imports the hook with a relative path (we are inside a folder component).

./src
└── app
   └── blog
      └── articles
         └── [slug]
            └── _components
               └── Article
                  ├── Article.tsx
                  ├── ArticleBody.tsx
                  ├── ArticleHeader
                  │  ├── ArticleHeader.tsx
                  │  ├── index.ts
                  │  └── useColoredPart.ts
                  └── index.ts

It is possible to create a special folder for same-type components. E.g. /hooks, /validations, /constants, etc.

./src
└── app
   └── blog
      └── articles
         └── [slug]
            └── _components
               └── Article
                  ├── Article.tsx
                  ├── ArticleBody.tsx
                  ├── ArticleHeader
                  │  ├── ArticleHeader.tsx
                  │  ├── hooks
                  │  │  ├── useColoredPart.ts
                  │  │  └── useSomethingSpecial.ts
                  │  └── index.ts
                  └── index.ts

Global components

Article now needs useColoredPart.ts and the hook is expected to be used in many, many others. This type of module could be declared as a global one. The same logic has, e.g., UI JSX components. We move them to the root.

./src
├── _components
│  ├── Button.tsx
│  └── FormFieldText.tsx
├── _hooks
│  └── useColoredPart.ts
└── app
   └── blog
      ├── _components
      │  ├── ArticlePreview.tsx
      │  └── Rating.tsx
      ├── articles
      │  └── [slug]
      │     ├── _components
      │     │  └── Article
      │     │     ├── Article.tsx
      │     │     ├── ArticleBody.tsx
      │     │     ├── ArticleHeader
      │     │     │  ├── ArticleHeader.tsx
      │     │     │  ├── index.ts
      │     │     │  └── useSomethingSpecial.ts
      │     │     └── index.ts
      │     └── page.tsx
      └── page.tsx

These components theoretically may be used across projects. Absolute imports inside nested folders, relative within the same level.

A similar concept is used, e.g., by the npm package manager, which places installed dependencies into a file system tree. The only difference is that npm considers all dependencies root-first, not leaf-first.

Conclusion

Pros

• It is evident which part of an application we can affect after changes in any file.

• Rules for imports reduce the number of required import changes across an app in cases of moving or adding complexity to a component.

Cons

• We continually need to check if all rules are fulfilled, especially the rule about the location of the shared component in the nearest common parent folder.

Variable name formats

It is good to restrict name formats to those listed below unless there is an extraordinary reason (e.g. pairing with database column names):

• camelCase – default name format,

• PascalCase – format of classes, types, enum-like structures, interfaces and special structures (e.g. React component names),

• SCREAMING_SNAKE_CASE – global constants.

We can use full words (properties), abbreviations (props) and acronyms within variable names.

• 2 letter acronyms are uppercase.

• 3+ letter acronyms are lowercase.

// 2 letters
const TranslationsEn = {};  // abbreviation
const enTranslations = {};  // abbreviation
const adminUI = {};         // acronym
const adminUIAdvanced = {}; // acronym
const UIButton = {};        // acronym

// 3+ letters
type ComponentProps = {};  // abbreviation
const htmlTags = [];       // acronym
const copyHtml = () => {}; // acronym

Custom values

All variables must be named to reflect the meaning of the stored value. The name format is chosen according to the list above. In special cases (boolean values, enums, etc.), variable names may use a unique prefix or rule to distinguish themselves from the rest.

// <variableDescription>
const result = 1;
const nextMiddleware = "logger";

// <VARIABLE_DESCRIPTION>
const ENVIRONMENT_VARIABLE = process.env.ENVIRONMENT_VARIABLE;

Boolean values - is, are, has

These variables should only contain true/false boolean (not string) values and thus implicitly declare that they are safe to use in conditions.

// (is|are)[<Noun>]<Adjective>
const isSubmitted = false;
const isFormASubmitted = false;
const isFormBSubmitted = false;
const areFormsSubmitted = isFormASubmitted && isFormBSubmitted;

// (is|are)<Action>
const isFetching = true;

// has<SubjectDescription>
const hasAtLeastOneOddNumber = true;

// Global constant with IS prefix
const IS_DEBUG_MODE = true;

Prefixes is/are have a priority over has – don't name a variable hasDefinedStatus when you can use isStatusDefined. The prefix has should be used in cases that cannot be comfortably replaced with is/are, e.g. hasTwoElementsFromArray.

Negation

Sometimes, negation is used as frequently as the original value, or we need to operate with negative statements only. In these cases, we can use a secondary Not prefix.

const isFormatted = false;
const isNotFormatted = !isFormatted;

Enums

Enums have a special behaviour - TypeScript enum as a type is not the best concept, according to the TypeScript Team. Therefore it is better to use an object with as const structure (explanation). According to Google JS Guide, we can think of this object as a special structure (PascalCase) containing constants (SCREAMING_SNAKE_CASE).

const RequestStatus = {
   PENDING: 'Pending',
   SUCCESS: 'Success',
   ERROR: 'Error',
} as const;

type RequestStatus = (typeof RequestStatus)[keyof typeof RequestStatus];

// Usage
RequestStatus.SUCCESS;

Types, interfaces and generics

Types use PascalCase and do not need a special prefix. Interfaces and generics have one letter prefix because of their special use cases (useful mainly in libraries).

// <TypeName>
type SystemProps = {};

// I<InterfaceName>
interface ISystemProps {}

// T<GenericType>
const createValue = <TInputValue>(value: TInputValue) => {
   return value;
};

Event handlers

Event handlers (callbacks) are functions that are called after an event – e.g. HTML onclick, oncontextmenu, React events, etc.

// handle[<Object>]<Action>
const handleClick = () => {};           // click is clearly defined
const handleSendButtonClick = () => {}; // one of many click events
const handleSignOut = () => {}          // multi-usage close callback

• Object - defines unique items that we interact with. It is optional if the handler is called from multiple places or if it is unique within the code part.

• Action - an action caused by a user.

React applications are a special case using onX={handleX} pairs.

type ComponentProps = {
   onSignInFormSubmit: () => {};
};

const Component = ({ onSignInFormSubmit }: ComponentProps) => {};

const Parent = () => {
   const handleSignInFormSubmit = () => {};
   return <Component onSignInFormSubmit={handleSignInFormSubmit} />
}

It is better to not name handlers with on prefix unless you, for example, want to create an auto-spreading structure of build-in properties (using spread syntax with prop names onClick, etc.). Detailed explanation: Event Handler Naming in React (by Jake Trent).

Functions

A function is always some kind of action. Therefore, its name should begin with a verb. It is a good idea to fix a set of these verbs and describe their purpose.

// transform[Entity]to[Entity]
const transformResultToOrderedArray = () => {}

// format[Entity]As[Entity]
const formatTimestampAsLocalizedEnString = () => {}

// (generate|gen)[Entity]
const generateRandomTraceId = () => {}
const genRandomTraceId = () => {}

HTTP method functions (return a result of fetch API) should be named with a method that they return:

// <method><Entity>
const getArticles = () => {};
const postArticle = () => {};
const putArticle = () => {};
const patchArticle = () => {};
const deleteArticle = () => {};
// ...

Class private attributes and methods

According to Private Fields we need to use # (hash names) for private methods and attributes.

class PrivateNumber {
    #x;

    constructor(x) {
        this.#x = x;
    }

    get #privateSecretValue() {
        return this.#x + 10;
    }

    get secretValue() {
        return this.#privateSecretValue;
    }
}

Conclusion

After all, it is not so important which style, rules or prefixes we use. They just need to be consistent at least within a project. But we make our (and our colleagues) lives easier when we use at least somehow unified conventions.