Парадигмы программирования - императивная и декларативная

Это серия статей о функциональном программировании:

1. Парадигмы программирования (рассматривается в этой статье)
2. Композиция
3. Функторы
4. Каррирование
5. Чистые функции
6. Функции первого класса

Парадигмы программирования

Парадигма программирования — это стиль или "способ" программирования. Поэтому некоторые языки заставляют нас писать в определенной парадигме. Другие языки оставляют варианты открытыми для программиста, где каждая парадигма следует набору понятий. За всю историю компьютерного программирования инженеры разработали разные языки. Каждый язык основывался на одной или нескольких парадигмах. Эти парадигмы принадлежат к одной из следующих двух основных категорий:

1. Императивная парадигма

В императивных языках программирования поток управления является явным, где программист инструктирует программу, как изменить ее состояние. В императивную парадигму также включается:

• Структурная парадигма
• Объектно-ориентированная парадигма

2. Декларативная парадигма

В декларативной парадигме поток управления является неявным, когда программист указывает программе, что следует делать, не указывая, как это должно быть сделано. В декларативную парадигму также включается:

• Функциональная парадигма
• Логическая парадигма
• Математическая парадигма
• Реактивная парадигма

Большинство языков принадлежат либо к императивной, либо к декларативной парадигме, где каждая парадигма имеет набор понятий, которым необходимо следовать. Рассмотрим подробнее каждую парадигму.

Императивная парадигма

Императивная парадигма немного изменилась из-за структурной парадигмы, но у нее все еще есть проблемы:

• Указание программе, как что-то делать (поток управления является явным)
• Общее состояние

Чтобы понять эти проблемы рассмотрим примеры.

Проблема 1: Указание программе, как что-то делать (поток управления является явным)

Кейс: представьте себе 1000 сотрудников с руководителем, который ведет их по проекту. Руководитель начинает рассказывать 1000 сотрудников, как делать вещи одну за другой. Как вы думаете, насколько это будет плохо? Я почти уверен, что вы видите, что этот стиль управления на микроуровне имеет большие риски, ловушки и даже не сработает. Решение: Сгруппировать людей по зонам ответственности и делегировать в каждую группу руководителя группы. Руководитель каждой группы должен знать, как делать что-то для достижении цели. Это значительно уменьшит сложность, узкие места и станет намного проще в управлении. В этой аналогии

• Руководитель = Программист
• Руководители групп = Функции более высокого уровня
• Сотрудники в каждой группе = Строки кода

Вывод: когда мы применяем организационную структуру более высокого порядка на программном уровне, наша жизнь становится проще.

Проблема 2: Общее состояние

Кейс: Представьте отца, у которого двое детей. У них есть общий банковский счет. Каждый месяц отец кладет на этот счет 1000 долларов. Оба ребенка не знают, что учетная запись используется совместно. Таким образом, они оба думают, что у каждого есть 1000 долларов, которые он может потратить на себя. В конце месяца оказывается, что на этом счету осталось -1000 долларов. Решение: У каждого ребенка должна быть отдельная учетная запись и указанная ежемесячная сумма. В этой аналогии:

• Дети = Функции
• Общий банковский счет = общее состояние

Вывод: Когда ваши функции имеют одно и то же состояние, они используют его неосознанно. Это испортит состояние вашей программы даже с двумя функциями. Так что всегда лучше, чтобы каждая функция имела собственное независимое состояние для использования.

Пример императивной парадигмы

Давайте посмотрим, как функция для суммирования может быть реализована в императивной парадигме.

const sum = (list) => {
  let result = 0
  for (let i = 0; i < list.length; i++) {
    result += list[i]
  }
  return result
}

Почему этот код считается императивным?

1. Указание программе, как что-то делать (поток управления является явным): мы явно сообщаем циклу for, как работать. Также мы обращаемся к каждому элементу в массиве явно.
2. Совместное состояние: результирующая переменная является общим состоянием, изменяющимся на каждой итерации (с общим состоянием в более крупных решениях будет гораздо сложнее справиться).

Декларативная парадигма

Декларативная парадигма — это когда программист указывает программе, что должно быть сделано, не указывая, как. В декларативной парадигме мы пишем функции, которые:

• Описывают, что должна выполнять программа, а не как (неявный поток управления).
• Не производят побочных эффектов (о которых мы поговорим позже).

Пример декларативной парадигмы

Мы увидели, как функция sum может быть реализована в императивной парадигме. Давайте посмотрим, как ее можно реализовать декларативно.

const add = (a, b) => a + b
const sum = (list) => list.reduce(add)

Похоже на магию? Но почему это считается декларативным?

• Описано, что программа должна выполнять, а не как (неявный поток управления): нет явного итератора, нет явного указания циклу, как работать или как получить доступ к элементам. Это было достигнуто с помощью метода reduce.
• Не производит побочных эффектов: общее состояние — это форма побочных эффектов, которая была полностью устранена с помощью метода reduce и функции add.

Еще одно сравнение

Что, если мы хотим суммировать только четные числа? Разберем эту задачу на примерах в разных парадигмах.

Императивная реализация

const evenSum = (list) => {
  let result = 0
  for (let i = 0; i < list.length; i++){
    if(list[i] % 2 === 0) {
      result += list[i]
    }
  }
  return result
}

Декларативная реализация

const evenSum = (list) => {    
  const isEven = (n) => n % 2
  const add = (a, b) => a + b
  return list.filter(isEven).reduce(add)
}

Как видим, если мы хотим сравнить обе парадигмы (императивную и декларативную), то декларативная парадигма (в нашем случае Функциональная парадигма) больше похожа на шестеренки. Вы разрабатываете свои шестеренки как отдельные единицы, затем добавляете их туда, где они вам нужны. Но в императивной парадигме это больше похоже на тесто. Почти все смешано и слито в один и тот же кусок код. В целом декларативная парадигма — это:

• Предсказуемость
• Тестируемость
• Многоразовость
• Настраиваемость
• Кэшируемость
• Поддерживаемость
• Компонуемость

Некоторые из этих моментов не обязательно имеют смысл в контексте примера с функцией sum, но будут иметь смысл в следующих статьях о функциональном программировании.

Эволюция парадигм

Итак, у нас есть 2 основные парадигмы: императивная и декларативная, каждая из которых имеет подпарадигмы. Теперь поговорим подробнее о структурной, объектно-ориентированной и функциональной парадигмах. с эволюционной точки зрения. Каждая парадигма ограничивала способ программирования, вводя что-то новое.

• Структурная парадигма: ограниченное использование goto и «потока передачи управления» за счет введения в наш код такой структуры, как if/else/then/loop и других. Другими словами, он ограничивает поток передачи управления.
• Объектно-ориентированная парадигма: ограничение полиморфизма с использованием указателей на функции за счет введения полиморфизма с использованием наследования.
• Функциональная парадигма: ограничения общего состояния и побочные эффекты за счет введения иммутабельности.

Имейте в виду, что каждая парадигма может использовать одну или несколько концепций других парадигм (например, как объектно-ориентированная, так и функциональная парадигмы используют концепции структурной парадигмы).

Итоги

В реальной жизни у нас разные парадигмы с разными стилями, которые требуют разного уровня мастерства. Практика большего количества парадигм даст вам больше возможностей. У объектно-ориентированной парадигмы есть свои особенности, у функционального программирования - свои. Чем сильнее вы становитесь в этих парадигмах, тем мощнее будут ваши решения.

Не все типы состояния равнозначны в React. Перед тем, как использовать любую библиотеку, важно понять, какой тип состояния необходим для вашего приложения. Ваш фреймворк может уже предоставлять все, что вам нужно, особенно с React 19. Возможно, вам вообще не понадобится библиотека управления состоянием.

Состояние в адресной строке

Самый простой вид состояния — это состояние в URL. Хранилище ключей и значений как часть URL: /search?query=abc. Состояние в URL идеально подходит для простых значений и хранения обновлений как части истории браузера. Примером может служить переключение между списком и элементом с помощью radio button.

export default function Page() {
  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
      />
      <input
        name="view"
        type="radio"
        value="tiles"
      />
    </div>
  );
}

Сохранение фильтров и выбора в истории браузера позволяет пользователю отменить выбор, нажав кнопку «Назад» . onChange помещает ту же страницу с добавленными параметрами поиска в URL:

"use client";

import { usePathname, useRouter } from "next/navigation";

export default function Page() {
  const pathname = usePathname();
  const router = useRouter();

  // Нет нужды хранить значение в `useState`, а хранится в URL
  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const urlSearchParams = new URLSearchParams();
    urlSearchParams.set("view", event.target.value);
    router.push(`${pathname}?${urlSearchParams.toString()}`, { scroll: false });
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        onChange={onChange}
      />
    </div>
  );
}

При выборе опции URL-адрес обновляется с использованием ключа view (поле name инпута) и значения list или tiles. NextJS предоставляет хук useSearchParams для чтения параметров поиска из URL. Мы извлекаем ключ view и устанавливаем defaultChecked параметр каждого инпута:

"use client";

import { usePathname, useRouter, useSearchParams } from "next/navigation";

export default function Page() {
  const pathname = usePathname();
  const searchParams = useSearchParams(); // здесь
  const view = searchParams.get("view") ?? undefined; // здесь

  const router = useRouter();

  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const urlSearchParams = new URLSearchParams(searchParams);
    urlSearchParams.set("view", event.target.value);
    router.push(`${pathname}?${urlSearchParams.toString()}`, { scroll: false });
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        // Применим значение по умолчанию из `URLSearchParams`
        defaultChecked={view === "list"}
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        // Применим значение по умолчанию из `URLSearchParams`
        defaultChecked={view === "tiles"}
        onChange={onChange}
      />
    </div>
  );
}

Значение будет выбрано по умолчанию даже при перезагрузке страницы. Другой вариант с NextJS читать параметры поиска - читать их внутри серверных компонентов. Каждая страница имеет доступ к props, содержащим searchParams как Promise:

interface Props {
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
}

export default async function Page(props: Props) {
  const searchParams = await props.searchParams; // здесь
  const view = searchParams.view ?? undefined; // здесь
  /// ...
}

Такие хуки, такие как useRouter или usePathname не доступны в серверных компонентов. Способом сохранения пропсов searchParams, и хуков в одном компоненте является новая функция use:

"use client"; // Можно не создавать отдельный компонент для клиентского кода

import { usePathname, useRouter } from "next/navigation";
import { use } from "react";

interface Props {
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
}

// Не нужно создавать async серверный компонент
export default function Page(props: Props) {
  // Доступ к асинхронным `searchParams` с помощью новой функции `use` (React 19)
  const searchParams = use(props.searchParams);
  const view = searchParams.view ?? undefined;

  const pathname = usePathname();
  const router = useRouter();

  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const urlSearchParams = new URLSearchParams();
    urlSearchParams.set("view", event.target.value);
    router.push(`${pathname}?${urlSearchParams.toString()}`, { scroll: false });
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        defaultChecked={view === "list"}
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        defaultChecked={view === "tiles"}
        onChange={onChange}
      />
    </div>
  );
}

Во всех примерах обратите внимание, что инпут - неуправляемый компонент. Поскольку состояние хранится в URL, то нет необходимости в useState. Вот как реализовать то же самое с useState (управляемый компонент):

"use client";

import { useState } from "react";

export default function Page() {
  const [view, setView] = useState<string | undefined>(undefined);

  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    setView(event.target.value);
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        // `checked` вместо `defaultChecked` для управляемого компонента
        checked={view === "list"}
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        // `checked` вместо `defaultChecked` для управляемого компонента
        checked={view === "tiles"}
        onChange={onChange}
      />
    </div>
  );
}

Состояние URL настолько распространено, что большинство React фреймворков включают специальную поддержку параметров поиска.

Состояние на стороне сервера

Состояние сервера относится к данным, которые управляются сервером, а не являются локальными для клиента. Обычно вы читаете данные при загрузке страницы. Данные не обновляются на клиенте, а перезагружаются после обновления (POST, PUT или DELETE). Поскольку эти данные считываются только один раз при загрузке страницы, вам не нужно делать запрос на чтение на клиенте. Вместо этого вы обычно предварительно загружаете данные и HTML на сервере. Вот для чего нужны серверные компоненты:

interface Post {
  title: string;
  body: string;
}

export default async function Page() {
  // Сервер загружает данные прямо в серверный компонент (React 19)
  const post = await fetch("https://jsonplaceholder.typicode.com/posts/1").then(
    (response) => response.json() as Promise<Post>
  );

  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.body}</p>
    </div>
  );
}

Серверный компонент помечен как async и fetch выполняется непосредственно внутри функции компонента. Клиент получает окончательный макет без необходимости делать еще один запрос к серверу. После обновления сервера (POST/ PUT/DELETE) вам необходимо вручную перезагрузить страницу, чтобы отобразить новые данные. Если вместо этого вы предпочитаете повторно проверять данные на клиенте, используйте такие решения, как TanStack Query. useQuery делает асинхронный запрос, когда страница загружается (на клиенте) и сохраняет ответ в кэше. Периодически делается новый запрос для повторной проверки данных:

"use client"; // Клиентский компонент

import { useQuery } from "@tanstack/react-query";

interface Post {
  title: string;
  body: string;
}

export default function Page() {
  const result = useQuery({
    queryKey: ["post"],
    queryFn: () =>
      fetch("https://jsonplaceholder.typicode.com/posts/1").then(
        (response) => response.json() as Promise<Post>
      ),
  });

  if (result.isPending) {
    return <div>Loading...</div>;
  } else if (result.isError) {
    return <div>Error: {result.error.message}</div>;
  }

  return (
    <div>
      <h2>{result.data.title}</h2>
      <p>{result.data.body}</p>
    </div>
  );
}

Вам необходимо проверить оба isPending и isError, чтобы убедиться, что data определена. Поскольку запрос выполняется на клиенте, при первой загрузке пользователь увидит состояние загрузки (isPending). Этого не происходит с серверными компонентами, поскольку страница загружена и готова к отправке клиенту.

Состояние внутри формы

Форма хранит данные ввода с целью отправки form запроса. React 19 представляет useActionState хук специально для запросов форм. useActionState сохраняет состояние запроса (обычно данные ответа) и заботится о состоянии ожидания.

export default function Page() {
  const [state, action, isPending] = useActionState(api, null);
  return (
    <form action={action}>
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={isPending}>
        Submit
      </button>
    </form>
  );
}

api реализует async запрос (или синхронный) путем извлечения значений из FormData (на основе name инпутов).

"use client";

import { useActionState } from "react";

type State = null; // основано на типе ответа

const api = async (
  previousState: State,
  formData: FormData
): Promise<State> => {
  const email = formData.get("email");
  const password = formData.get("password");
  console.log(email, password);
  await new Promise((resolve) => setTimeout(resolve, 2000));
  return null;
};

export default function Page() {
  const [state, action, isPending] = useActionState(api, null);
  return (
    <form action={action}>
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={isPending}>
        Submit
      </button>
    </form>
  );
}

Все инпуты неконтролируемые, их значения извлекаются из FormData. Нет необходимости в нескольких useState. При такой реализации запрос отправляется внутри клиента. Поэтому console.log будет выведен в консоль браузера.

Серверные действия

Если вы хотите выполнить действие внутри сервера, вы можете использовать серверные действия. Реализация та же самая, но api функция находится в отдельном файле, помеченном как "use server":

"use server";

type State = null;

export const api = async (
  previousState: State,
  formData: FormData
): Promise<State> => {
  const email = formData.get("email");
  const password = formData.get("password");
  console.log(email, password);
  await new Promise((resolve) => setTimeout(resolve, 2000));
  return null;
};

Компонент ссылается на api так же, как и раньше внутри useActionState:

"use client";

import { useActionState } from "react";
import { api } from "./api";

export default function Page() {
  const [state, action, isPending] = useActionState(api, null);
  return (
    <form action={action}>
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={isPending}>
        Submit
      </button>
    </form>
  );
}

При такой реализации api будет выполнено на сервере. Поэтому console.log печатает в логах сервера (в браузере ничего не печатается). При отправке формы на сервер отправляется POST-запрос. Параметры функции и метаданные отправляются как часть RPC-запроса для выполнения API на сервере. При отправке формы на сервер отправляется POST-запрос. Параметры функции и метаданные отправляются как часть RPC-запроса для выполнения API на сервере.

Мутации с TanStack Query

Другой вариант — использование мутаций из TanStack Query с useMutation хуком. useMutation принимает функцию для выполнения, как и useActionState. Невозможно напрямую использовать action формы. Вместо этого можно выполнить мутацию onSubmit: Вам необходимо вручную вызвать preventDefault, чтобы избежать перезагрузки страницы.

export default function Page() {
  const mutation = useMutation({
    mutationFn: api,
  });

  return (
    <form
      onSubmit={(event) => {
        event.preventDefault(); // здесь
        mutation.mutate(new FormData(event.currentTarget));
      }}
    >
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={mutation.isPending}>
        Submit
      </button>
    </form>
  );
}

api то же самое, что и раньше. Он получает FormData и выполняет функцию на клиенте. Даже в этом случае состояние неконтролируемо и извлекается как FormData:

"use client";

import { useMutation } from "@tanstack/react-query";

const api = async (formData: FormData) => {
  const email = formData.get("email");
  const password = formData.get("password");
  console.log(email, password);
  await new Promise((resolve) => setTimeout(resolve, 2000));
};

export default function Page() {
  const mutation = useMutation({
    mutationFn: api,
  });

  return (
    <form
      onSubmit={(event) => {
        event.preventDefault();
        mutation.mutate(new FormData(event.currentTarget));
      }}
    >
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={mutation.isPending}>
        Submit
      </button>
    </form>
  );
}

Состояние на стороне клиента

До сих пор мы не использовали ни useState, ни useReducer, ни какой-либо другой хук или библиотеку, которая хранит и вручную обновляет данные на клиенте. Во всех вышеперечисленных случаях это не нужно:

• Состояние URL для пар «ключ-значение» синхронизировано с URL (история браузера)
• Состояние сервера для чтения данных при загрузке страницы
• Состояние формы для отправки form запросов

Состояние клиента необходимо только для управления сложными взаимодействиями: множественными переменными, включая производные значения с множественными состояниями и шагами. Для этих сложных вариантов использования вам нужен способ контролировать мутации и избегать ненужных повторных рендеров. Тогда следует обратиться к библиотекам вроде XState, Zustand, Redux. В большинстве случаев вам может даже не понадобиться внешняя библиотека. Хуки вроде useReducer, useContext, и useState могут быть достаточны для большинства локальных и простых случаев использования.

Функция перехода состояния

Библиотека управления состоянием в основном отвечает за:

• Хранение и предоставление доступа к состоянию
• Обновление состояния (избегая чрезмерного повторного рендеринга)

Распространенный шаблон, ставший популярным благодаря Redux, состоит в функции перехода состояния. Это функция, которая принимает событие и текущее состояние и возвращает следующее состояние. Самая простая реализация этого шаблона - это useReducer:

"use client";

import { useReducer } from "react";

interface State {
  firstName: string;
  lastName: string;
}

type Event =
  | { type: "firstName.update"; value: string }
  | { type: "lastName.update"; value: string };

const reducer = (state: State, event: Event): State => {
  switch (event.type) {
    case "firstName.update":
      return { ...state, firstName: event.value };
    case "lastName.update":
      return { ...state, lastName: event.value };
  }
};

export default function Page() {
  const [state, dispatch] = useReducer(reducer, {
    firstName: "",
    lastName: "",
  });
  const fullName = `${state.firstName} ${state.lastName}`; // Производное состояние
  return (
    <form>
      <input
        type="text"
        name="firstName"
        value={state.firstName}
        onChange={(event) =>
          dispatch({ type: "firstName.update", value: event.target.value })
        }
      />
      <input
        type="text"
        name="lastName"
        value={state.lastName}
        onChange={(event) =>
          dispatch({ type: "lastName.update", value: event.target.value })
        }
      />

      <p>{fullName}</p>
      <button type="submit">Submit</button>
    </form>
  );
}

Такие библиотеки, как @xstate/store и Redux, основаны на этом же шаблоне.

Стэйт машины (конечные автоматы)

Для еще более сложных случаев состояния (объекта) и событий недостаточно. Конечные автоматы моделируют различные состояния явно (например, «открыто»/«закрыто»). Обновление состояния использует ту же событийно-управляемую логику функции редьюсера. Главное отличие в том, что определенные действия разрешены только внутри определенных состояний. Конечные машины можно визуализировать в виде диаграммы. Этот дополнительный уровень абстракции предотвращает непреднамеренные действия, когда они не разрешены в состоянии. Он дает больше контроля над состояниями приложения за счет более высокой сложности . Конечный автомат моделирует всю сложность вашего приложения, поэтому его часто считают более сложным для реализации и требующим больше кода. Стандартным решением для конечных автоматов в React является XState:

"use client";

import { useMachine } from "@xstate/react";
import { createMachine } from "xstate";

const machine = createMachine({
  types: {} as {
    events: { type: "OPEN" } | { type: "CLOSE" };
  },
  initial: "closed",
  states: {
    closed: {
      on: { OPEN: "open" },
    },
    open: {
      on: { CLOSE: "closed" },
    },
  },
});

export default function Page() {
  const [snapshot, send] = useMachine(machine);

  if (snapshot.matches("open")) {
    return (
      <div>
        <p>Open</p>
        <button onClick={() => send({ type: "CLOSE" })}>Close</button>
      </div>
    );
  }

  return (
    <div>
      <p>Closed</p>
      <button onClick={() => send({ type: "OPEN" })}>Open</button>
    </div>
  );
}

Диаграммы состояний

Диаграммы состояний расширяют базовую модель конечных автоматов для создания комплексного решения по управлению состоянием. Диаграммы состояний добавляют дополнительные функции, включая иерархию, параллелизм и коммуникацию. XState реализует модель диаграмм состояний (statecharts ). Он также позволяет нескольким statecharts взаимодействовать друг с другом в модели актора. Актор инкапсулирует логику определенной функциональности в вашем приложении. Модель актора позволяет отправлять сообщения между акторами как модель параллельных вычислений.

Библиотеки управления состоянием в React

Ниже представлен обширный список библиотек управления состоянием для более сложных требований состояние на стороне клиента:

• @xstate/store
• zustand
• jotai
• redux
• Redux Toolkit
• MobX
• xstate
• Valtio
• MobX-State-Tree