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

Вчера Алекс Шилс опубликовал обновление предлагаемых рекомендаций для каталога блоков WordPress. В документе добавлены восемь правил, которым должны следовать авторы плагинов, если они планируют добавлять свои разовые блоки в каталог. Рекомендации – это дополнительные требования к существующим рекомендациям по каталогам плагинов.

Хотя формулировка и организация руководящих указаний по блокам были переработаны по сравнению с исходным предложением, общее настроение не изменилось. Шилс благодарит разработчиков сообщества за отзывы об исходных правилах, но не вдавался в подробности о том, что изменилось в результате.

Первичные руководящие принципы в основном являются ожидаемыми, стандартными требованиями к блокам. Разработчикам нужен файл block.json. Они должны правильно называть вещи. Плагины должны содержать только один блок. Плагины должны касаться только редактора блоков. После активации блоки должны работать без сбоев.

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

Монетизация по-прежнему не разрешена

Самый большой отклик на руководящие принципы, которые мы получили здесь, в Таверне, заключался в полном запрете коммерческих интересов для разработчиков блоков. Блоки по-прежнему не могут подключаться к платным сервисам или рекламироваться в админке. Это ограничение, очевидно, оттолкнет многие компании, которые, возможно, ожидали, что каталог блоков станет потенциальным источником прибыли. Прямо сейчас люди с альтруистическими интересами должны будут строить разовые блоки, отдавая их сообществу просто из доброты своих сердец.

Хотя в этом нет ничего плохого по своей сути, это не привлекает разработчиков, которые в первую очередь сосредоточены на том, чтобы заработать. Любители и крупные компании, у которых есть ресурсы, которые можно вернуть, хорошо подойдут для добавления блоков в каталог. Однако это заставит многих разработчиков задуматься, потому что это вряд ли принесет хорошую отдачу от инвестиций. Вместо этого эти разработчики с большей вероятностью отправят свои блоки в обычный каталог плагинов с помощью своих обычных методов допродажи. Это только усложнит обнаружение блоков для конечных пользователей.

Это упущенная возможность построить всестороннюю систему, справедливую как для пользователей, так и для разработчиков, которым нужно зарабатывать на жизнь. Будь то система тегов плагинов или конкретные рекомендации по монетизации, мы могли бы создать что-то, что сделало бы всех немного счастливыми и немного безумным, компромисс, объединивший хороший пользовательский интерфейс и удобство.

Не то чтобы никаких предложений не было. В январе Люк Карбис написал подробный план того, как WordPress может обеспечить золотую середину между устойчивостью (бизнес-модели) и доступностью (бесплатные варианты) с предстоящим каталогом блоков. Он опасался, что каталог блоков будет полон блоков без обновлений через несколько лет, потому что полностью бесплатная модель неустойчива. Его предложение представляло собой систему на основе значков, которая сообщала пользователям, содержит ли блок рекламу, использует ли модель freemium или требует входа в стороннюю службу.

Текущее руководство не высечено на камне. Это первая версия каталога блоков. Не исключено, что команда может что-то изменить по мере роста каталога со временем.

Нет любви к серверным блокам

Рекомендации по каталогам блоков по-прежнему в значительной степени ориентированы на статические блоки. PHP должен быть минимальным и в первую очередь использоваться для загрузки любых необходимых скриптов и таблиц стилей. На данный момент серверные блоки не привлекают особого внимания, что может быть ограничением программного обеспечения.

Было бы здорово увидеть способ включения некоторых серверных блоков в каталог блоков. Например, блок хлебных крошек должен во многом полагаться на PHP для рендеринга своего вывода. Это скорее динамический блок, чем статический. Этот конкретный блок не будет полезен до тех пор, пока полное редактирование сайта не появится в WordPress, до которого еще несколько месяцев. Однако мне не терпится превратить мой старый плагин  в блок. Было бы неплохо увидеть его в списке блоков.

Есть бесчисленное множество других сценариев. Списки публикаций, таблицы продуктов и данные, полученные из внешних API, – все это хорошие варианты использования одноразовых блоков.

Зависимости не допускаются

Учитывая способ работы WordPress, имеет смысл запретить зависимости от других плагинов для работы любого конкретного блока. Это старое ограничение, которое снова поднимает голову. Все остальные современные фреймворки используют какое-то управление зависимостями для решения этой проблемы.

Каталог блоков может еще больше усугубить проблему. Поскольку плагины, поступающие из этого каталога, будут отдельными блоками, это часто означает, что разработчики используют одни и те же биты кода в нескольких проектах. Например, конечный пользователь может активировать несколько подключаемых модулей блока, которые используют одну и ту же библиотеку JavaScript. Поскольку не существует 100% надежного способа убедиться, что загружен только один экземпляр этой библиотеки, пользователи могут запускать несколько экземпляров этой библиотеки на своих сайтах. Это не новая проблема, но плагины меньшего размера означают, что пользователи с большей вероятностью установят больше плагинов. Это увеличивает вероятность столкнуться с этой проблемой.

Если бы авторы плагинов могли использовать какое-либо базовое управление зависимостями в WordPress, это решило бы целый мир проблем. За прошедшие годы разработчики создали методы, позволяющие минимизировать проблемы, возникающие из-за отсутствия такой системы. Однако ничто не является надежным без стандарта, которому нужно следовать.

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