Какие изучаешь документации по JavaScript

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

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

Короткий ответ может звучать так:

Для JavaScript я чаще всего использую MDN. Там удобно смотреть синтаксис, Web API, примеры и совместимость. Если вопрос спорный или связан с новой возможностью языка, проверяю ECMAScript specification и статус TC39 proposal. Для React, TypeScript и инструментов смотрю официальные docs нужной версии, release notes и migration guides. Внешние посты и видео воспринимаю как дополнительный материал, но сверяю их с официальными источниками.

MDN стоит назвать первым, если это правда ваш рабочий справочник. Он полезен не только для методов JavaScript. Еще там удобно проверять Web API: fetch, AbortController, IntersectionObserver, structuredClone, события, DOM и browser compatibility.

ECMAScript specification и TC39 proposals лучше подавать точечно. Не нужно говорить, что вы каждый день читаете спецификацию от корки до корки. Сильнее звучит честная формулировка: вы открываете ее, когда нужно понять точное поведение языка, статус новой возможности или причину, почему код работает именно так.

Для библиотек и инструментов называйте официальные docs под конкретную версию: React docs, TypeScript Handbook, Vite, Babel, Webpack, ESLint, Testing Library. Здесь риск особенно практический. Пример для старой версии может компилироваться, но вести к плохому паттерну или ошибке при обновлении.

Хороший ответ объясняет, как документация влияет на код. Например, если вы нашли новый API, недостаточно сказать, что он есть на MDN. Нужно проверить поддержку браузеров, необходимость полифилла, поведение в SSR, ограничения безопасности и влияние на бандл.

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

Плохой ответ:

Я увидел structuredClone в примере и теперь везде заменяю им глубокое копирование.

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

Безопаснее сказать:

Я проверю контракт API, поддержку в целевых браузерах и реальную необходимость глубокой копии. Если данные можно не мутировать или обновить иммутабельно точечно, это часто лучше, чем слепо клонировать большой объект.

Еще один практический пример. Статья показывает fetch внутри useEffect и обновляет состояние после ответа. Если не проверить документацию по AbortController и правила cleanup в React, можно получить race condition: старый запрос перезапишет новые данные, loading зависнет, а ошибка останется без понятного сообщения для пользователя.

Безопаснее сказать так:

Я не копирую сетевой пример целиком. Проверяю, как отменить запрос, что делать при смене параметров, как показать loading, error и empty state, и не обновлять UI результатом устаревшего запроса.

У источника важно смотреть контекст. Для языка и Web API это статус стандарта, browser compatibility, ссылки на спецификацию и дата обновления. Для библиотек это версия, release notes, migration guide и официальные рекомендации команды.

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

Их можно упоминать, но не как главный источник истины. Посты от maintainers, Web.dev, engineering blogs компаний и разборы опытных разработчиков помогают увидеть практические сценарии, производительность, доступность и реальные trade-off.

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

Можно отвечать по такой схеме:

1. Назовите основной справочник: MDN для JavaScript, Web API, примеров и совместимости.
2. Добавьте первоисточник: ECMAScript specification и TC39 для точного поведения и новых возможностей.
3. Назовите docs инструментов: React, TypeScript, сборщики, тестовые библиотеки, линтеры.
4. Объясните проверку актуальности: версия, дата, browser support, release notes, migration guide.
5. Приведите короткий пример из практики, но без выдуманных достижений.

Если у вас нет сильного примера, не придумывайте его. Лучше сказать простую правду: вы регулярно проверяете поддержку API перед использованием, а при миграциях начинаете с официального migration guide.