Middle JavaScript и React

Экспресс-шпаргалка 20/20

1. React сравнивает предыдущее и новое virtual DOM дерево и применяет в real DOM только минимально необходимые изменения.
2. key нужен, чтобы React стабильно идентифицировал элементы между рендерами и корректно обновлял список.
3. В зависимости нужно включать все внешние значения, которые используются внутри effect, чтобы избежать stale данных.
4. Они полезны, когда есть измеримая проблема производительности: дорогие вычисления или лишние ререндеры из-за нестабильных ссылок.
5. Контролируемая форма хранит значение в state, неконтролируемая — в DOM через ref.
6. State поднимают к ближайшему общему родителю, если нескольким компонентам нужны одни и те же данные.
7. При изменении value контекста все подписанные потребители могут перерендериться.
8. Error Boundary ловит ошибки рендера в дочернем дереве React-компонентов и показывает fallback UI.
9. Для code splitting и отложенной загрузки тяжелых частей интерфейса.
10. Нестабильные props (функции/объекты), слишком высокий state, изменения контекста и отсутствие мемоизации в нужных местах.
11. CSR рендерит в браузере, SSR рендерит HTML на сервере на каждый запрос, SSG генерирует HTML заранее на этапе сборки.
12. Hydration mismatch — несоответствие между HTML с сервера и первым рендером клиента.
13. Оба описывают форму данных, но interface проще расширять через declaration merging, а type гибче для union/intersection и утилитарных комбинаций.
14. Generics позволяют писать переиспользуемые функции/типы с сохранением строгой типизации.
15. Это union объектов с общим дискриминатором (например, type), который позволяет TypeScript безопасно сужать тип.
16. Чаще всего Partial, Pick, Omit, Record, Readonly, ReturnType.
17. Promise.all падает на первой ошибке, Promise.allSettled дожидается завершения всех промисов и возвращает статус каждого.
18. AbortController позволяет отменять fetch и другие abortable операции, чтобы не держать лишние запросы и состояния.
19. Это обработка событий на общем родителе вместо подписки на каждый дочерний элемент.
20. Tree shaking удаляет неиспользуемые экспорты из бандла, если код и сборка позволяют это статически определить.

1. Как работает reconciliation в React?

Теги: react, reconciliation, rendering, performance Сложность: Middle

Короткий ответ

React сравнивает предыдущее и новое virtual DOM дерево и применяет в real DOM только минимально необходимые изменения.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

items.map(item => <Row key={item.id} item={item} />);

Углубление (2-3 минуты)

1. Свяжите тему "Как работает reconciliation в React?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните поведение на быстром и медленном устройстве/сети.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Переусложняют мемоизацию там, где нет измеримой проблемы.
2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как будете валидировать эффект на медленных устройствах?
2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Профилирование рендера до/после изменения.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

2. Зачем нужен key в списках?

Теги: react, key, lists, state-preservation Сложность: Middle

Короткий ответ

key нужен, чтобы React стабильно идентифицировал элементы между рендерами и корректно обновлял список.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример

todos.map(todo => <Todo key={todo.id} todo={todo} />);

Углубление (2-3 минуты)

1. Свяжите тему "Зачем нужен key в списках?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
2. Переусложняют мемоизацию там, где нет измеримой проблемы.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как будете валидировать эффект на медленных устройствах?
2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Критический путь рендера и метрики LCP/INP/CLS.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

3. Как правильно работать с зависимостями в useEffect?

Теги: react, useeffect, dependencies, async Сложность: Middle

Короткий ответ

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

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Делаю воспроизводимый сценарий гонки/таймаута, добавляю логи порядка событий и проверяю стабильность в серии прогонов.

Мини-пример

useEffect(() => {
  fetchUser(userId);
}, [userId]);

Углубление (2-3 минуты)

1. Свяжите тему "Как правильно работать с зависимостями в useEffect?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как тема влияет на race conditions, отмену операций и устойчивость состояния.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Игнорируют отмену, таймауты и повторные запросы, из-за чего появляются race conditions.
2. Не учитывают поведение при ошибках внешних сервисов.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Где поставите retry, а где запретите его и почему?
2. Что изменится в поведении при таймауте внешнего сервиса?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Стратегии timeout, retry, cancellation и их ограничения.
2. Метрики latency/error-rate на целевом сценарии.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

4. Когда useMemo и useCallback реально полезны?

Теги: react, usememo, usecallback, optimization Сложность: Middle

Короткий ответ

Они полезны, когда есть измеримая проблема производительности: дорогие вычисления или лишние ререндеры из-за нестабильных ссылок.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример

const filtered = useMemo(() => heavyFilter(items, query), [items, query]);
const onSelect = useCallback(id => setSelected(id), []);

Углубление (2-3 минуты)

1. Свяжите тему "Когда useMemo и useCallback реально полезны?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не проверяют сценарий на медленных устройствах и сетях.
2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
2. Как будете валидировать эффект на медленных устройствах?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Профилирование рендера до/после изменения.
2. Критический путь рендера и метрики LCP/INP/CLS.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

5. Контролируемые и неконтролируемые формы в React?

Теги: react, forms, controlled-uncontrolled, validation Сложность: Middle

Короткий ответ

Контролируемая форма хранит значение в state, неконтролируемая — в DOM через ref.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример

<input value={name} onChange={e => setName(e.target.value)} />

Углубление (2-3 минуты)

1. Свяжите тему "Контролируемые и неконтролируемые формы в React?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Сравните поведение на быстром и медленном устройстве/сети.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
2. Не проверяют сценарий на медленных устройствах и сетях.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Границы SSR/CSR/SSG/ISR (если применимо).
2. Критический путь рендера и метрики LCP/INP/CLS.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

6. Когда поднимать state вверх (lifting state up)?

Теги: react, state-management, lifting-state, architecture Сложность: Middle

Короткий ответ

State поднимают к ближайшему общему родителю, если нескольким компонентам нужны одни и те же данные.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Оформляю решение через ADR, затем проверяю ключевой trade-off на прототипе и эксплуатационных метриках.

Мини-пример

// Parent хранит selectedId и передает вниз в List и Details

Углубление (2-3 минуты)

1. Свяжите тему "Когда поднимать state вверх (lifting state up)?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите, какие решения документируете в ADR и почему.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Смешивают границы модулей и получают высокий coupling.
2. Оптимизируют локально, ухудшая глобальную архитектуру.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Где проходит boundary между модулями в этом кейсе?
2. Какое решение вы зафиксируете в ADR и какие альтернативы отвергнете?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Артефакт ADR или эквивалентный документ решения.
2. Dependency map и границы ownership.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

7. Какие проблемы у Context API по производительности?

Теги: react, context-api, performance, state Сложность: Middle

Короткий ответ

При изменении value контекста все подписанные потребители могут перерендериться.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

const value = useMemo(() => ({ theme, setTheme }), [theme]);
<ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>

Углубление (2-3 минуты)

1. Свяжите тему "Какие проблемы у Context API по производительности?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не проверяют сценарий на медленных устройствах и сетях.
2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как будете валидировать эффект на медленных устройствах?
2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Профилирование рендера до/после изменения.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

8. Что такое Error Boundary и где его ограничения?

Теги: react, error-boundary, resilience, monitoring Сложность: Middle

Короткий ответ

Error Boundary ловит ошибки рендера в дочернем дереве React-компонентов и показывает fallback UI.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

<ErrorBoundary fallback={<ErrorScreen />}>
  <App />
</ErrorBoundary>

Углубление (2-3 минуты)

1. Свяжите тему "Что такое Error Boundary и где его ограничения?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
2. Не проверяют сценарий на медленных устройствах и сетях.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как будете валидировать эффект на медленных устройствах?
2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Критический путь рендера и метрики LCP/INP/CLS.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

9. Когда использовать React.lazy и Suspense?

Теги: react, lazy, suspense, code-splitting Сложность: Middle

Короткий ответ

Для code splitting и отложенной загрузки тяжелых частей интерфейса.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример

const Settings = React.lazy(() => import('./Settings'));

Углубление (2-3 минуты)

1. Свяжите тему "Когда использовать React.lazy и Suspense?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

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

Follow-up вопросы

1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
2. Как будете валидировать эффект на медленных устройствах?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Профилирование рендера до/после изменения.
2. Критический путь рендера и метрики LCP/INP/CLS.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

10. Какие основные причины лишних ререндеров в React?

Теги: react, rerender, profiler, optimization Сложность: Middle

Короткий ответ

Нестабильные props (функции/объекты), слишком высокий state, изменения контекста и отсутствие мемоизации в нужных местах.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

const onClick = () => setOpen(true); // новая ссылка каждый render

Углубление (2-3 минуты)

1. Свяжите тему "Какие основные причины лишних ререндеров в React?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

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

Follow-up вопросы

1. Как будете валидировать эффект на медленных устройствах?
2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Критический путь рендера и метрики LCP/INP/CLS.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

11. Разница между CSR, SSR и SSG?

Теги: frontend, csr-ssr-ssg, rendering-strategy, seo Сложность: Middle

Короткий ответ

CSR рендерит в браузере, SSR рендерит HTML на сервере на каждый запрос, SSG генерирует HTML заранее на этапе сборки.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В production-фичах React/JS: состояние, эффекты, интеграции и оптимизация UI.
2. Главный риск: Растут сложность и техдолг, а скорость разработки падает из-за нестабильного поведения.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

Next.js: static page + dynamic route with server rendering

Углубление (2-3 минуты)

1. Свяжите тему "Разница между CSR, SSR и SSG?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Оптимизируют без baseline-метрик и не понимают реальный эффект.
2. Не проверяют сценарий на медленных устройствах и сетях.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как будете валидировать эффект на медленных устройствах?
2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Критический путь рендера и метрики LCP/INP/CLS.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

12. Что такое hydration mismatch и как его избежать?

Теги: frontend, hydration, ssr, rendering Сложность: Middle

Короткий ответ

Hydration mismatch — несоответствие между HTML с сервера и первым рендером клиента.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример

// Плохо: рендерим Date.now() напрямую в SSR markup

Углубление (2-3 минуты)

1. Свяжите тему "Что такое hydration mismatch и как его избежать?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не проверяют сценарий на медленных устройствах и сетях.
2. Оптимизируют без baseline-метрик и не понимают реальный эффект.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Границы SSR/CSR/SSG/ISR (если применимо).
2. Профилирование рендера до/после изменения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

13. type vs interface в TypeScript?

Теги: typescript, type-vs-interface, api-contracts, styleguide Сложность: Middle

Короткий ответ

Оба описывают форму данных, но interface проще расширять через declaration merging, а type гибче для union/intersection и утилитарных комбинаций.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В типизации контрактов между UI, API и бизнес-логикой, чтобы ловить ошибки до рантайма.
2. Главный риск: Слабые контракты увеличивают runtime-ошибки и ломают интеграции между слоями.
3. Как проверяете решение: Собираю пример с DTO + runtime validation и сверяю, что invalid payload отклоняется предсказуемо.

Мини-пример

interface User { id: string }
type Status = 'idle' | 'loading' | 'done';

Углубление (2-3 минуты)

1. Свяжите тему "type vs interface в TypeScript?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте edge-case, где типы предотвращают регрессию.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не учитывают backward compatibility типов API.
2. Используют any вместо явных контрактов на границах.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какой контрпример сломает слабый типовой контракт?
2. Где здесь compile-time проверка достаточна, а где нужна runtime?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. План миграции типов без breaking changes.
2. Union/narrowing/generics в контексте задачи.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

14. Как использовать generics в TypeScript на практике?

Теги: typescript, generics, api-client, type-safety Сложность: Middle

Короткий ответ

Generics позволяют писать переиспользуемые функции/типы с сохранением строгой типизации.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В типизации контрактов между UI, API и бизнес-логикой, чтобы ловить ошибки до рантайма.
2. Главный риск: Слабые контракты увеличивают runtime-ошибки и ломают интеграции между слоями.
3. Как проверяете решение: Запускаю tsc --noEmit, добавляю edge-case тесты и проверяю совместимость контрактов на границе API.

Мини-пример

function first<T>(arr: T[]): T | undefined {
  return arr[0];
}

Углубление (2-3 минуты)

1. Свяжите тему "Как использовать generics в TypeScript на практике?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Добавьте edge-case, где типы предотвращают регрессию.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не учитывают backward compatibility типов API.
2. Используют any вместо явных контрактов на границах.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какой контрпример сломает слабый типовой контракт?
2. Как будете мигрировать типы без поломки потребителей API?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Union/narrowing/generics в контексте задачи.
2. План миграции типов без breaking changes.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

15. Что такое discriminated unions и зачем они нужны?

Теги: typescript, discriminated-union, state-modeling, reducers Сложность: Middle

Короткий ответ

Это union объектов с общим дискриминатором (например, type), который позволяет TypeScript безопасно сужать тип.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В типизации контрактов между UI, API и бизнес-логикой, чтобы ловить ошибки до рантайма.
2. Главный риск: Слабые контракты увеличивают runtime-ошибки и ломают интеграции между слоями.
3. Как проверяете решение: Собираю пример с DTO + runtime validation и сверяю, что invalid payload отклоняется предсказуемо.

Мини-пример

type State =
  | { type: 'idle' }
  | { type: 'loading' }
  | { type: 'error'; message: string };

Углубление (2-3 минуты)

1. Свяжите тему "Что такое discriminated unions и зачем они нужны?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите границы типов между UI, API и доменной логикой.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не учитывают backward compatibility типов API.
2. Надеются только на TypeScript без runtime-валидации входных данных.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какой контрпример сломает слабый типовой контракт?
2. Как будете мигрировать типы без поломки потребителей API?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Union/narrowing/generics в контексте задачи.
2. План миграции типов без breaking changes.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

16. Какие utility types вы используете чаще всего?

Теги: typescript, utility-types, api, maintainability Сложность: Middle

Короткий ответ

Чаще всего Partial, Pick, Omit, Record, Readonly, ReturnType.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В типизации контрактов между UI, API и бизнес-логикой, чтобы ловить ошибки до рантайма.
2. Главный риск: Слабые контракты увеличивают runtime-ошибки и ломают интеграции между слоями.
3. Как проверяете решение: Собираю пример с DTO + runtime validation и сверяю, что invalid payload отклоняется предсказуемо.

Мини-пример

type UserPreview = Pick<User, 'id' | 'name'>;
type UserPatch = Partial<User>;

Углубление (2-3 минуты)

1. Свяжите тему "Какие utility types вы используете чаще всего?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите границы типов между UI, API и доменной логикой.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не учитывают backward compatibility типов API.
2. Используют any вместо явных контрактов на границах.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какой контрпример сломает слабый типовой контракт?
2. Где здесь compile-time проверка достаточна, а где нужна runtime?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. План миграции типов без breaking changes.
2. Контракты DTO/API и runtime-валидацию.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

17. Promise.all vs Promise.allSettled?

Теги: javascript, promise-all, allsettled, resilience Сложность: Middle

Короткий ответ

Promise.all падает на первой ошибке, Promise.allSettled дожидается завершения всех промисов и возвращает статус каждого.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В production-фичах React/JS: состояние, эффекты, интеграции и оптимизация UI.
2. Главный риск: Растут сложность и техдолг, а скорость разработки падает из-за нестабильного поведения.
3. Как проверяете решение: Делаю воспроизводимый сценарий гонки/таймаута, добавляю логи порядка событий и проверяю стабильность в серии прогонов.

Мини-пример

const results = await Promise.allSettled([p1, p2, p3]);

Углубление (2-3 минуты)

1. Свяжите тему "Promise.all vs Promise.allSettled?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Разберите порядок выполнения шагов при нормальном сценарии и при ошибке/таймауте.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Игнорируют отмену, таймауты и повторные запросы, из-за чего появляются race conditions.
2. Не учитывают поведение при ошибках внешних сервисов.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Что изменится в поведении при таймауте внешнего сервиса?
2. Как исключите race condition при параллельных запросах?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Стратегии timeout, retry, cancellation и их ограничения.
2. Порядок очередей/фаз выполнения и обработку ошибок.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

18. Как работает AbortController и зачем он нужен?

Теги: javascript, abortcontroller, cancellation, requests Сложность: Middle

Короткий ответ

AbortController позволяет отменять fetch и другие abortable операции, чтобы не держать лишние запросы и состояния.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В production-фичах React/JS: состояние, эффекты, интеграции и оптимизация UI.
2. Главный риск: Растут сложность и техдолг, а скорость разработки падает из-за нестабильного поведения.
3. Как проверяете решение: Собираю короткий воспроизводимый пример, прогоняю edge-case и объясняю результат без подсказок.

Мини-пример

const c = new AbortController();
fetch('/api', { signal: c.signal });
c.abort();

Углубление (2-3 минуты)

1. Свяжите тему "Как работает AbortController и зачем он нужен?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Разложите ответ на «механика -> применение -> ограничение», чтобы показать не только теорию, но и практику.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

1. Не проговаривают ограничения и edge-cases.
2. Дают определение, но не объясняют, как это использовать в рабочем коде.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Где граница применимости этого решения?
2. Какой минимальный тест докажет корректность подхода?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Базовые определения темы и 2 контрпримера (где работает и где ломается).
2. Связанный вопрос из Банка вопросов для закрепления.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

19. Что такое делегирование событий и когда оно полезно?

Теги: javascript, event-delegation, dom, performance Сложность: Middle

Короткий ответ

Это обработка событий на общем родителе вместо подписки на каждый дочерний элемент.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Сравниваю flamegraph и пользовательские метрики до/после, затем фиксирую guard-тест от регрессии.

Мини-пример

list.addEventListener('click', e => {
  const btn = e.target.closest('[data-id]');
  if (!btn) return;
});

Углубление (2-3 минуты)

1. Свяжите тему "Что такое делегирование событий и когда оно полезно?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

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

Follow-up вопросы

1. Что выберете: простоту кода или оптимизацию, и по какому критерию?
2. Как будете валидировать эффект на медленных устройствах?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Границы SSR/CSR/SSG/ISR (если применимо).
2. Профилирование рендера до/после изменения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React

20. Что такое tree shaking и от чего он зависит?

Теги: frontend, tree-shaking, bundling, performance Сложность: Middle

Короткий ответ

Tree shaking удаляет неиспользуемые экспорты из бандла, если код и сборка позволяют это статически определить.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

import { usedFn } from './utils.js'; // не импортируем весь namespace без нужды

Куда дальше

1. Вернитесь в модуль: React.
2. Сверьтесь с картой темы: React.
3. Продолжайте по маршруту: Middle трек.
4. Закрепите один ответ на практике в Песочнице.

Углубление (2-3 минуты)

1. Свяжите тему "Что такое tree shaking и от чего он зависит?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Зафиксируйте, какой компромисс вы принимаете и как защитите решение на интервью.

Типичные ошибки

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

Follow-up вопросы

1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
3. Какой минимальный тест или проверка подтвердит, что решение действительно работает?

Что повторить

1. Границы SSR/CSR/SSG/ISR (если применимо).
2. Критический путь рендера и метрики LCP/INP/CLS.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: JavaScript
2. Обучение: React
3. Карта подготовки: React