Что такое чистая функция

У чистой функции есть два признака. Первый, одинаковые входные данные дают одинаковый результат. Второй, вызов функции не меняет внешний мир.

Простой пример.

const add = (a, b) => a + b;

Здесь результат зависит только от a и b. Вызов не меняет внешние переменные, DOM, storage, сеть или аргументы. Такую функцию легко проверить тестом и безопасно переиспользовать.

На интервью не обязательно спорить о терминах. Удобнее пройтись по короткому чек-листу. Так вы покажете, что понимаете практическую границу, а не просто выучили определение.

Если на любой вопрос из списка ответ отрицательный, функцию лучше назвать нечистой. Или хотя бы сказать, что у нее есть скрытая зависимость. Это не всегда плохо. Запросы к API, запись аналитики и работа с DOM нужны в приложении. Важно не выдавать такие операции за чистое вычисление.

Побочный эффект это наблюдаемое изменение вне результата функции. Во frontend чаще всего встречаются такие случаи.

• изменение глобальной переменной или модуля;
• мутация объекта или массива, который пришел аргументом;
• запрос к API;
• запись в localStorage или sessionStorage;
• изменение DOM;
• запуск таймера, подписки или аналитического события;
• чтение времени через Date.now() или случайности через Math.random(), если это влияет на результат.

Главное последствие, поведение функции становится труднее предсказать. Тестам нужны моки. Повторный вызов может что-то сломать. Оптимизации вроде мемоизации становятся опасными.

Плохой пример для списка задач.

function addTodo(todos, text) {
  todos.push({ id: Date.now(), text });
  return todos;
}

Здесь сразу две проблемы. Функция мутирует входной массив и сама создает id через текущее время. В React это может сломать обновление по ссылке. В тестах результат будет зависеть от момента запуска.

Более безопасная граница выглядит так.

function addTodo(todos, todo) {
  return [...todos, todo];
}

const todo = { id: Date.now(), text: "Read docs" };
const nextTodos = addTodo(todos, todo);

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

Запрос к API не может быть частью чистой функции. Он зависит от сети, сервера, авторизации и времени ответа. Если спрятать запрос в обычное вычисление или в рендер, компонент может отправлять лишние запросы. Еще он может получить состояние не от того ответа.

Плохой пример.

function UserProfile({ id }) {
  const [user, setUser] = React.useState(null);

  fetch(`/api/users/${id}`)
    .then((response) => response.json())
    .then(setUser);

  return user ? <div>{user.name}</div> : <div>Loading...</div>;
}

Что здесь сломается. Запрос запускается при каждом рендере. Старый ответ может перезаписать данные для нового id. Ошибка не попадет в UI. При размонтировании останется незавершенный запрос. Безопаснее отделить чистую подготовку URL от побочного эффекта и явно обработать loading, error и отмену.

function getUserUrl(id) {
  return `/api/users/${encodeURIComponent(id)}`;
}

function UserProfile({ id }) {
  const [user, setUser] = React.useState(null);
  const [loading, setLoading] = React.useState(false);
  const [error, setError] = React.useState(null);

  React.useEffect(() => {
    const controller = new AbortController();

    setLoading(true);
    setError(null);

    fetch(getUserUrl(id), { signal: controller.signal })
      .then((response) => {
        if (!response.ok) throw new Error("Request failed");
        return response.json();
      })
      .then(setUser)
      .catch((err) => {
        if (err.name === "AbortError") return;
        setError(err);
      })
      .finally(() => {
        if (!controller.signal.aborted) setLoading(false);
      });

    return () => controller.abort();
  }, [id]);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Failed to load user</div>;
  if (!user) return <div>No user</div>;

  return <div>{user.name}</div>;
}

Здесь getUserUrl остается чистой функцией. Запрос все еще является побочным эффектом, но он находится в контролируемом месте и не ломает рендер.

React хорошо показывает практическую пользу чистых функций. Рендер компонента должен быть предсказуемым. При тех же props и state он возвращает тот же UI и не меняет внешний мир.

Плохой пример.

function UserCard({ user }) {
  localStorage.setItem("lastUserId", user.id);

  return <div>{user.name}</div>;
}

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

function UserCard({ user }) {
  React.useEffect(() => {
    localStorage.setItem("lastUserId", user.id);
  }, [user.id]);

  return <div>{user.name}</div>;
}

То же правило относится к props. Нельзя менять объект, который пришел в компонент, а потом возвращать JSX. Такая мутация влияет на родителя или соседние компоненты и делает UI непредсказуемым. Если нужна измененная версия данных, создайте новый объект или массив.

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

При этом локальная мутация внутри функции не всегда проблема.

function normalizeNames(users) {
  const result = [];

  for (const user of users) {
    result.push(user.name.trim().toLowerCase());
  }

  return result;
}

Здесь меняется только локальный массив result, который создан внутри функции. Снаружи этого изменения не видно. Входной users не мутируется. Поэтому с точки зрения вызывающего кода функция может оставаться чистой.

Хороший ответ на интервью может звучать так.

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

После такого ответа полезно сразу привести пример. Не ограничивайтесь функцией сложения чисел. Лучше показать реальный frontend-сценарий, обновление списка, форматирование данных, расчет derived state или чистый reducer.