Спросите бармена: что происходит, когда изменяется разметка блока?

Я разработчик, который недавно начал разрабатывать с помощью Gutenberg. Есть куча удивительных преимуществ и возможностей, но есть и масса недостатков, несоответствий, а также совершенно ужасная и устаревшая документация.

Одним из худших аспектов Gutenberg с точки зрения разработчика является проверка блоков. Рассмотрим следующий сценарий. Я создаю собственный (нединамический) блок на основе JavaScript, а редактор CMS добавляет этот блок на тысячи страниц. Что происходит, когда или если мне нужно обновить разметку блока?

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

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

Разве не должен быть способ для разработчиков блоков отказаться от процесса проверки или глобальный способ восстановления блоков?

ПиДжей

Ты точно ничего не скрываешь, Пи Джей. Хотя многое из этого носит более технический характер, чем я обычно хотел бы рассказать здесь, в Tavern, я решил обратиться к Риаду Бенгуэлле, одному из ведущих разработчиков Gutenberg, чтобы получить больше информации о ситуации.

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

При разработке блоков или приложений любого типа, которые выводят интерфейсный код, вам нужно подумать о том, как это должно выглядеть сегодня и через 10 лет. Что произойдет, если пользователь добавит пользовательский CSS для оформления вашего блока, а HTML-структура блока изменится? С их точки зрения, ваше обновление блока сломало их сайт. То же самое можно сказать и о другом плагине, который каким-то образом расширяет ваш плагин.

Спросите любого автора темы, как он разочаровывается, когда Gutenberg/WordPress меняет свой блочный вывод. Хотя за последние пару лет он улучшился, блоки стилей для редактора и внешнего интерфейса часто были кошмаром для обслуживания.

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

Это увеличивает время раннего проекта, когда вы просто пытаетесь передать его пользователям. Здесь помогает сделать шаг назад перед выпуском. Отойдите от компьютера. Отправляйтесь на прогулку. Подумайте об архитектуре вашего проекта и о том, идеален ли он в долгосрочной перспективе.

«Для блочного управления версиями/обновлениями это действительно одна из областей API Gutenberg, где нам нужно было пойти на архитектурные компромиссы, и мы решили отдать предпочтение пользовательскому опыту, а не разработчику», — сказал Бенгуэлла.

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

«Чтобы правильно понять проблему, нужно понять, как блоки работают и редактируются», — сказал Бенгуэлла. «Экземпляры блоков — это объект JSON, и пользовательский интерфейс редактора манипулирует этим JSON, но для обеспечения обратной совместимости, обеспечения сохранения пользовательского контента в наиболее читаемом формате и максимально возможного соответствия веб-стандартам редактор блоков хранит не объект JSON, а его HTML-сериализацию в post_content ».

Эта сериализация анализируется и преобразуется в JSON, когда редактор перезагружает содержимое для повторного редактирования. На заключительных этапах парсинга автор блока должен решить, как сохранить и парсить объект.

«А теперь представьте, если бы пользователь изменил сохраненный HTML (сериализация) и просто поместил туда любой случайный контент», — сказал Бенгуэлла. «Возможно, блок не сможет правильно проанализировать HTML, потому что он не соответствует его ожиданиям (то, что было определено автором блока), что означает, что воссоздание этого объекта JSON для манипулирования будет невозможным в этот момент. ».

Когда это происходит, редактор блоков предоставляет пользователю интерфейс для принятия обоснованного решения. Они могут попытаться «принудительно проанализировать» блок JSON или преобразовать его в HTML или классический блок.

Такой же тип инвалидации может произойти, когда разработчик плагина обновляет свой блок. Однако вместо изменения сохраненного HTML разработчик изменил «ожидания» блока — изменив способ его сохранения и анализа.

«Вот почему мы просим разработчиков блоков предоставлять устаревшие блоки, представляющие старую разметку того же блока», — сказал Бенгуэлла. «Устаревшие также можно рассматривать как действительные альтернативные источники для одного и того же блока. Это позволяет редактору анализировать старую разметку при загрузке и сохранять новую разметку обратно, если в блок вносятся изменения».

В WordPress есть документация об устаревании блоков. Однако это не тщательно. Лучший источник информации об устаревании в реальном мире — просмотр библиотеки блоков Гутенберга. У устаревших блоков есть файл deprecated.js .

Бенгуэлла сказал, что эта система может разочаровать авторов блоков. Особенно это проявляется в среде разработки при внесении изменений. Это побудило разработчиков запросить метод отключения алгоритма проверки.

«Это то, что мы не хотим предоставлять в данный момент, потому что, как объяснялось выше, проверка также важна, когда разметка изменяется по другой причине (внешнее редактирование, другой редактор и т. д.)», — сказал он. «Таким образом, это может привести к потере контента для пользователей без их ведома. Сейчас предпочтение отдается осведомленности пользователей».

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