Создание веб-сайта с Nuxt.js и WordPress REST API

Обновление:
Теперь вы можете использовать мой шаблон из общедоступного репо:
https://github.com/bovas85/nuxt-headless
(пожалуйста, пометьте 🌟 если вы это цените, не стесняйтесь вносить свой вклад).

Часто мы оказываемся в ситуации, когда нашим клиентам нужна система управления контентом (CMS и далее), которая позволит им редактировать свои страницы, не зная для этого HTML-код.

Затем обычно возникает выбор между индивидуализированной CMS и WordPress (в последнее время мы видим все больше и больше «безголовых» CMS, а также очень действенную альтернативу уценке или статическим вариантам CMS).

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

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

Что касается Frontend, я отвечал за выбор стека, и, поскольку я очень люблю Vue.js (Vue 2), я определенно продвинул это вперед, используя Nuxt.js для рендеринга на стороне сервера (с этого момента SSR).

Часть 1. Что такое Nuxt.js?

Nuxt.js PRO:
1) автоматически генерируемая маршрутизация с промежуточным программным обеспечением, валидаторами и т. д.
2) полная поддержка SSR из коробки с поддержкой vuex
3) страницы система с обработчиками асинхронных данных, переходами, индикатором загрузки и т. д.
4) система макетов из коробки
5) обработка метаданных из коробки с поддержкой SSR
6) все модные модули nuxt, обеспечивающие такие вещи, как PWA, аутентификация, автономная поддержка и многое другое
7) подход к конфигурации, который я предпочитаю.
8) Сообщество разработчиков Vue, которые все работают с одним и тем же упрямым подходом.

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

Это без учета SSR ...

- @ gustojs # 2934 с канала VueLand в Discord

Как видите, эти функции являются огромным преимуществом для небольшого агентства, которое не может тратить слишком много времени на разработку корпоративной архитектуры для своего стека.
WordPress недавно включил REST api в основной пакет (4.6.0 ) и я решил попробовать это для нашего первого сайта.

Это был переход с внешнего интерфейса AngularJS…

Часть 2, начальная настройка

Первым требованием было сделать веб-сайты максимально дружественными к SEO, исходя из Angular 1 / 1.5, где единственным простым решением был prerender.io (который не был реализован).

Раньше я пробовал Nuxt для побочного проекта, но ничего не получается, если вы не усердно над ним работаете.

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

Вы можете начать с установки vue cli, если еще не сделали этого:

npm install -g vue-cli

(следите за vue-cli 3, который скоро выйдет, поскольку он может изменить эту следующую команду)

Затем, используя vue-cli, вы можете запустить новый проект Nuxt, набрав:

vue init nuxt-community/starter-template <project-name>

Где ‹project-name› - это ваша папка и имя проекта.
Вы создадите каталог, содержащий несколько других и файл nuxt.config.js:

Первое, что нужно понять о Nuxt, - это то, что это беспроблемный фреймворк вокруг VueJS и SSR.

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

Часть 3, Идем глубже

Первоначально основная проблема заключалась в том, как интегрировать sass и использовать переменные sass в моем проекте.
Мне пришлось сделать это волшебство, чтобы переменные были доступны в каждом отдельном файловом компоненте (SFC) или странице

Это стало намного проще благодаря модулю Nuxt, который можно просто добавить в nuxt.config в массив со списком переменных sass для глобальной загрузки.

Следующим шагом было выяснение того, как управлять государством.

По какой-то причине я подумал, что глобальный миксин был хорошей идеей

Реальность такова, что когда у вас есть пара компонентов, может быть, панель навигации или модальные окна, уже пора загружать Vuex.

Сделать это в Nuxt очень просто:

Nuxt также позволяет заранее загружать каждое значимое состояние с помощью действия NuxtServerInit в магазине.
Это позволяет вам предварительно загружать все, что вам нужно, без необходимости использовать смонтированный для его загрузки (и таким образом терять SSR).

Существуют и другие методы, которые можно использовать вне хранилища: asyncData (загружает данные в компонент) и fetch (фиксирует изменения или отправляет действия).

Их можно использовать, если вам нужно что-то только локально внутри компонента или страницы.

Здесь нужно понимать, что мы имеем дело с двумя экземплярами.
Один на сервере, виртуальный и невидимый, и один на стороне клиента.

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

Nuxt включает в себя компонент ‹no-ssr›, который может обернуть все, что угодно, включая другие компоненты, если у вас есть единственный корневой элемент внутри него.

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

Если вы не сделаете этого или чего-то еще, что я покажу сейчас, вы можете столкнуться с другой древовидной структурой, о которой Nuxt уведомит вас:

Другая проблема заключается в том, как библиотеки и компоненты загружаются в Nuxt.
Мы загружаем их, создавая плагины в папке плагинов и прикрепляя их с помощью Vue.use, Vue.component или Vue.directive.

Второй шаг здесь - добавить этот плагин в nuxt.config, и здесь мы можем указать, готов ли это плагин к ssr (просто введя путь к плагину) или нет, указав там ssr: false.

Часть 4: работа с вызовами WordPress CMS и API

После того, как основной проект настроен и вы начнете работать с каждой страницей, самый быстрый и лучший подход, на мой взгляд, - это добавить плагин под названием:
Расширенные настраиваемые поля (ACF)
в бэкэнд WordPress.

Это добавляет функциональность настраиваемых полей на страницы и сообщения в WordPress.
Чтобы расширить это до REST API, вам также понадобится плагин под названием
ACF to REST API

Некоторые полезные дополнения:
Поля фильтра WP REST API
поля фильтра. Позволяет фильтровать поля, возвращаемые API.

WP REST API Pure Taxonomies
Этот плагин включает все доступные атрибуты таксономии в WordPress REST API (v2) без дополнительных запросов API.

WP REST API Cache
Включите кеширование для WordPress REST API и увеличьте скорость вашего приложения. (Я не рекомендую использовать этот плагин)
Предостережение:
Если вы выполняете почтовые запросы (пример плагина contact-form-7), убедитесь, что вы не используйте этот плагин или, если да, отфильтруйте строку 'contact-forms' в functions.php, как показано ниже:

add_filter( 'rest_cache_skip', function( $skip, $request_uri ) {
  if ( ! $skip && false !== stripos( $request_uri, 'contact-form-7' )) {
    return true;
  }
  return $skip;
}, 10, 2 );

Меню WP REST API
Расширяет WP API маршрутами меню WordPress.

Следующим шагом была настройка конечных точек API.
Я лично использовал файл config.js, который можно импортировать следующим образом:

импортировать конфигурацию из ‘~ / assets / config’;

Это позволит мне иметь четкое и настроенное местоположение конечной точки для всех моих страниц.

Вышеупомянутое частично взято у оператора роскошных путешествий Antilophia.
Сайт еще не работает, но я обновлю его здесь, когда он появится. Будьте на связи ;)

Получив указанную выше конфигурацию, вы можете настроить приложение для получения данных либо с помощью nuxtServerInit, либо с помощью fetch / asyncData.

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

Сервер будет обновлять контент каждый раз, когда загружает сеанс для пользователя.

Вы можете создавать динамические страницы, используя структуру папок: ‹dynamic-param›
Где ‹dynamic-param› - имя нужного вам параметра (например: пункт назначения)

Это дает вам доступ к параметру, используя:

this.$route.params.<dynamic-param>

Например, /pages/:mexico/index.vue вернет

this.$route.params.destination === ‘mexico’

Помните, что в asyncData или fetch у вас нет доступа к this, поскольку он запускается до монтирования страницы, но вы можете получить доступ к контексту ».

async fetch ({app, store, params}) {
  // this gives you acess to route params with the shorthand params 
  // but also to the store and the other app values
  // check all fields at https://nuxtjs.org/api/context/
}

Если у вас много вызовов API, я могу предложить два варианта:
- Используйте плагин WP REST API Cache, например WP REST API Cache
- Cache nuxtServerInit calls ( предпочтительно)

Для последнего это немного сложно и требует использования механизмов lre-cache и пакета axios-extensions.
Суть со всеми файлами приведена ниже.

Ссылка: https://gist.github.com/bovas85/8b5610ac94dd036628f53f702b300a64

Это особенно полезно, если вы создаете статический сайт (nuxt generate), поскольку nuxtServerInit будет запускаться один раз на каждую сгенерированную страницу (представьте, что у вас 20 динамических страниц, тогда он будет запускать 20 * вызовов API).

Часть 5. Как насчет развертывания приложения?

Мы попробовали два маршрута с этим.
1) Мы использовали статический сайт, созданный с помощью nuxt, обслуживаемый обычным сервером (старая школа). Быстро, но недостатком является то, что если у вас много динамических страниц, рендеринг динамических маршрутов будет немного сложным и медленным (проверьте здесь, как это сделать);
2) Мы использовали службу, размещенную на nodeJS, например Now (их несколько, или даже просто воспользуйтесь вашим хостингом, если он поддерживает NodeJS, наш - нет).

Я написал статью о конкретной проблеме при переносе домена на Now с GoDaddy, вы можете прочитать ее здесь:

Развертывание приложения SSR в Zeit Now из GoDaddy @MoustacheDsign https://medium.com/@moustachedesign/deploying-your-ssr-app-to-zeit-now-from-godaddy-41b51302375f

Теперь, после установки cli, вы просто набираете сейчас, и он развернет ваш сайт SSR за секунды (буквально, в зависимости от вашего соединения и размера сайта;))

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

Часть 6. Что дальше с Vue и Nuxt?

Vue и Nuxt больше не новички, существует большая экосистема плагинов, модулей и библиотек, которые доступны и будут становиться все больше и больше.

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

Nuxt.js - это OpenCollective и самофинансируемый.
Если вам это нравится так же, как и мне, подумайте о пожертвовании на https://opencollective.com/nuxtjs

Присылайте вопросы для Nuxt здесь (он интегрируется с проблемами Github, очень удобно!):
https://nuxtjs.cmty.io