Практикум JavaScript, React и Node.js

Учебный проект, который есть смысл обсуждать на ревью

Возьмите одну законченную задачу: каталог, поиск по документам или трекер задач. Пользователь должен пройти путь от открытия приложения до полезного результата. Количество экранов вторично: важнее связность поведения и способность объяснить решения.

Что проверить до отправки ссылки

• Состояния. Проверьте загрузку, пустой результат, ошибку, повторную попытку и успешный ответ. По возможности воспроизведите ответ не в том порядке, в котором ушли запросы.
• Доступность. Пройдите основной сценарий клавиатурой, увеличьте масштаб, проверьте подписи полей и видимый фокус. Ошибка должна быть понятна и без красного цвета.
• Данные. Разделите формат ответа сервера и состояние интерфейса. Неверный ответ должен стать контролируемой ошибкой, а не падением всего экрана.
• Проверки. Добавьте тест на важную границу: устаревший ответ, неверный тип данных, отмену или недоступный API. Не ограничивайтесь тестом на само наличие кнопки.
• Документация. Запишите команды запуска, ограничения и два осмысленных решения. Другой разработчик должен воспроизвести пример без личной переписки.

Для frontend начните с отмены запросов в React, для backend - с контракта ошибок API. Эти разборы помогут сформулировать проверяемый результат.

Один проект вместо бесконечного списка туториалов

Постройте небольшой поиск по каталогу. Сначала сделайте интерфейс с локальными данными. Затем подключите API, добавьте отмену и валидацию ответа. После этого проверьте доступность формы и замерьте скорость на мобильном устройстве.

Шаги проекта

1. Семантический HTML и адаптивная компоновка без горизонтального скролла.
2. Три состояния запроса: загрузка, ошибка и результат. Отдельно проверьте пустой список.
3. Типизация на границе API: unknown, runtime-проверка и понятный контракт.
4. Регрессионный тест на быстрый повторный запрос и неправильный ответ.
5. Клавиатура, подписи полей, фокус ошибки и устойчивость при увеличении текста.
6. Отчёт о производительности: что измерено, что изменено и какие ограничения остались.

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

Как отличить готовый интерфейс от красивого макета

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

Проверьте длинный текст на узком экране

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

Проверьте работу интерфейса целиком

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

Что приложить к frontend-ревью

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

Для самостоятельной проверки используйте практикум. Если нужен разбор с ментором, посмотрите frontend-программу и формат работы.

Как подготовить технический вопрос к разбору

Чем меньше времени уходит на восстановление контекста, тем больше остаётся на само решение. Такой пакет полезен для менторской встречи, code review в команде и вопроса коллеге.

1. Сформулируйте ожидаемое и фактическое поведение. Пример: «При быстром изменении поиска вижу результат предыдущего запроса».
2. Приложите минимальный воспроизводимый пример, команду запуска и версии среды. Удалите реальные токены, адреса клиентов и персональные данные.
3. Опишите, что уже проверили: зависимости эффекта, порядок ответов, запись в консоли, сетевую вкладку. Разделите наблюдение и предположение.
4. Укажите ограничение решения: совместимость, доступность, время ответа или объём данных. Объясните, почему простой вариант не подходит.
5. После разбора добавьте регрессионную проверку и короткую заметку о причине ошибки. Так решение остаётся вашим навыком, а не чужой подсказкой.

Если хочется понять формат работы с ментором, посмотрите как проходит менторство и условия оплаты.