Что такое сложное вычисление

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

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

Хороший короткий ответ на интервью:

Сложное вычисление это CPU-задача, которая на реальном объеме данных занимает заметное время и может блокировать главный поток. Во frontend я смотрю на размер данных, частоту запуска и влияние на UI. Дальше выбираю решение: уменьшаю объем работы, улучшаю алгоритм, кеширую результат, откладываю или разбиваю расчет, либо выношу его в Web Worker.

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

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

// Плохо: Promise не переносит расчет в отдельный поток.
async function handleSearch(items, query) {
  await Promise.resolve();

  const result = items
    .filter((item) => expensiveMatch(item, query))
    .sort(expensiveCompare);

  setResult(result);
}

Здесь await может поменять момент запуска кода, но сама фильтрация и сортировка все равно выполняются в главном потоке. Если данных много, поле поиска может зависать после каждого ввода.

Безопаснее сначала понять причину: расчет запускается слишком часто, данных слишком много, алгоритм плохо растет или один запуск длится слишком долго. После этого можно добавить debounce, сократить входной набор, применить мемоизацию, виртуализировать список или вынести работу в Worker.

Не стоит отвечать "я всегда использую Web Worker" или "я всегда использую useMemo". Сильнее звучит ответ с критерием выбора. Разные инструменты решают разные проблемы.

Если расчет долгий только потому, что он повторяется без изменения входных данных, помогает кеш или useMemo. Если один запуск занимает сотни миллисекунд и блокирует ввод, мемоизация не спасет этот запуск. Тогда нужны Worker, chunking или изменение алгоритма.

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

function Products({ products, filters }) {
  const visibleProducts = useMemo(() => {
    return filterAndSortProducts(products, filters);
  }, [products, filters]);

  return <ProductList items={visibleProducts} />;
}

Такой код может убрать лишние повторные расчеты. Но если filters создается заново на каждом рендере, зависимость будет новой и кеш не сработает. А если сам расчет занимает слишком много времени при первом запуске, он все равно пройдет в главном потоке.

Для долгой обработки данных можно использовать Worker. В React важно не забыть про жизненный цикл. Иначе Worker останется работать после размонтирования компонента, а старый результат может перезаписать новый UI.

useEffect(() => {
  let cancelled = false;
  const worker = new Worker(new URL("./search-worker.js", import.meta.url), {
    type: "module",
  });

  setStatus("loading");
  worker.postMessage({ items, query });

  worker.onmessage = (event) => {
    if (cancelled) return;
    setResult(event.data);
    setStatus("ready");
  };

  worker.onerror = () => {
    if (cancelled) return;
    setStatus("error");
  };

  return () => {
    cancelled = true;
    worker.terminate();
  };
}, [items, query]);

Это не делает алгоритм магически дешевым, но освобождает главный поток для UI. Минусы тоже есть: данные нужно передавать сообщениями, Worker не имеет прямого доступа к DOM, а для больших объектов сама передача может стоить заметного времени. Без статуса загрузки и ошибки пользователь может видеть старые данные и не понять, идет ли расчет.

На интервью удобно идти от симптома к решению. Сначала скажите, что именно может сломаться: input lag, пропущенные кадры, долгое открытие страницы, зависший обработчик клика. Потом объясните, как проверить гипотезу: профайлер, реальные данные, слабое устройство, частота запуска.

После этого выбирайте самое простое решение, которое убирает причину. Иногда лучший ответ не Worker, а нормальный алгоритм или уменьшение объема данных до того, как они попадут в компонент.

Не всякая долгая операция является сложным вычислением. Ожидание сети может занимать секунды, но CPU в это время не обязательно занят. Однако обработка большого JSON после ответа сервера уже может стать тяжелой CPU-задачей.

Еще важно различать редкий и частый запуск. Разовая сортировка при открытии экрана может быть приемлемой, если UI показывает состояние загрузки. Та же сортировка после каждого символа в поле поиска уже может стать заметной проблемой.

Если хотите усилить ответ, добавьте одну фразу про измерения: "Я бы подтвердил это в Performance panel или React Profiler, потому что без измерений легко оптимизировать не то место".