Что такое функциональное программирование

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

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

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

Короткий ответ можно построить так:

Функциональное программирование это парадигма, в которой программа описывается через функции и преобразования данных. В идеале функции чистые. Для одинаковых аргументов они возвращают одинаковый результат и не меняют внешний мир. Во frontend это помогает не мутировать state, проще тестировать логику и отделять вычисления от эффектов вроде запросов или работы с DOM.

После этого добавьте практический вывод. Например, если функция форматирует список товаров, она должна вернуть новый список и не менять исходный. А если нужно отправить аналитику или сделать fetch, это уже эффект. Его лучше держать отдельно и явно вызывать в нужном месте.

Чистая функция зависит только от входных аргументов. Она не читает случайное внешнее значение и не меняет ничего снаружи.

const formatPrice = (price, currency) =>
  new Intl.NumberFormat("ru-RU", { style: "currency", currency }).format(price);

Здесь результат определяется аргументами. Функцию можно проверить в тесте, вызвать в любом компоненте и не бояться, что она изменит состояние приложения.

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

let discount = 0.1;

const getFinalPrice = (price) => {
  analytics.track("price_calculated");
  return price * (1 - discount);
};

Эта функция выглядит как вычисление, но читает внешнюю переменную и отправляет событие аналитики. Если вызвать ее при расчете данных для UI, событие может уйти при каждом рендере. Метрика станет неверной, а изменение скидки снаружи даст неожиданный результат. Безопаснее передать скидку аргументом, а аналитику вызвать отдельно там, где вы контролируете эффект и обработку ошибки.

Функциональный стиль особенно хорошо подходит для трансформации данных. Например, для фильтрации списков, нормализации ответа API, вычисления derived state и валидации формы. В этих местах важно, чтобы функция принимала данные и возвращала результат без скрытой записи куда-то еще.

Но если задача состоит в управлении эффектами, например запросить данные и показать уведомление, полностью чистой она не будет. Тогда полезно отделить чистую часть от нечистой. Одна функция готовит данные, другая отправляет запрос или пишет в UI.

Не прячьте fetch, запись в localStorage или отправку аналитики в функции с названием вроде getVisibleItems. Если такую функцию вызвать из render или selector, можно получить лишние запросы, race condition, неверную аналитику и UI со старыми данными. Безопаснее сделать чистую функцию для расчета данных, а сетевой эффект вынести в контролируемый слой с обработкой loading, error и отменой запроса.

Иммутабельность означает, что вы не меняете уже созданное значение, а создаете новое. Для React это не абстрактная идея, а практическое правило. React, React.memo, зависимости хуков и многие оптимизации часто смотрят на ссылку, а не делают глубокое сравнение всего объекта.

Плохой пример обновления состояния:

setTodos((todos) => {
  todos[0].done = true;
  return todos;
});

Здесь меняется старый массив и возвращается та же ссылка. UI может не обновиться ожидаемым образом. Другие части приложения увидят измененные данные без явного сигнала.

Безопаснее вернуть новое значение:

setTodos((todos) =>
  todos.map((todo, index) =>
    index === 0 ? { ...todo, done: true } : todo
  )
);

Такой код явно показывает, что изменилось. Он не мутирует старые объекты и лучше работает с ререндером, мемоизацией и отладкой.

В JavaScript функции являются значениями. Их можно записывать в переменные, передавать в другие функции и возвращать из функций. Поэтому методы map, filter и reduce часто приводят как примеры функций высшего порядка.

const activeUserNames = users
  .filter((user) => user.active)
  .map((user) => user.name);

Такой код читается как последовательность преобразований. Сначала оставить активных пользователей, потом взять имена. Это удобно, пока каждый шаг простой и не прячет эффекты.

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

Во frontend чаще всего полезны не сложные термины, а несколько привычек:

• выносить форматирование, фильтрацию и валидацию в чистые функции;
• не мутировать данные из props, state и ответа API;
• делать эффекты явными: запросы, таймеры, storage, DOM и аналитику;
• давать функциям понятный вход и выход;
• не усложнять код абстракциями, если команда будет читать его хуже.

Практическая выгода простая. Чистые функции проще тестировать без браузера и моков. Иммутабельные обновления проще отслеживать в React DevTools. Явные эффекты проще отменять, повторять и обрабатывать при ошибках.