Почему Shopify возвращает структуру тем в читаемый код — и что это открывает для разработчиков, мерчантов и агентов.
Ровно 12 лет назад я начал создавать свой первый магазин на Shopify.
Я не был разработчиком в полном смысле. Я был технически подкованным дизайнером, знающим HTML, CSS и ровно столько jQuery, чтобы быть опасным. Я знал одно: я хотел витрину, которая выглядела бы полностью кастомно под мой бренд, — но при этом не хотел управлять целым стеком электронной коммерции ради этого.
И тут я нашел Shopify.
Я скачал Timber, открыл его шаблон коллекции, и всё встало на свои места:
1{% for product in collection.products %}2 {% include 'product-grid-item' %}3{% endfor %}
Весь шаблон состоял из 100 строк кода. Я мог понять, как он работает, просто прочитав код. Мне почти не нужна была документация, кроме шпаргалки Марка Данкли.
Для разработчиков тем это была золотая эра читаемости. Для мерчантов глобальных настроек темы явно не хватало.
Компромисс, на который мы пошли
Настройки темы могли завести нас лишь до определённого предела. В 2016 году Shopify представила разделы, и изменилось сразу три вещи.
- Мерчанты стали мерчандайзерами. Люди без навыков программирования могли формировать страницы и рассказывать гораздо более насыщенную историю продукта.
- Разработчики стали дизайнерами компонентов. Разделы должны были быть модульными, гибкими и работать в любом порядке.
- А темы стали продуктами. Разработчикам пришлось думать о создаваемом интерфейсе и сознательно искать компромисс между простотой использования и гибкостью.
Эти тенденции ускорились с появлением Dawn в 2016 году, а затем Horizon в прошлом году, когда «блоки» стали основным компонуемым элементом в темах.
Чтобы представить разделы и блоки в каждом шаблоне, Shopify потребовался формат сериализации. Шаблоны перешли на JSON.
Этот компромисс дал мерчантам гораздо больше контроля, но обошёлся в качество опыта разработчика: теперь понять страницу, прочитав один файл, стало невозможно. Приходилось сопоставлять JSON, Liquid, схемы, настройки, разделы и блоки, чтобы восстановить, как работает страница.
Как только шаблоны стали JSON, они перестали быть удобной поверхностью для разработчика. Они превратились в автоматически сохраняемый вывод — то, что мы буквально предупреждали разработчиков не редактировать вручную.
Это был разумный компромисс для эпохи «императивного ПО», когда мерчанты управляли магазином через кнопки, ручки и настройки, указывая, что именно должно измениться.
ИИ меняет уравнение.
Отличный опыт разработчика — это отличный опыт агента
Когда мы дали Sidekick возможность редактировать темы, онлайн-редактор магазина вступил в эру «декларативного ПО». Простой пример: вместо того чтобы открывать палитру цветов и выбирать \[#0000FF](https://x.com/search?q=%230000FF&src=hashtag_click)\, мерчант мог просто сказать: «Сделай это синим».
В этом году мерчанты уже совершили 25 миллионов правок тем через Sidekick, и каждый пятый мерчант использует ИИ для редактирования своей темы.
В то же время разработчики всё чаще используют агентов для написания кода. Это значит, что у Shopify теперь две взаимосвязанные задачи:
- Дать агентам лучшие инструкции.
- Дать им лучшую обратную связь.
Для инструкций мы выпускаем улучшенные навыки Liquid. Темы также могут содержать указания для агентов через каталог \.agents\ и файлы вроде \AGENTS.md\ и \DESIGN.md\, чтобы помочь агентам понять, как вы хотите, чтобы писался код, и как сохранять дизайн в стиле бренда.
Для обратной связи мы расширили тег \{% doc %}\ до типизированных контрактов для сниппетов и блоков. Параметры можно документировать, типизировать, проверять с помощью Theme Check, а также сопровождать примерами использования.
1{% doc %}2 @param {string} [variant]3 @param {string} [tag]45 @example6 {% block 'text', tag: 'h1' %}7 Featured Collection8 {% endblock %}9{% enddoc %}
Когда вы пишете код вручную, это даёт вам обратную связь в реальном времени, интеллисенс и ошибки; а также позволяет агентам обнаруживать допустимые параметры, учиться на хороших примерах и получать полезную обратную связь, когда они галлюцинируют несуществующий API.
Мы также добавили 20 новых правил Theme Check, охватывающих контракты, структуру, валидацию, сложность, вложенность и ограничения размера файлов.
Удивительная вещь для разработчиков вроде меня в эпоху агентов — она вознаграждает то же, что мы всегда хотели: читаемый код, явные контракты и быструю обратную связь.
Поэтому мы задались более масштабным вопросом: какой была бы идеальная архитектура темы, если бы эти качества были основополагающими принципами?
Мы создаём новую базовую тему Shopify, которая объединяет все наши идеи.
(Стоит упомянуть… это новая архитектура, оптимизированная для агентов, но это не принудительный переход. Существующие темы продолжат работать вечно; Liquid был и всегда останется вечным API.)
Структура страницы снова стала читаемым кодом
Первое, что вы заметите в новой теме, открыв каталог \templates\: шаблоны снова стали файлами Liquid.
Её шаблон коллекции примерно такой же длины, как у Timber, а во всей теме на 93% меньше строк кода, чем в Horizon. Это не попытка сделать тему «всё включено», как Horizon; её задача — максимально упростить создание с использованием всех примитивов коммерции в Shopify и заложить основу для достижения наилучшей производительности, оставляя вам свободу строить всё то, что делает каждый магазин уникальным.
Зачем возвращать структуру страницы в Liquid?
Глубокая проблема сериализованной конфигурации не в том, что JSON сам по себе плох. Проблема в том, что у конфигурации ограниченный словарь. Разработчик темы должен предвидеть композиции, которые может захотеть мерчант.
Представьте раздел, содержащий одну кнопку. Мерчант просит агента добавить вторую кнопку рядом.
В архитектуре, управляемой настройками, тема должна уже содержать групповой блок, способный вместить обе кнопки, или разработчик должен был предусмотреть настройку для второй кнопки.
В HTML вы просто добавляете ещё одну кнопку и оборачиваете пару в \div\.
Каждая ведущая модель уже понимает HTML. Он выразителен, локален и эффективен с точки зрения токенов. И у Shopify уже более 20 лет есть язык, необходимый для объединения этой выразительности с коммерцией: Liquid.
Блоки и HTML вместе
Новая архитектура вводит компонуемый тег \{% block %}\, который можно использовать непосредственно в шаблонах Liquid.
1<div class="mb-8">2 {% block 'text',3 tag: 'h1',4 block.settings.variant: 'type-heading-xl',5 class: 'mb-2'6 %}7 {{ collection.title | escape }}8 {% endblock %}9</div>
Блоки принимают именованные параметры. Они могут содержать вложенный контент. Их параметры можно типизировать через \{% doc %}\. Они определяют границы того, с чем мерчант может взаимодействовать, в то время как обычный HTML обрабатывает всё остальное.
Если вы работали с компонентной системой вроде React, модель покажется знакомой: параметры ведут себя как пропсы, а вложенный контент — как children. Но это остаётся Liquid — достаточно простым, чтобы читать сверху вниз в одном файле.
Это делает композицию явной, не требуя превращать каждый элемент разметки в отдельный раздел, блок или настройку.
Точная реактивность с помощью partials
Разработчики тем использовали Section Rendering API далеко за пределами его первоначального назначения, потому что это был лучший доступный инструмент для серверной реактивности.
Мы хотели чего-то более точного.
Вдохновляясь новыми подходами к декларативным частичным обновлениям, мы представляем простой примитив под названием partials для Liquid.
Оберните область, которую можно повторно отрендерить:
1{% partial 'cart-count' %}2 <span>3 {{ 'cart.count' | t: count: cart.item_count }}4 </span>5{% endpartial %}
Затем получите свежий HTML и примените его там, где нужно:
1const html = await partials.fetch('cart-items', 'cart-count');2partials.apply(html);
Вот и всё. Точные серверные обновления без рендеринга целого раздела и без внедрения виртуального DOM.
Добавление товара в корзину может обновлять соответствующие области корзины всего в несколько строк. Этот один примитив позволит нам убрать тысячи строк реактивного кода из Horizon.
Стандартные события и действия
Мы также делаем типичные взаимодействия с витриной проще и более совместимыми.
Стандартные действия предоставляют общий контракт для операций, таких как обновление корзины. Стандартные события позволяют темам и приложениям реагировать через один и тот же стабильный словарь.
1const { cart } = await Shopify.actions.updateCart({2 lines: [{3 merchandiseId: variant.id,4 quantity: 1,5 }],6});
Это проще писать разработчикам, проще интегрировать приложениям и проще понимать агентам. Стандартные действия работают во всех магазинах Shopify сегодня, а поддержка WebMCP даёт браузерным агентам семантический путь для просмотра и добавления товаров, пока витрина отвечает на эти взаимодействия.
Цель не в том, чтобы прикрутить «режим ИИ» к витрине. Цель — сделать возможности витрины ясными и компонуемыми для всех участников: тем, приложений, разработчиков и агентов.
Делаем Liquid безопаснее для развития
Были и очевидные возможности языка, которые мы хотели добавить в Liquid: булевы выражения, инфиксные операторы с приоритетом, литеральные массивы и объекты.
Препятствием было не отсутствие желания. Исторический парсер Liquid принимал неоднозначный синтаксис, который формально не был валидным. Введение нового синтаксиса могло изменить поведение существующих тем.
Команда провела масштабную миграцию для безопасного перевода тем на строгий парсер. Эта работа даёт нам пространство для развития Liquid без нарушения работы витрин, которые уже от него зависят.
Это открывает более простые и знакомые выражения:
1{{ 1 + 1 }}2{{ false && false || true }}3{% assign products = ["shirt", "hat", "shoes"] %}
А также делает ошибки более предсказуемыми — как для разработчиков, так и для агентов.
И ещё кое-что: Tailwind
Скоро мы добавим поддержку Tailwind в темы на Liquid.
Агенты отлично с ним работают. Разработчики уже его знают. И он даёт нам общий язык стилизации, построенный на дизайн-токенах, без необходимости навязывать мерчантам сложную систему сборки.
Этот общий словарь важен. Чем лучше агенты понимают структуру, контракты и стилистические намерения, тем больше разработчики могут сосредоточиться на том, что действительно отличает бренд.
Назад в будущее
Двенадцать лет назад Shopify зацепил меня тем, что я мог открыть тему, прочитать код и понять магазин.
Со временем мы сделали темы гораздо более гибкими для мерчантов, но код стал менее прозрачным.
Агенты дают нам шанс объединить эти две вещи: гибкость, необходимую мерчантам, и читаемость, которую заслуживают разработчики.
Именно в этом направлении движется новая архитектура:
- Шаблоны Liquid как читаемая структура страницы.
- Компонуемые типизированные блоки вместе с обычным HTML.
- Навыки агентов и руководство на уровне репозитория.
- Более богатая обратная связь через \
{% doc %}\и Theme Check. - Точная реактивность через partials.
- Общие контракты витрины через стандартные события и действия.
- Строгий парсер, позволяющий Liquid безопасно развиваться.
- Tailwind как общий язык стилизации.
Предварительная версия для разработчиков и документация доступны уже сейчас:
https://shopify.dev/docs/storefronts/themes/getting-started/developer-preview
Попробуйте и поделитесь своими отзывами. Не терпится увидеть, что вы создадите!
