Редактируемый продавцом слой Sections на Dawn

Собственная витрина не обязана означать витрину, доступную только разработчику. Визуальный слой может быть специфичным и брендированным, а повседневный контент при этом остаётся в руках команды, которая управляет магазином. Именно так проект Absolute Support удерживал рутинные изменения внутри редактора темы Shopify и данных о товарах, тогда как структурная логика оставалась работой инженеров.

Это третий из трёх детальных разборов по кейсу Absolute Support. Он следует за разбором компрессионного PDP и разбором фильтрации.

Проблема, в одном абзаце

Команде витрины нужно обновлять изображения, тексты, призывы к действию и FAQ, не открывая код темы и не дожидаясь разработчика ради каждого сезонного изменения. Но полный no-code контроль не является ни реалистичным, ни желательным: некоторые вещи, например поведение навигации и форма исходных данных, должны оставаться в руках инженеров, чтобы магазин не ломался незаметно. Задача состояла в том, чтобы провести эту границу осознанно, так чтобы у контента и структуры были разные, чёткие владельцы.

Ограничения

• Контент и структура: это разные задачи. Рутинный контент должен меняться самостоятельно. Структурное изменение должно быть проверенной работой инженеров. Их смешение приводит к тому, что тема превращается в неподдерживаемый конструктор страниц.
• Переиспользование вместо разовых решений. Section, созданная ради отрисовки одного конкретного дизайна и один раз, это обуза. Sections должны были переиспользоваться между товарами и коллекциями.
• Редактирование должно оставаться нативным. Команда уже знает редактор темы Shopify. Правильной поверхностью управления был этот редактор, а не отдельная админка на заказ.
• Никаких хрупких ссылок в переиспользуемых частях. Переиспользуемая section, которая жёстко задаёт конкретный товар или коллекцию, перестаёт быть переиспользуемой в тот момент, когда каталог меняется.

Как устроен слой sections

Контентный слой построен из переиспользуемых Shopify OS 2.0 sections. Для читателей, впервые сталкивающихся с Shopify: OS 2.0 sections это настраиваемые блоки страницы, которые продавец может добавлять, удалять и менять местами в редакторе темы. Каждая section здесь предоставляет настройки (текст, изображения, ссылки), повторяемые blocks (для списков вроде FAQ или строк с характеристиками) и preset, чтобы она появлялась в меню редактора «add section». Sections выбирают товары и коллекции через нативные пикеры Shopify, а не через жёстко заданные handle, и несут разумные общие значения по умолчанию, чтобы новая страница выглядела законченной ещё до того, как её кто-либо настроит. Там, где товару нужна собственная версия общего контента, section читает переопределение из product metafield.

Владение контентом: кто что редактирует

Граница между двумя владельцами и есть суть всего решения.

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

• Изображения, тексты и призывы к действию
• FAQ и похожий списочный контент
• Конкретные товары и коллекции, которые показывает section
• Опции подборщика и коллекция назначения, на которую указывает каждая опция
• Переопределения контента для конкретного товара

Во владении инженеров:

• Поведение навигации
• Соглашения о данных и сама схема metafields
• Структурные макеты
• Поведение, внедряемое приложениями
• Новые контентные примитивы, то есть новые типы section

Короткая версия и правило, которое стоит сформулировать прямо: рутинные изменения контента делаются самостоятельно. Структурные изменения остаются работой инженеров.

Поток переопределения через metafield

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

Shared section defaults       (authored)
        |
        v
Product metafield override    (merchant data, optional)
        |
        v
Product-specific content      (rendered output)

  no override present:
        |
        v
  falls back to the shared default

Одна общая section может обслуживать весь каталог. Товар, которому нужны собственные изображение, заголовок, бейдж или основной текст, задаёт их через metafield, и section отрисовывает именно их вместо значения по умолчанию. Товар, у которого ничего не задано, всё равно отрисовывает полный базовый вариант, так что только что добавленный товар никогда не бывает пустым. Что важно, переиспользуемый слой sections ссылается на товары через данные и пикеры, а не через жёстко заданные ссылки на товары, и именно это делает его безопасным для переиспользования. Здесь я хочу быть точным: это утверждение о переиспользуемом слое sections, а не заявление о том, что во всей теме нигде нет ни одного жёстко заданного идентификатора.

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

Та же логика запасных вариантов проходит через баннер коллекции, так что страница коллекции выглядит завершённой ещё до того, как её кто-либо тронет.

Collection-specific image (set in the theme editor)
   -> else a collection metafield image
   -> else the collection's own image
   -> else a shared default image

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

Настройка подборщика

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

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

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

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

• Sections поставляются с разумными presets, так что добавление одной даёт рабочий, заполненный блок, а не пустую оболочку.
• Настройки несут осмысленные подписи, так что редактирующий человек понимает, что делает каждый элемент управления.
• Безопасные значения по умолчанию означают, что section никогда не оказывается случайно пустой.
• Не каждое решение по стилизации выведено как настройка. Избыточный вывод элементов управления делает редактор сложнее в использовании, а не проще, поэтому стилизация на уровне пикселей остаётся в коде, а контент остаётся редактируемым.

Редактирование на десктопе, отрисовка на мобильных

Одно честное различие: редактор темы это в основном десктопный инструмент, но витрина, которую он создаёт, mobile-first. Редактируемость продавцом не гарантирует качество на мобильных. Команда может задать вполне хороший контент и всё равно столкнуться с макетом, которому нужна явная адаптивная обработка. Поэтому sections строились и проверялись на мобильную отрисовку отдельно от опыта редактирования. Редактируемость и корректность на мобильных это две разные гарантии, и обе нужно было спроектировать.

Что осталось структурным

Это осталось работой инженеров, а не настройками редактора:

• Дополнения к схеме и схема metafields
• Новые типы section
• Логика навигации
• Изменения системы макетов
• Поведение, внедряемое приложениями

Проверка

На уровне реализации, а не бизнес-результат:

• Контентный слой это переиспользуемые OS 2.0 sections.
• Sections предоставляют presets и blocks.
• Sections используют нативные пикеры товаров и коллекций.
• Переопределения через product metafield управляют контентом для конкретного товара.
• Запасной контент отрисовывается, когда переопределение отсутствует.
• Переиспользуемый слой sections не содержит жёстко заданных ссылок на товары.
• Рутинный контент можно менять в редакторе темы.

Компромиссы

• Пересекающиеся паттерны sections. Несколько баннерных и обучающих sections разделяют большую часть своего макета и могли бы быть объединены в меньшее число параметризованных sections.
• Часть обучающих текстов зафиксирована в коде. Определённый сравнительный контент живёт в шаблоне, а не в настройках, поэтому изменение этих формулировок требует разработчика.
• Разрастание sections и сложность схемы. Больше типов section означает больше поверхности для поддержки, а настройки могут разрастись до точки, где ими уже неудобно пользоваться.
• Консолидация это работа на будущее. Переиспользуемое ядро надёжно; дублирование это долг, который нужно погасить.

Что я улучшил бы дальше

• Объединить продублированные обучающие и баннерные паттерны в меньшее число параметризованных sections.
• Перенести оставшиеся зафиксированные тексты в настройки.
• Задокументировать соглашения редактора, чтобы изменения контента оставались согласованными.
• Проверить пустые состояния, чтобы ни одна section не могла отрисоваться пустой.
• Добавить проверки визуальной регрессии на мобильных, чтобы изменение в редакторе не могло незаметно сломать макет на телефоне.

Назад к полной истории: кейс Absolute Support.