Новое предложение призывает участников прекратить объединение экспериментальных API от Gutenberg до ядра WordPress

Практика слияния экспериментальных API от Gutenberg с ядром WordPress может скоро подойти к концу. Новое предложение, опубликованное спонсируемым Automattic участником Адамом Зелински, призывает участников стабилизировать API перед их объединением в ядро.

За прошедшие годы около 280 экспериментальных API-интерфейсов были объединены с плагином Gutenberg, который Зелински проверил в тикете, который он открыл для выпуска в апреле. Чтобы сбалансировать стремление двигаться быстро с итерацией редактора(ов) и стремлением WordPress к обратной совместимости, количество экспериментальных API стало неприемлемым, и в настоящее время активно пересматривается практика их объединения в ядро.

Официально экспериментальные API помечены как таковые, чтобы воспрепятствовать их использованию третьими лицами, поскольку ожидается, что они изменятся. На практике люди, создающие для редактора блоков, все равно используют их, потому что они находятся в ядре, и они хотят расширить функции, которые позволяют эти API.

«Авторы плагинов и тем вынуждены полагаться на __experimental функции, которые могут быть удалены или изменены обратно несовместимым образом в любое время», — сказал Зелински, повторяя разочарование и опасения, которые многие разработчики испытывали в связи с проектом в последние несколько лет. «Это серьезное бремя обслуживания. Каждый новый выпуск Gutenberg/WordPress означает потенциально критические изменения».

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

• основные коммиттеры не желают использовать определенные функции библиотеки для облегчения основных задач, потому что они не доверяют надежности
• разработчики больше не обновляют клиентские сайты WP. Как основной коммиттер, который годами стремился поддерживать обратную совместимость, это меня разочаровывает. Как член команды безопасности это очень важно
• разработчики, решившие включить копии пакетов в темы и плагины, а не полагаться на глобальные переменные wp.* . Опять же, это беспокоит меня с точки зрения безопасности, но это также значительно увеличивает полезную нагрузку JavaScript, чем поддержание обратной совместимости.
• отчеты о нарушениях обратной совместимости в младших версиях: «вы не ожидаете, что выпуск 5.9.1 нарушит отзывчивость кучи изображений на наших сайтах за пределами редактора блоков»
• разработчики рассматривают возможность никогда не использовать базовые блоки, потому что они слишком нестабильны: «Я перестал использовать/расширять базовые блоки, потому что они слишком сильно менялись, и я использовал блоки ACF, чтобы, по крайней мере, я знал, что могу делать блоки, которые не будут ломать. Конечно, пользовательский интерфейс не так хорош, как основные блоки, но я в любое время выберу стабильность, а не разрушение блоков».

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

«Нестабильность между версиями уже начинает отталкивать некоторых из крупнейших внешних сторонников редакторов блоков», — сказал Уилсон.

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

«Как автор плагинов, который в настоящее время использует множество __experimental API, я бы хотел, чтобы они стабилизировались», — сказал Ник Диего, спонсируемый участниками WP Engine. «Большинство из них предоставляют важные функции, но создание продукта, основанного на __experimental API, всегда немного сбивает с толку. Пока процесс чрезвычайно прозрачен, широко освещается, и мы предоставляем авторам плагинов/тем руководство по переходу на стабильные версии, тогда мне нравится эта инициатива».

После нескольких месяцев обсуждения тикета Зелински изложил опасения участников в плане действий, предложенном в блоге Make WordPress Core.

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

«Это сохранит обратную совместимость и не должно заметно повлиять на размер пакета», — сказал Зелински. «Некоторым потребуется другое лечение; давайте обсудим это в каждом конкретном случае». Он также рекомендовал участникам подумать о том, нужно ли удалять существующий экспериментальный API, уже находящийся в ядре. Он не ожидает, что это произойдет во многих случаях, но рекомендует использовать устоявшиеся методы связи с авторами плагинов, использование мягкого устаревания и публикацию основных сообщений.

«Я также вижу здесь две вещи: использование и злоупотребление экспериментальными API во время разработки API (как правило, для использования и тестирования в плагине Gutenberg) и отсутствие тщательного процесса их стабилизации, когда они удовлетворяют критериям дизайна», Главный архитектор Гутенберга Матиас Вентура прокомментировал оригинальный билет. «Те, которые должны считаться общедоступными де-факто , — это те, которые существовали для многих выпусков в стабильной форме, несмотря на их номенклатуру».

В интересах сохранения способности WordPress выполнять свои обещания обратной совместимости, в предложении рекомендуется ограничивать экспериментальные API плагином Gutenberg и никогда не объединять их с ядром. В случаях, когда стабильная функция зависит от экспериментального API, Зелински нашел простой ответ:

«Тогда он на самом деле не стабилен. Давайте сначала стабилизируем зависимости».

По сути, это новый способ продвижения вперед, который должен повысить стабильность и уверенность в API и обновлениях WordPress, но у него есть несколько недостатков.

Пользователи и участники могут ожидать, что функции Gutenberg могут медленнее объединяться с ядром, поскольку они не могут полагаться на экспериментальные API, когда они попадают в прайм-тайм в основных выпусках. Зелински также отметил, что у участников также могут возникнуть трудности с рефакторингом этих API после того, как они будут отправлены и будут использоваться на миллионах сайтов WordPress.

До сих пор предложение получило исключительно положительную поддержку, поскольку многие считают, что эти API никогда не должны были появиться в ядре, пока они все еще находятся на экспериментальной стадии.

«Я полностью поддерживаю такой подход, — сказал разработчик WordPress Марк Рут-Вили. «Я создаю собственные темы и использую несколько простых плагинов. В обоих случаях мне несколько раз приходилось иметь дело с экспериментальными API и трудностями их обновления, когда в ядро ​​вводятся функции, которые можно отключить, настроить или расширить только с помощью экспериментального API».

«Возвращение к такой стабильности в ядре будет иметь большое значение для восстановления доброй воли разработчиков», — прокомментировал это предложение участник WordPress Довид Левин.

Крайний срок для комментариев по предложению — 7 сентября, что закроет обсуждение всего за три недели до того, как ожидается WordPress 6.1 Beta 1. Это дает участникам некоторое время для более тщательного аудита экспериментальных API перед следующим основным выпуском, если они достигнут консенсуса по ограничению их использования плагина Gutenberg.