Вёрстка и основы фронтенд-разработки: HTML, CSS, JavaScript и подготовка к React

HTML: структура страницы, семантика и доступность

Зачем начинать с структуры, семантики и доступности

HTML отвечает за смысл и структуру страницы. CSS оформляет, JavaScript добавляет поведение, но именно HTML задаёт:

какие части страницы являются навигацией, основным содержимым, статьёй, подвалом

какие элементы являются заголовками, списками, ссылками, кнопками, полями ввода

как страницу воспринимают поисковые системы

как страницу читают скринридеры и как по ней перемещаются с клавиатуры

Если базовая структура HTML плохая, то:

CSS становится сложнее (приходится «чинить» разметку стилями)

JavaScript и будущий React-компонентный подход дают меньше пользы (компоненты без семантики хуже переиспользуются)

доступность страдает, а исправлять её позже значительно дороже

В этой статье вы научитесь строить скелет документа, выбирать семантические элементы и закладывать основы доступности.

Что такое HTML-документ

HTML-документ можно представить как:

объявление типа документа (нужно браузеру, чтобы корректно интерпретировать страницу)

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

две логические части: метаданные и контент

!Общая карта того, из каких частей состоит страница и где что находится

Метаданные и контент: что где должно быть

Метаданные (часто называют head) — это информация о странице, а не её видимое содержимое. Там обычно указывают:

кодировку (например, UTF-8)

заголовок страницы (то, что видно во вкладке браузера)

описание страницы для поисковых систем

настройки адаптивности для мобильных устройств

подключения стилей и скриптов (в зависимости от подхода)

Контент (часто называют body) — это то, что пользователь видит и с чем взаимодействует:

заголовки, текст, изображения

ссылки, кнопки, формы

блоки навигации и основное содержимое

Полезная справка:

MDN: HTML

MDN: Основы HTML

Семантика: как выбирать правильные элементы

Семантика — это выбор элементов по смыслу. Идея простая: элемент должен описывать, что это такое, а не как это выглядит.

Семантические «области» страницы

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

header — шапка страницы или раздела

nav — блок навигации

main — главное содержимое страницы (обычно один раз на странице)

footer — подвал страницы или раздела

aside — дополнительное содержимое (сайдбар, примечания, похожие ссылки)

Для контентных единиц:

article — самостоятельная публикация (пост, карточка новости, статья)

section — смысловой раздел внутри страницы или статьи

Когда выбирать article, section и «просто контейнер»

Практическое правило:

используйте article, если блок можно вынести из страницы и он останется понятным сам по себе (например, новость с заголовком и текстом)

используйте section, если это часть большого материала, и для понимания важен контекст

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

Заголовки: основа структуры

Заголовки задают «оглавление» страницы. Они важны и для людей, и для скринридеров.

Ключевые принципы:

на странице обычно есть один главный заголовок h1

уровни заголовков должны идти логично: h2 для крупных разделов, h3 для подразделов

не выбирайте уровень заголовка из-за размера шрифта — это задача CSS

!Как заголовки формируют иерархию и помогают навигации

Справка:

MDN: Заголовки и секционирование

Списки, ссылки и кнопки: важные различия

Списки:

используйте список, когда есть набор однотипных элементов (меню, преимущества, шаги)

Ссылки и кнопки:

ссылка ведёт на другой адрес или место на странице

кнопка запускает действие (отправить форму, открыть модальное окно, переключить фильтр)

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

Справка:

MDN: Ссылки

MDN: Кнопка

Доступность: базовые привычки с первого дня

Доступность (a11y) — это когда интерфейсом могут пользоваться люди с разными возможностями и в разных условиях: со скринридером, без мыши, при плохом зрении, на маленьком экране, с медленным интернетом.

Важно: доступность начинается с правильного HTML, а не с «дополнительных атрибутов».

Справка:

MDN: Введение в доступность

W3C WAI: Обзор WCAG

Язык документа

Указывайте язык документа (например, lang со значением ru). Это помогает:

скринридерам выбрать правильную озвучку

браузерам корректно обрабатывать переносы и проверку орфографии

Текст альтернативы для изображений

Если изображение несёт смысл, ему нужен альтернативный текст через alt.

Практические правила:

если изображение информативное, alt описывает смысл, а не «картинка»

если изображение декоративное, alt делают пустым, чтобы скринридер его пропустил

Справка:

MDN: Изображения в HTML

Подписи полей формы

У каждого поля ввода должна быть понятная подпись, связанная с полем. Подсказка внутри поля (placeholder) не заменяет подпись, потому что:

она исчезает при вводе

её легко не заметить

она хуже читается скринридерами

Справка:

MDN: Формы

Управление с клавиатуры и фокус

Проверяйте страницу без мыши:

можно ли дойти до всех интерактивных элементов клавишей Tab

виден ли фокус (обводка активного элемента)

логичен ли порядок обхода

Это в значительной степени зависит от того, используете ли вы правильные элементы по назначению.

ARIA: когда нужно и когда нет

ARIA-атрибуты (например, aria-label) помогают ассистивным технологиям, но их легко применить неправильно.

Безопасное правило для старта:

сначала используйте нативные элементы по назначению (button, ссылки, поля форм)

ARIA добавляйте только если нативной семантики не хватает

Справка:

MDN: ARIA

Мини-чеклист хорошей HTML-структуры

Перед тем как переходить к CSS, убедитесь, что:

у страницы задан язык документа (lang)

структура крупных зон страницы выражена семантическими элементами (header, nav, main, footer)

заголовки идут по уровням и отражают смысл

ссылки ведут к навигации, кнопки запускают действия

у изображений есть корректный alt по смыслу

у полей формы есть подписи

страница работает с клавиатуры

Инструменты и практика

Валидатор разметки

Проверяйте документ валидатором — он находит ошибки структуры и некоторые проблемы доступности.

W3C: Markup Validation Service

Как эта тема связана с дальнейшим курсом

Дальше в курсе мы будем опираться на эту основу:

в CSS вы будете стилизовать уже правильно размеченную структуру, а не пытаться «компенсировать» неправильные элементы

в JavaScript вы будете добавлять поведение к семантическим элементам (например, управлять меню или формой)

при переходе к React вы будете собирать интерфейс из компонентов, где каждый компонент сохраняет семантику и доступность

CSS: стили, блоки, Flexbox, Grid и адаптивность

Как CSS продолжает правильный HTML

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

Важный принцип курса:

сначала смысл (семантика HTML)

потом оформление (CSS)

потом поведение (JavaScript)

Такой порядок делает код проще: CSS не приходится использовать как «костыль» для плохой разметки, а в React позже будет легче выделять компоненты с понятными стилями.

Справка:

MDN: CSS

MDN: Learn CSS

Как CSS применяется к странице

CSS-правило состоит из селектора и набора деклараций.

Селектор определяет, к чему применить стиль.

Декларации задают свойства (например, color, padding, display).

Чаще всего стили пишут в отдельном файле и подключают к странице (это вы будете делать на практике в проекте). Для разработки важно помнить, что браузер применяет стили по правилам каскада.

Каскад, специфичность и наследование

Каскад

Если на один и тот же элемент влияет несколько правил, браузер выбирает победителя. В упрощённом виде учитываются:

важность (!important почти всегда стоит избегать)

специфичность селектора

порядок в файле (позднее правило при равных условиях выигрывает)

Справка:

MDN: Cascade

Специфичность

Специфичность — это «вес» селектора. Практически полезная шкала для старта:

селектор по тегу (button, header) обычно слабее

селектор по классу (.card, .menu-item) сильнее

селектор по идентификатору (#app) ещё сильнее, но в вёрстке его лучше использовать осторожно

Практические советы:

чаще стилизуйте через классы, так проще переиспользовать блоки

не усложняйте селекторы без необходимости

не «лечите» конфликты !important, сначала попробуйте упростить структуру и понять каскад

Наследование

Некоторые свойства наследуются от родителя к потомкам (например, color, font-family), а многие — нет (например, margin, padding, border).

Полезная привычка:

базовую типографику задавать на уровне body

точечные отличия задавать на уровне конкретных компонентов

Единицы измерения: px, %, rem и зачем они нужны

В CSS много единиц, но для уверенного старта достаточно понимать несколько:

px — фиксированная единица, удобна для тонкой настройки, но не всегда помогает адаптивности

% — часто зависит от размера родителя (удобно для резиновых блоков)

rem — зависит от размера шрифта корневого элемента (обычно удобно для масштабируемой типографики)

vw и vh — проценты от ширины и высоты окна браузера

Практическая стратегия:

размеры шрифта, отступы компонентов часто удобно задавать в rem

ширины контейнеров — в % плюс ограничения через max-width

мелкие «пиксель-перфекты» — оставлять для особых случаев

Справка:

MDN: CSS values and units

Блочная модель (box model): основа верстки

Каждый элемент в потоке страницы можно представить как прямоугольник.

Он состоит из:

content — содержимое (текст, картинка)

padding — внутренние отступы

border — рамка

margin — внешние отступы

!Слои блочной модели: content, padding, border, margin

Ключевой момент, который часто ломает макеты новичкам: по умолчанию свойство width задаёт ширину только области content, без учёта padding и border.

Поэтому в реальных проектах часто включают:

border-box означает: заданная ширина включает content + padding + border, а это делает размеры более предсказуемыми.

Справка:

MDN: Box model

MDN: box-sizing

Нормальный поток, display и базовые типы элементов

Нормальный поток

Если не вмешиваться, элементы располагаются в нормальном потоке:

блочные элементы идут сверху вниз

строчные элементы выстраиваются в строку и переносятся

display: block, inline, inline-block

block занимает всю доступную ширину и переносит следующий элемент на новую строку

inline не разрывает строку и обычно игнорирует вертикальные отступы так, как вы ожидаете от блока

inline-block ведёт себя как строчный, но принимает размеры и отступы как блок

Справка:

MDN: display

Почему важно понимать поток

Большая часть верстки — это управление потоком через:

размеры (width, max-width)

отступы (margin, padding)

режимы раскладки (flex, grid)

Если вы понимаете поток, Flexbox и Grid становятся предсказуемыми инструментами, а не магией.

Позиционирование: когда нужно и когда лучше не надо

Основные варианты position:

static — значение по умолчанию, элемент живёт в потоке

relative — элемент остаётся в потоке, но его можно сместить относительно самого себя

absolute — элемент исключается из потока и позиционируется относительно ближайшего «позиционированного» предка (обычно с position: relative)

fixed — позиционируется относительно окна браузера

sticky — ведёт себя как обычный, пока не дойдёт до заданной границы, затем «прилипает»

Справка:

MDN: position

Практическое правило:

для сеток и раскладок чаще используйте Flexbox или Grid

position оставляйте для точечных задач: бейдж на карточке, закреплённая панель, всплывающая подсказка

Flexbox: раскладка в одном измерении

Flexbox удобен, когда элементы нужно разложить в строку или колонку и управлять:

выравниванием

распределением свободного места

переносом на новую строку

Контейнер и элементы

Flexbox включается на контейнере:

После этого дети контейнера становятся flex-элементами.

Главная и поперечная оси

flex-direction задаёт направление главной оси (row или column)

justify-content выравнивает по главной оси

align-items выравнивает по поперечной оси

!Как оси Flexbox меняются при row и column

Перенос и «резиновость»

Частые настройки:

Как читать flex: 1 1 240px:

первый параметр — как охотно элемент растёт

второй — как охотно сжимается

третий — базовая ширина

Справка:

MDN: Flexbox

MDN: flex

MDN: gap

Grid: раскладка в двух измерениях

Grid удобен, когда вы мыслите строками и колонками одновременно: сетка каталога, карточки, общий макет страницы.

Создание сетки

grid-template-columns задаёт колонки

fr — доля свободного пространства

gap — расстояние между ячейками

Адаптивные колонки без сложных медиазапросов

Один из самых практичных паттернов:

Что здесь происходит:

minmax(220px, 1fr) говорит: колонка не должна быть уже 220px, но может расширяться

auto-fit заполняет строку максимальным количеством колонок, которые помещаются

!Как Grid перестраивает количество колонок по ширине

Справка:

MDN: Grid

MDN: minmax()

MDN: repeat()

Flexbox или Grid

Практическое сравнение:

Flexbox — когда важна линия (ряд или колонка), выравнивание и распределение

Grid — когда важна таблица из строк и колонок, или общий макет

В реальных интерфейсах их часто комбинируют: общий каркас страницы на Grid, а мелкие блоки внутри — на Flexbox.

Адаптивность: чтобы интерфейс работал на телефоне и на десктопе

Адаптивность — это не «сделать поменьше», а обеспечить удобное чтение и управление на разных размерах экрана и с разными способами ввода.

Базовая стратегия: резина + ограничения

Частый подход для контентного контейнера:

Идея:

контейнер занимает почти всю ширину на маленьких экранах (с боковыми отступами)

но не растягивается слишком сильно на больших экранах

Справка:

MDN: min()

Медиазапросы

Медиазапросы позволяют включать стили при определённых условиях, чаще всего по ширине.

Практические советы:

делайте базовую версию для узких экранов, затем улучшайте для широких (подход часто называют mobile-first)

не плодите слишком много точек перелома, лучше используйте резиновую сетку (Flex/Grid) и добавляйте медиазапросы точечно

Справка:

MDN: Media queries

Адаптивная типографика и читабельность

Чтобы текст было удобно читать:

контролируйте ширину строки через max-width у текстовых блоков

используйте достаточный line-height

проверяйте контраст текста и фона

Справка:

MDN: line-height

MDN: color

Практика доступности в CSS

CSS может как улучшить доступность, так и ухудшить.

Полезные привычки:

не убирайте фокус у интерактивных элементов без замены (outline: none почти всегда ошибка)

добавляйте заметные стили фокуса через :focus-visible

делайте состояния :hover и :focus-visible согласованными

Пример безопасного фокуса:

Справка:

MDN: :focus-visible

MDN: outline

Как готовиться к JavaScript и React через CSS

То, что вы делаете в CSS сейчас, напрямую влияет на следующий шаг.

Чтобы позже было проще добавлять JS и переходить к React:

называйте классы по смыслу компонента, а не по внешнему виду

делайте компоненты независимыми: карточка должна хорошо выглядеть в разных контейнерах

избегайте слишком «глубоких» селекторов, которые привязывают стили к конкретной структуре

В JavaScript вы будете переключать состояния (например, открытое меню), а в React — передавать состояния как пропсы. В обоих случаях CSS проще поддерживать, если стили построены вокруг компонентов и их состояний.

Мини-чеклист перед тем, как двигаться дальше

включён предсказуемый box-sizing: border-box

вы понимаете разницу block, inline, inline-block

вы умеете собирать ряд/колонку на Flexbox и сетку на Grid

у макета есть разумная адаптивность (контейнеры, сетки, медиазапросы)

фокус виден, состояния :focus-visible продуманы

Дальше в курсе мы начнём добавлять поведение через JavaScript: обработчики событий, изменение классов, управление состояниями интерфейса. Это даст вам связку семантический HTML + аккуратный CSS + интерактивность — базу для перехода к React.

Практика вёрстки: макет, формы, медиа и UI-компоненты

Зачем нужна практика после HTML и CSS

В прошлых темах вы разобрали:

как строить смысловую структуру страницы и думать о доступности

как управлять внешним видом, раскладкой (Flexbox, Grid) и адаптивностью

Теперь задача — научиться превращать макет в понятный набор UI-компонентов и собрать страницу так, чтобы:

её было удобно расширять

формы были дружелюбны к пользователю и доступны

изображения и медиа корректно работали на разных экранах

стили оставались предсказуемыми, а компоненты — переиспользуемыми

Это напрямую готовит к JavaScript (переключение состояний) и к React (компонентный подход).

Как читать макет и превращать его в компоненты

Шаги перевода макета в разметку

Рабочий процесс, который снижает хаос:

Определите каркас страницы:

- шапка, навигация, основной контент, подвал

Разбейте основной контент на секции по смыслу:

- промо-блок, список преимуществ, тарифы, отзывы, контакты

Найдите повторяющиеся куски и выделите компоненты:

- кнопки, карточки, поля ввода, бейджи, табы

Для каждого компонента определите:

- что является контентом, что является действием - какие бывают состояния (обычное, наведено, в фокусе, отключено, ошибка)

Спроектируйте классы по смыслу компонента, а не по внешнему виду.

!Диаграмма показывает, как из цельного макета выделяются переиспользуемые UI-компоненты

Компонентное мышление до React

React позже потребует, чтобы интерфейс был собран из независимых блоков. Вёрстка уже сейчас может быть такой же по духу.

Полезная модель:

компонент имеет корневой класс (например, card)

внутри есть элементы (например, card__title, card__meta)

состояния задаются модификаторами (например, is-active, is-loading)

Главная идея: стили компонента не должны «ломаться», если вы перенесёте его в другой контейнер.

Слои стилей

Чтобы стили не превращались в «комок», удобно мысленно разделить их на уровни:

базовые правила проекта: box-sizing, типографика, базовые цвета

раскладки страниц: контейнеры, сетки, отступы секций

компоненты: кнопки, карточки, формы

состояния: активное, скрытое, ошибка

Сборка макета: контейнеры, сетки, отступы

Контейнер и ритм

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

Практика:

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

внутри секций задавайте gap, а не «случайные» margin в разных местах

Карточки и списки: когда Flexbox, когда Grid

Flexbox удобен для рядов с выравниванием и переносом

Grid удобен для «табличных» сеток карточек

Пример адаптивной сетки карточек:

Типичная ошибка в учебной вёрстке

Ошибка: строить весь макет через позиционирование.

Правило:

сетки и общий макет делайте через Flexbox или Grid

позиционирование оставляйте для точечных деталей (например, бейдж на карточке)

Формы: поля, подписи, состояния, ошибки

Формы — место, где чаще всего страдает доступность и удобство. Хорошая форма:

понятна без подсказок

управляется с клавиатуры

корректно сообщает об ошибках

имеет заметный фокус

Справка:

MDN: Формы

MDN: Form validation

Структура формы по смыслу

Продумайте заранее:

какие данные обязательны

какой тип ввода нужен (почта, телефон, пароль)

какая подсказка действительно помогает

где показывать ошибки

Практическое правило: подсказка внутри поля не должна быть единственным объяснением. Подпись должна существовать всегда.

Состояния поля

Минимальный набор состояний, который вы должны уметь оформить:

| Состояние | Что видит пользователь | Что важно для доступности | |---|---|---| | Обычное | Нейтральная рамка, понятная подпись | Читабельный текст | | Фокус | Заметная подсветка рамки | Не убирать фокус без замены | | Ошибка | Сообщение об ошибке, красная рамка | Ошибка должна быть текстом, а не только цветом | | Отключено | Ослабленный цвет, запрет ввода | Не делать отключённым то, что нужно заполнить |

Пример CSS для фокуса и ошибок:

Кнопки в формах: действие, а не навигация

Один из частых промахов: использовать «не тот» интерактивный элемент.

Запомните:

переход на другую страницу — это навигация

отправка формы, открытие модального окна, переключение фильтра — это действие

Это важно для поведения с клавиатуры и для ожиданий пользователей.

Подготовка к JavaScript-валидации

Даже если сейчас вы делаете статическую страницу, верстайте так, чтобы в будущем было легко подключить JS:

не «вшивайте» ошибки в стили навсегда

планируйте классы состояний (is-error, is-success)

держите место под текст ошибки, чтобы верстка не прыгала

Минимальный JS-шаблон переключения состояния:

Медиа: изображения, пропорции, адаптивность и качество

Медиа часто ломает макет: изображения растягиваются, «выпадают» из контейнера, выглядят мыльно на ретина-экранах.

Справка:

MDN: Responsive images

MDN: object-fit

MDN: aspect-ratio

Базовая защита от поломок

Правило, которое стоит добавить почти в любой проект:

Что это даёт:

изображение не вылезет шире контейнера

пропорции сохраняются

пропадают неожиданные «щели» из-за строчного поведения

Кадрирование и одинаковые превью

Для карточек часто нужны одинаковые превью, даже если исходные картинки разные.

Подход:

задайте блоку фиксированную пропорцию через aspect-ratio

внутри используйте object-fit: cover, чтобы картинка заполняла область и аккуратно кадрировалась

Подготовка к адаптивным изображениям

Когда вы будете делать реальные проекты, вы столкнётесь с задачей отдавать разные размеры изображений под разные экраны.

Ключевые термины, которые стоит запомнить:

srcset — список вариантов одного изображения в разных размерах

sizes — подсказка браузеру, какой размер будет нужен в макете

picture — выбор источника в зависимости от условий (например, формат или ширина)

Даже если вы пока не используете эти техники в учебном проекте, учитывайте:

изображение должно оставаться резким

вес страницы не должен быть огромным

UI-компоненты: кнопки, навигация, карточки, модальные окна

Компоненты — это кирпичи будущего интерфейса. Делайте их предсказуемыми.

Кнопка как базовый компонент

Кнопка обычно должна иметь состояния:

обычное

наведение

фокус

отключено

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

Карточка

Карточка — отличный тренажёр компонентного подхода:

внутри есть изображение, заголовок, мета-информация, действия

карточка может быть ссылкой или содержать кнопки

карточка часто используется в сетке

Рекомендации:

задавайте карточке внутренние отступы и рамку на корневом классе

используйте gap для расстояний между внутренними блоками

следите, чтобы кликабельные зоны были понятны

Навигация и активный пункт

Даже без JavaScript вам нужно уметь визуально показать активный пункт.

Подход:

базовый стиль пункта

модификатор активного состояния (is-active)

Модальное окно как упражнение на состояния

Модальное окно — компонент, где особенно важно состояние.

Даже если вы пока не реализуете всё поведение, предусмотрите:

оверлей

контейнер окна

класс состояния открытости (is-open)

блокировку прокрутки страницы (обычно добавляется через класс на корневом контейнере)

Пример CSS-структуры состояния:

Справка по ожиданиям доступности модалок:

MDN: Dialog (доступность и особенности)

Мини-чеклист перед переходом к JavaScript

Убедитесь, что в вашем учебном макете:

структура страницы выражена смысловыми областями

сетка карточек адаптируется без «ломания»

у интерактивных элементов виден фокус

форма имеет понятные подписи и места под ошибки

изображения не вылезают из контейнеров и не искажаются

компоненты имеют классы по смыслу и состояния через модификаторы

Следующий шаг курса — JavaScript: события, работа с классами, переключение состояний (меню, модалки, валидация форм). Если ваша вёрстка компонентная и аккуратная, JS добавится без переписывания половины проекта.

JavaScript: основы языка и работа с DOM

Зачем JavaScript после HTML и CSS

В первых темах курса вы научились:

строить семантический HTML-скелет и думать о доступности

оформлять и раскладывать интерфейс с помощью CSS (Flexbox, Grid, адаптивность)

верстать макет как набор UI-компонентов со состояниями (например, is-open, is-error)

JavaScript добавляет третью часть фронтенда: поведение. Именно он отвечает за интерактивность:

открыть и закрыть меню

переключить вкладку или фильтр

показать модальное окно

валидировать форму и вывести ошибки

загрузить данные и отрисовать список

Главная идея, которая связывает JavaScript с предыдущими статьями: хорошая вёрстка и продуманные CSS-состояния позволяют добавлять поведение без переписывания структуры.

Полезные источники:

MDN: Руководство по JavaScript

MDN: Введение в DOM

Как выполняется JavaScript в браузере

Когда браузер загружает страницу, он:

строит DOM-дерево документа

применяет CSS и рассчитывает раскладку

выполняет JavaScript-код

DOM — это объектное представление страницы, с которым JavaScript умеет работать.

!Упрощённое DOM-дерево и место JavaScript

Когда можно обращаться к элементам

Если ваш код ищет элементы на странице, важно, чтобы DOM уже был построен. Два распространённых подхода:

подключать скрипт так, чтобы он выполнялся после построения DOM

ждать событие DOMContentLoaded

Событие DOMContentLoaded означает: HTML разобран, DOM готов, можно безопасно искать элементы.

MDN: DOMContentLoaded

Пример ожидания готовности DOM:

Основы языка: то, что нужно для работы с интерфейсом

Ниже — минимальный фундамент JavaScript, который понадобится для DOM, событий и будущего React.

Переменные: const и let

const — значение нельзя переприсвоить (но объект внутри может изменяться)

let — значение можно переприсваивать

Практическое правило: по умолчанию используйте const, а let — только когда переприсваивание действительно нужно.

Типы данных, которые встречаются постоянно

строки: "Привет"

числа: 42

логические: true и false

null и undefined

объекты

массивы

Очень часто в интерфейсах вы будете работать с:

строками (тексты, значения полей)

массивами (списки карточек, пункты меню)

объектами (состояние компонента, данные формы)

Условия: if и ранний выход

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

Функции: объявление и стрелочные

Функции позволяют упаковать поведение и переиспользовать его.

Массивы: обработка списков

Массив — стандартная структура для коллекций.

Частые методы:

forEach — пройти по всем

map — создать новый массив

filter — отфильтровать

find — найти первый подходящий

Объекты: данные и состояние

Объект удобен, когда данные имеют смысловые поля.

Это напрямую связано с React: компонент часто имеет состояние, похожее на объект.

DOM: поиск элементов и чтение данных

DOM-API предоставляет объект document, через который вы находите элементы и работаете с ними.

Поиск одного элемента: querySelector

querySelector принимает CSS-селектор и возвращает первый найденный элемент или null.

MDN: document.querySelector

Поиск списка: querySelectorAll

querySelectorAll возвращает статическую коллекцию (NodeList), по которой можно пройти циклом.

dataset: данные из data-* атрибутов

dataset — удобный способ хранить небольшие параметры на элементах.

MDN: dataset

Изменение DOM: классы, текст, атрибуты, создание элементов

Главная идея: вёрстка задаёт структуру, CSS — стили и состояния, а JavaScript переключает состояния, меняя классы и атрибуты.

Классы: classList

Обычно вы управляете состоянием через классы вроде is-open, is-active, is-error.

MDN: classList

toggle с вторым аргументом делает поведение предсказуемым: класс точно будет добавлен или удалён.

Текст: textContent вместо небезопасных вставок

Для текста используйте textContent. Это безопаснее и проще.

Атрибуты: например, для доступности

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

Создание элементов: createElement и вставка

Если нужно добавить новый элемент, вы создаёте его через DOM.

Практическая привычка: стилизуйте такие элементы через классы, как и остальную вёрстку.

События: клики, ввод, отправка формы

Интерфейс в браузере строится вокруг событий: клик, ввод, фокус, отправка.

addEventListener: как подписываться на события

MDN: addEventListener

Объект события: event, target и currentTarget

В обработчик приходит объект события.

event.target — реальный элемент, на котором произошло событие

event.currentTarget — элемент, на котором висит обработчик

Это важно, когда вы делаете делегирование событий.

Всплытие событий и делегирование

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

MDN: События, всплытие и захват

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

Пример делегирования для списка кнопок:

Идея: вы добавляете новые элементы в список — а обработчик продолжает работать без дополнительных подписок.

Отмена поведения браузера: preventDefault

Иногда браузер делает действие по умолчанию (например, отправляет форму). Если вы хотите обработать это сами, используйте preventDefault.

MDN: preventDefault

Практические паттерны для интерфейса

Переключение состояния компонента через класс

Это основной мост между CSS и JavaScript: CSS описывает внешний вид состояния, JS включает и выключает состояние.

Пример: открыть и закрыть модальное окно.

!Переключение состояния через класс

Состояния формы: ошибки и подсказки

Из прошлой темы по практике вёрстки у вас уже должны быть:

контейнер поля (например, .field)

место под текст ошибки (например, .field__error)

класс состояния (например, is-error)

JavaScript должен лишь поставить и снять состояние.

Отладка: как быстрее находить ошибки

Консоль и console.log

Минимальный инструмент для начинающего — DevTools браузера:

console.log для проверки значений

вкладка Elements для просмотра DOM

вкладка Sources для точек останова

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

Частые ошибки новичков

искать элементы до готовности DOM

забывать проверять null после querySelector

путать ссылку и кнопку на уровне поведения

управлять стилями напрямую вместо переключения классов

пытаться сделать всю раскладку через JavaScript

Как этот модуль готовит к React

React меняет подход: вы обычно не пишете прямые команды вроде найди элемент и добавь класс. Вместо этого вы описываете:

состояние (например, isOpen)

как выглядит интерфейс при этом состоянии

Но чтобы прийти к React уверенно, нужно понимать базу:

DOM и события, потому что React-компоненты всё равно реагируют на события пользователя

управление состояниями через классы и данные, потому что это тренирует компонентное мышление

разделение ответственности: HTML — структура, CSS — стили, JS — поведение

Если вы научились аккуратно добавлять поведение к вашей вёрстке, переход к React будет выглядеть как следующий логичный шаг, а не как новая вселенная.

Полезные источники для закрепления:

MDN: Работа с DOM

MDN: Введение в события

Подготовка к React: модули, сборка, компоненты и состояние

Зачем этот шаг после HTML, CSS и JavaScript

В прошлых темах вы прошли полный базовый цикл фронтенда:

HTML дал структуру и семантику

CSS дал внешний вид, сетки и адаптивность

JavaScript дал поведение через события и работу с DOM

React не отменяет эти знания — он меняет способ сборки интерфейса.

В «ванильном» JavaScript вы часто действуете так:

найти узел в DOM

повесить обработчик

добавить или убрать класс, изменить текст

В React вы чаще мыслите так:

есть состояние (данные)

UI — это функция от состояния

при изменении состояния React сам обновляет то, что нужно

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

Модули в JavaScript: как структурировать код

Что такое модуль

Модуль — это файл, который явно описывает:

что он отдаёт наружу (экспорт)

что он берёт из других файлов (импорт)

Это делает код:

переиспользуемым

тестируемым

читаемым

Справка:

MDN: JavaScript modules

Экспорт и импорт

Есть два основных стиля экспорта.

Именованный экспорт:

Импорт именованных сущностей:

Экспорт по умолчанию:

Импорт по умолчанию:

Практическое правило:

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

экспорт по умолчанию удобен, когда файл отдаёт «главную сущность» (например, один компонент)

Почему модули связаны с React напрямую

React-приложение обычно состоит из множества файлов:

компоненты

стили

утилиты

запросы к API

Без модулей такой проект быстро превращается в монолитный скрипт, который сложно поддерживать.

Зачем нужна сборка: почему одного браузера недостаточно

Проблема «голого» запуска файлов

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

Но в приложении уровня React почти сразу появляются задачи:

подключить десятки модулей и собрать их в оптимальный пакет

быстро обновлять страницу при изменениях в коде

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

подключать CSS как часть системы компонентов

оптимизировать итоговый результат для публикации

Эти задачи решает сборка.

!Общая картина, как исходный код превращается в готовую сборку

Из чего состоит типичный инструментальный набор

Обычно вы встречаете такой набор понятий:

Node.js как среда, в которой запускаются инструменты

npm как менеджер пакетов

dev server для разработки

bundler для сборки модулей

линтер и форматтер для качества кода

Справка:

Node.js: официальный сайт

npm: документация

Vite как современный старт для React

Сегодня один из самых удобных способов начать React-проект для обучения — Vite.

Справка:

Vite: официальный сайт

React: документация

Типичный старт (пример команд):

Что вы получаете:

проект со структурой папок

dev server

сборку для продакшена

корректную работу модулей

package.json: что важно понимать

package.json — это «паспорт» проекта. В нём обычно есть:

зависимости

команды запуска

Пример ключевой идеи команд:

Смысл команд:

dev запускает режим разработки

build собирает оптимизированный результат

preview позволяет локально посмотреть то, что получится после сборки

Компоненты: переносим опыт из вёрстки в React

Компонентное мышление, которое вы уже тренировали

В теме про практику вёрстки вы учились выделять UI-компоненты:

кнопка

карточка

поле ввода

модальное окно

React просто делает этот подход «официальным» и удобным.

Компонент в React можно понимать как:

независимый кусок интерфейса

со своими входными данными

со своими состояниями

Публичный контракт компонента

У компонента обычно есть:

props — входные данные от родителя

state — внутренние данные компонента

Важная идея:

props приходят снаружи и не должны изменяться самим компонентом

state живёт внутри и меняется через механизм React

!Визуальная модель, как данные и события обычно движутся в React

Как связать это с вашим текущим опытом DOM

В «ванильном» подходе вы делали так:

пользователь кликает

обработчик добавляет класс is-open

В React вы думаете так:

есть переменная состояния isOpen

при клике меняем isOpen

отображение само подстраивается под isOpen

То есть вы перестаёте «командовать DOM вручную» и начинаете описывать результат.

Состояние: как интерфейс становится управляемым

Что такое состояние в UI

Состояние — это данные, которые могут измениться и должны изменить интерфейс.

Примеры состояния:

открыта ли модалка

выбранная вкладка

текст в поле ввода

список элементов

статус загрузки

В React локальное состояние часто хранится через хук useState.

Справка:

React: useState

Концептуальный пример (без JSX, чтобы сосредоточиться на идее):

Что здесь важно:

count — текущее значение состояния

setCount — единственный правильный способ изменить count

вариант setCount((prev) => prev + 1) полезен, когда новое значение зависит от предыдущего

Почему нельзя менять состояние напрямую

В React нельзя делать «как с обычной переменной»:

изменение должно быть заметно React

React должен понимать, когда пересчитать UI

Поэтому вы меняете состояние только через setter-функцию (например, setCount).

Два ключевых принципа React-состояния

состояние должно быть минимальным, но достаточным

источник правды должен быть один

«Один источник правды» означает: если значение важно для нескольких частей UI, оно должно храниться в одном месте, а остальные получают его через props.

Поднятие состояния вверх

Если два компонента должны разделять данные, обычно делают так:

состояние живёт в ближайшем общем родителе

вниз передаются значения и колбэки

Это называют lifting state up.

Справка:

React: Sharing State Between Components

Управляемые поля форм

Формы — место, где React отлично показывает пользу состояния.

Вместо того чтобы читать значение из DOM в момент отправки, вы храните значение в состоянии и делаете поле управляемым.

Справка:

React: Adding Interactivity

Основная идея:

значение поля берётся из состояния

при вводе вызывается обработчик, который обновляет состояние

Это особенно полезно для:

мгновенной валидации

подсказок и ошибок

блокировки кнопки отправки

Эффекты: когда нужно синхронизироваться с внешним миром

Есть действия, которые не являются «чистой отрисовкой»:

запросы к API

работа с таймерами

подписки

ручная синхронизация с браузерными API

Для этого используется useEffect.

Справка:

React: useEffect

Важная мысль для новичка:

состояние отвечает за данные UI

эффект отвечает за побочные действия

Практическая связь с будущим React-проектом

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

Как ваши текущие лучшие практики «переезжают» в React

семантический HTML остаётся важным, потому что компоненты всё равно рендерят разметку

CSS-компонентность становится ещё важнее, потому что каждый React-компонент обычно имеет свои стили и состояния

подход «состояния через классы» превращается в «состояния через данные», но классы и дальше используются как отражение состояния

Мини-чеклист готовности к React

вы уверенно используете import и export

вы понимаете, зачем нужен сборщик и dev server

вы можете объяснить разницу props и state

вы можете назвать примеры состояния в интерфейсе

вы понимаете идею «поднять состояние вверх» для общего поведения компонентов

Когда эти пункты понятны, React становится логичным продолжением вашего пути, а не резким прыжком.