Оглавление, кнопки навигации и таблицы удобно поддерживать в одном общем шаблоне. Статья передаёт ему содержание и разрешённые настройки, а шаблон отвечает за вид и поведение. Тогда исправление отступа, клавиатурного управления или мобильной ширины применяется ко всем материалам, которые используют этот блок.
Такое устройство особенно полезно журналу, который растёт. Пока статей три, одинаковую кнопку можно поправить вручную. Через полгода трудно вспомнить, куда скопировали старую версию и в каком материале сделали исключение. Проблема становится заметна читателю: на одной странице переход работает, на другой выглядит иначе, а на телефоне третья выходит за экран.
Разберём границу между данными статьи и интерфейсом, перенос повторяющегося блока и проверку результата. Для этого не нужно превращать весь сайт в сложный конструктор. Достаточно начать с одного повторения, которое уже приходится обслуживать.
Отделите содержание от правил показа
Заголовок раздела принадлежит статье. Размер этого заголовка и расстояние до текста принадлежат шаблону. Строки сравнительной таблицы меняются от материала к материалу, а поведение широкой таблицы на телефоне должно быть общим. Переключатель «показать оглавление» может храниться в записи статьи; сама логика раскрытия оглавления копироваться туда не должна.
Удобно составить два списка. В первый входят сведения, которые редактор меняет для конкретной публикации: текст, подписи, изображения, порядок разделов. Во второй — правила, которые требуется исправлять сразу для всех: внешний вид ссылки, доступ с клавиатуры, перенос длинного заголовка, сообщение об ошибке загрузки. Если один пункт оказался в обоих списках, уточните, какая его часть действительно индивидуальна.
Например, редактор может выбрать компактную или развёрнутую таблицу из двух поддерживаемых вариантов. Но произвольное поле «CSS этой таблицы» даёт возможность незаметно переопределить всё оформление. Через несколько публикаций общий блок перестаёт быть общим. Поэтому настройка должна выражать понятное содержательное решение, а не требовать от автора знания вёрстки.
В текущем журнале сведения статьи и настройки чтения хранятся отдельно от общего рендерера. Это позволяет менять текст без копирования интерфейса. Принцип переносится и на другие системы: конкретные названия файлов вторичны, важна единая ответственность за каждое правило.
Что меняется после выделения компонента
В документации React о компонентах повторно используемый элемент интерфейса описан как самостоятельный блок, который можно включать в разные страницы. На практике для журнала это может быть оглавление: оно получает список разделов, строит ссылки и одинаково обрабатывает действия читателя.
Допустим, в длинных названиях пунктов иконка налезает на текст. Если оглавление одно, вы меняете его разметку или стиль, после чего все экземпляры получают исправление. Тексты десяти статей остаются прежними. Если же в каждой записи лежит собственный HTML оглавления, нужно исправить десять копий и убедиться, что ни одну не пропустили.
Передаваемые значения называют параметрами компонента, или props. React позволяет передавать через них строки, массивы, объекты и обработчики действий. Для нашего примера хватит списка заголовков, текущего раздела и настройки начального состояния. Передавать компоненту весь документ сайта «на всякий случай» неудобно: зависимости скрываются, и любой новый вызов становится труднее проверить.
Один компонент может появляться на нескольких страницах, сохраняя отдельное состояние каждого экземпляра. Раскрытие оглавления в одной статье не обязано раскрывать его в другой. Общность реализации и общность текущего состояния — разные решения. Смешение этих решений способно вызвать ошибку уже после удачного удаления копий.
Начните с реального повторения
Выберите блок, который приходится исправлять чаще всего. Для одного сайта это таблица, для другого — карточка рекомендации или нижняя навигация. Соберите его существующие варианты рядом и выпишите различия. Часть различий окажется содержанием, часть — осознанными вариантами, а часть — накопленными ошибками.
Возьмём кнопку возврата. Подпись на русском и английском — допустимое различие. Адрес возврата тоже может зависеть от раздела. А разные высота, обводка и фокус без причины — кандидаты на унификацию. Не нужно переносить каждое случайное отклонение в новый переключатель. Иначе вместо нескольких копий появится один компонент, внутри которого те же копии спрятаны в условиях.
Начните перенос с двух достаточно разных страниц. Короткая статья покажет базовый сценарий; длинная с таблицей и нестандартным заголовком проверит границы. После этого сравните результат с исходным видом и поведением. Если компонент подходит обеим страницам без знания их адресов, граница, скорее всего, выбрана разумно.
Проверка по адресу внутри общего блока — повод остановиться. Условие вроде «если это статья про таблицы, добавь особый отступ» привязывает интерфейс к конкретной записи. Лучше выразить причину: есть подпись, включён компактный вид или отсутствует соседний элемент. Тогда следующий материал с тем же свойством получит нужное поведение автоматически.
Определите, где хранится состояние
У блока есть данные, которые приходят со страницы, и временное состояние: что раскрыто, какой пункт выбран, куда прокручен список. При переносе важно решить, кому принадлежит каждое значение. Два независимых владельца легко расходятся: один считает панель закрытой, другой продолжает показывать её выбранный пункт.
В руководстве React по совместному состоянию для согласованной работы соседних компонентов предлагается поднять нужное состояние к общему родителю. Для журнала примером может быть выбранный раздел, который одновременно нужен тексту и оглавлению. При этом настройку публикации «показывать оглавление» следует брать из данных статьи, а не заменять временным состоянием интерфейса.
Продумайте переходы. Читатель открыл новую статью: должен ли сброситься выбор раздела? Он вернулся назад: нужно ли восстановить положение прокрутки? Он сменил язык: какой текст и какое состояние останутся? Ответы зависят от продукта, но их стоит записать до переноса, чтобы рефакторинг случайно не изменил привычный сценарий.
Отдельно проверьте несколько экземпляров. Если на странице есть два похожих раскрывающихся блока, их кнопки не должны управлять одной и той же панелью из-за повторённого идентификатора. Визуально такие ошибки могут быть незаметны до первого действия с клавиатуры.
Общая реализация требует разных проверочных данных
После выделения компонента не стоит ограничиваться страницей, на которой его разрабатывали. Общая ошибка теперь тоже распространяется широко. Поэтому составьте небольшой набор случаев, различающихся именно по нагрузке на блок.
Для оглавления это пустой список, один пункт, много пунктов и длинная строка. Для таблицы — несколько столбцов, длинные значения, отсутствующая подпись и узкий экран. Для навигации — короткая и длинная подпись, два языка, управление клавиатурой и возврат после перехода. Важно проверить результат действия, а не только наличие элемента.
Например, панель раскрывается по щелчку мыши, но её кнопка не получает видимый фокус при переходе клавишей Tab. Или таблица остаётся внутри колонки на компьютере, а на телефоне расширяет всю страницу. Такие дефекты относятся к общей реализации и должны исправляться там. Редактору не нужно сокращать правильный заголовок, чтобы обойти техническую ошибку.
Сравнивайте и состояние после изменения данных. Если у статьи удалили раздел, старый пункт не должен остаться в оглавлении. Если таблицу очистили, пустая рамка не должна занимать место. Успешная первая отрисовка ещё не подтверждает, что компонент правильно переживает редактирование и повторное открытие.
Переносите постепенно и проверяйте границы изменения
Перед переносом сохраните исходную версию и список страниц, где встречается блок. Сначала подключите общий вариант в ограниченном наборе материалов, проверьте его и только затем заменяйте остальные копии. В рабочем проекте это позволяет понять, какая правка вызвала регрессию, и вернуть прежнее поведение без восстановления текстов из памяти.
После переноса проверьте, что изменился именно интерфейс. Заголовки, адреса, даты публикации и изображения должны остаться прежними, если задача их не затрагивала. Общий шаблон не даёт разрешения заново импортировать весь контент сайта. Для изменений данных нужен отдельный понятный список.
Наконец, добавьте новую статью обычным редакторским способом. Если она сразу получает правильные кнопки, таблицы и оглавление, повторное использование работает. Если приходится копировать код из соседнего материала или просить разработчика добавить исключение для нового адреса, часть реализации всё ещё находится в данных.
На этом этапе полезен простой критерий готовности: содержательную правку можно внести в одной статье, а техническую — в одном общем блоке. Обе операции должны оставаться понятными тем, кто поддерживает сайт. Документация React и текущая модель журнала сверены 26 октября 2026 года.
