Компонентный подход в WordPress

Всем привет. Сегодня я хотел бы рассказать о своём подходе к разработке тем WordPress. Не беру на себя ответственность говорить, что этот способ революционный или какой-то особый, но таким образом написанных тем я как-то особо и не видел.

Для начала немного истории. С WordPress’ом я познакомился достаточно давно, в бытность свою студентом. Сидел я в общежитии, какой-то сайт на Joomla собирал, и тут мне мой товарищ и сосед говорит:

— А зачем тебе такая сложная CMS? Попробуй вот это!

И протягивает ссылку на сайт на WordPress. Поначалу, признаюсь, я не сильно её оценил и продолжил использовать Джумлу. Но в какой-то момент животный интерес ко всему новому возобладал и я её установил. Если бы в то время уже вышел Хоббит, то чувствовал себя бы Торином Дубощитом.

Чем дальше я погружался в мир WordPress, тем больше он мне нравился – по плагинам и темам он явно не уступал, а вот по UI/UX на мой вкус сильно превосходил конкурента. А организация файлов темы – это ж просто сказка какая-то, просто песня.

Ни в коем случае не хочу умалить достоинств Joomla, но лично мой выбор остановился на WP и до сих пор я использую его для разработки сайтов. Когда я только начал погружаться в удивительный мир темостроения и вордпрессоводства, то примеры я черпал из официальных тем + того, что было в репозитории. Открывал я код, а там примерно такое:

— Ну код и код, может тут так принято, — думал я и просто учился писать свои темы по принципу «мартышка видит – мартышка повторяет». Потом, правда, стало приходить и осознание происходящего, и даже появилось некое творчество.

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

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

В целом, ничего в таком коде криминального-то и нет, если не считать того, что зачастую такую простыню текста очень сложно воспринять, а ещё прощё – поставить или не поставить закрывающий тег в нужном месте, после чего красивый список товаров бодро сваливает за границу вселенной экрана. И даже IDE с подсветкой строк не всегда помогает. Мысль о том, что нужно что-то менять, уже висела в воздухе, но пока не совсем было понятно, что делать.

И здесь мы плавно подходим к самой сути. В какой-то момент я плотно подсел на React. В те давние времена ещё писали на классах, но потом все завертелось и все двинулись в сторону функциональных компонентов и хуков. Зерно было посеяно, правда, непонятно, что за растению дано было из него вырасти.

В один прекрасный день, когда я пилил сайт на React, а API решил сделать на WordPress (благо, уже вышел REST API прямо из коробки), то мне пришла в голову одна мысль. В тот момент я делал сайт, где была достаточно стандартная по компоновке страница – карточки постов с навигацией, фильтрами и поиском. Изначально страницу рендерит php, а уже затем, при изменении пагинации, фильтров и вводе в строку поиска через api подгружаются новые данные и javascript их перерисовывает.

Вроде неплохой вариант, но изначально я сделал так, что api возвращает мне в ответ json, и по сути мне приходилось повторять там точно такую же вёрстку. И всегда помнить про консистентность, потому что если карточка поменяется, то менять её нужно будет в двух местах. Что, согласитесь, не круто.

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

В процессе я понял, что всё равно получается задвоение кода:

1. в файле шаблона темы типа loop.php, потому что стандартная логика шаблона предполагает, что можно вызвать волшебную функцию типа the_title() и WordPress сам поймёт, какой заголовок туда вставлять;
2. в функции, которая даёт результирующий код.

Опять то же самое – если что-то поменяется, то необходимо исправлять код дважды.

И тут меня озарило – функциональные компоненты! Можно же сделать то же самое. И даже кое-что поинтереснее, но об этом чуть ниже.

Вначале приведу пример разницы между двумя подходами – допустим, у нас есть некая карточка поста с обложкой, заголовком, описанием и кнопкой «Открыть подробнее».

В стандартном виде она будет выглядеть примерно так:

А теперь то же самое, но в функционально-компонентном стиле:

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

Во-первых, это переиспользуемость. На маленьких проектах она может быть абсолютно незаметна, но на больших, где есть несколько вариантов карточек, состоящих из одних и тех же элементов (атомарный подход) количество написанного кода сокращается в разы. И при изменении компонентов не нужно будет менять код в нескольких местах.

Собственно, выделение в моём примере в отдельные функции получение кода обложки и кнопки – и есть атомарный подход.

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

Во-вторых, это читаемость. Здесь нет бесконечных открытий / закрытий php, переносов на новые строки за 10 табов. Один компонент отвечает за один небольшой функционал, его достаточно просто редактировать.

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

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

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

На этом всё. И не забывайте, что код – это поэзия.