Создание веб-сайта с 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: работа с вызовами CMS и API WordPress

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

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

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

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

Кэш WP REST API
Включите кеширование для 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
- Кэшировать вызовы nuxtServerInit

Для последнего это немного сложно и требует использования механизмов 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