Oprettelse af et websted med Nuxt.js og WordPress REST API

Opdatering:
Du kan nu bruge min kedelplade fra den offentlige repo:
https://github.com/bovas85/nuxt-headless
(stjerne venligst det, hvis du sætter pris på det, er du velkommen til at bidrage).

Ofte befinder vi os i den position, hvor vores kunder ønsker et Content Management System (CMS og fremefter), der giver dem mulighed for at redigere deres sider uden at skulle vide HTML-kode for at gøre det.

Det er derefter normalt et valg mellem en skræddersyet CMS og WordPress (for nylig ser vi mere og mere "Headless" CMS komme op, samt det meget gyldige alternativ til markdown eller statiske CMS-indstillinger).

I vores tilfælde valgte vi WordPress af nogle få grunde:
- Det er en solid CMS med mange års erfaring på banen
- Sikkerhedsspørgsmål er nu næsten væk, i betragtning af de automatiske sikkerhedsopdateringer fra version 4.7 og fremefter (jeg tager muligvis fejl i versionen, ikke citerer mig på det).
- WordPress REST API giver os adgang til flere felter (og tilpassede felter) uden behov for at servere hele frontend med WordPress.

Vores Backend-udvikler var også mere fortrolig med PHP, Laravel og WordPress end andre teknologier, så heldigvis valgte vi WordPress til sidst.

Med hensyn til Frontend var jeg ansvarlig for at vælge stakken, og da jeg elsker Vue.js (Vue 2) så meget, skubbede jeg bestemt det fremad ved hjælp af Nuxt.js til Server Side Rendering (SSR fra nu af).

Del 1, Hvad er Nuxt.js?

Nuxt.js PROs:
1) automatisk genereret routing med mellemwares, validatorer og mere
2) fuld SSR-support ud af kassen med vuex-support
3) sider system med async datakroge, overgange, indlæsningsindikator osv
4) layoutsystem ud af kassen
5) metadatahåndtering ud af kassen med SSR-support
6) alle de fancy nuxt-moduler, der leverer ting som PWA, godkendelse, offline support og mere
7) konvention over konfigurationsmetode, som jeg foretrækker
8) Et samfund af Vue bruger, at alle arbejder med den samme meningsfulde tilgang.
Punkt 8 er især stort, fordi Vue-samfundet er ekstremt splittet, fordi Vue er en progressiv ramme.
Folk bruger Vue på så mange forskellige måder, at det er fantastisk at have en stor del af Vue-samfundet, der faktisk bruger Vue på samme måde.
Det er eksklusivt SSR ...

- @ gustojs # 2934 fra VueLand Discord-kanal

Som du kan se, er disse funktioner en enorm fordel for et lille bureau, der ikke kan bruge for meget tid på at designe en virksomhedsarkitektur til deres stak.
WordPress bundtede for nylig REST-apien inde i kernepakken (4.6.0), og derfor besluttede jeg at prøve det til vores første websted.

Det var en migration fra en AngularJS-frontend ...

Del 2, startopsætning

Det første krævede punkt var, at webstederne var så meget SEO venlige som muligt, der kom fra Angular 1 / 1.5, hvor den eneste lette løsning var prerender.io (som ikke blev implementeret).

Jeg havde prøvet Nuxt tidligere til et sideprojekt, men tingene klikker aldrig på, medmindre du er hårdt i gang med det.

Jeg var bekendt med VueJS, men den oprindelige opsætning af Nuxt efterlod mig lidt tvivlsom over kapaciteterne. Det så for simpelt ud til at være sandt og uden nogen konfigurering fra den oprindelige CLI.

Du kan starte med at installere vue cli, hvis du ikke har gjort det endnu:

npm installere -g vue-cli

(pas på vue-cli 3, der snart kommer ud, da det kan ændre denne følgende kommando)

Derefter ved hjælp af vue-cli kan du starte et nyt Nuxt-projektindtastning:

vue init nuxt-community / starter-template 

Hvor er din mappe og projektnavn.
Du stilladser et bibliotek, der indeholder flere andre og en nuxt.config.js-fil:

første nuxt.config.js-fil til min vue-meetup-samtale

Den første ting at forstå om Nuxt er, at det er en problemfri ramme omkring VueJS og SSR.

Den bruger kun moduler og biblioteker, der allerede findes i VueJS, men organiserer dem i en rigtig pæn, meningsfuld mappestruktur.

mappestruktur til et nuxt-projekt

Del 3, går dybere

Det største problem var oprindeligt, hvordan man integrerer sass og bruger sass-variabler i mit projekt.
Jeg var nødt til at gøre denne troldkunst her for at have variabler tilgængelige i hver enkelt filkomponent (SFC) eller side

Dette blev derefter meget lettere takket være et Nuxt-modul, som simpelthen kan føjes til nuxt.config i en matrix med en liste over sassvariabler, der skal indlæses globalt.

Det næste trin var at finde ud af, hvordan man skulle styre staten.

Af en eller anden grund var jeg selvom en global mixin en god idé

Realiteten er, at når du har et par komponenter, måske en navigationslinje eller nogle modaler, er det allerede tid til at indlæse Vuex.

At gøre det i Nuxt er så let som:

index.js inde i / gemmappe med nogle eksempler på mutationer og nuxtServerInit

Nuxt giver også en måde at indlæse enhver meningsfuld tilstand på forhånd ved at bruge NuxtServerInit-handling i butikken.
Dette giver dig mulighed for at hente alt hvad du har brug for uden brug af monteret til at indlæse det (og miste på SSR på den måde).

Der er andre metoder, der kan bruges uden for butikken, som er asyncData (der indlæser data i komponenten) og henter (der begår mutationer eller sender handlinger).

Disse kan bruges, hvis du kun har brug for noget lokalt inden for en komponent eller side.

asyncData returnerer en ny dataegenskab på den lokale .vue-sidevi kan overføre nye data fra en API til butikken med hent

En ting at indse her er, at vi har at gøre med to tilfælde.
En på serveren, virtuel og ikke synlig, og en på klientsiden.

Dette betyder, at der er nogle gotchas, når du udvikler med Nuxt og enhver serversidesapp, men Nuxt gør disse gotchas meget begrænsede og enkle at overvinde.

Nuxt har bundtet sig i en -komponent, som kan pakke alt andet, inklusive andre komponenter, så længe du har et enkelt rodelement inde i det.

no-ssr kører kun den vedlagte kode på klientsiden (ingen SSR)

Dette plugin tillader, hvad der er indeni, kun at leve på klientsiden, og er især nyttigt, når man beskæftiger sig med tredjeparts-plugins, der muligvis indeholder henvisninger til vindue- eller DOM-elementer og ikke er nødvendige på serversiden.

Hvis du ikke gør dette eller noget andet, jeg viser nu, kan du støde på en anden træstruktur, som Nuxt vil give dig besked om:

Den anden gotcha er, hvordan biblioteker og komponenter indlæses i Nuxt.
Vi indlæser dem ved at oprette plugins i plugin-mappen og vedhæfte enten Vue.use, Vue.component eller Vue.directive med det.

Det andet trin her er at tilføje det plugin til nuxt.config, og her kan vi specificere, om det er et ssr-klar plugin (bare ved at skrive stien til plugin) eller ikke, ved at specificere ssr: false der.

Del 4: håndtering af WordPress CMS og API-opkald

Når hovedprojektet er konfigureret og du begynder at behandle hver side, er den hurtigste og bedste fremgangsmåde efter min mening at tilføje et plugin kaldet:
Avancerede brugerdefinerede felter (ACF)
til WordPress backend.

Dette tilføjer brugerdefineret feltfunktionalitet til sider og indlæg i WordPress.
For at udvide dette til REST API skal du også bruge et plugin kaldet
API til ACF til REST

Nogle nyttige addons:
WP REST API-filterfelter
filterfelter Gør det muligt at filtrere felterne returneret af api.

WP REST API Pure Taxonomies
Dette plugin inkluderer alle tilgængelige taksonomiattributter i WordPress REST API (v2) uden yderligere API-anmodninger.

WP REST API-cache
Aktivér cache til WordPress REST API og øg din applikations hastighed. (Jeg opfordrer ikke til at bruge dette plugin)
Advarsel her:
Hvis du laver indlægsanmodninger (eksempelvis kontaktformular-7-plugin), skal du sørge for at du ikke bruger dette plugin, eller hvis du gør det, skal du filtrere strengen 'kontaktformularer' i funktioner.php som nedenfor:

add_filter ('rest_cache_skip', funktion ($ spring, $ request_uri) {
  if (! $ springe && falske! == stripos ($ request_uri, 'contact-form-7')) {
    vende tilbage sandt;
  }
  returner $ spring;
}, 10, 2);

WP REST API-menuer
Udvider WP API med WordPress menueruter.

Det næste trin var derefter at konfigurere API-slutpunkterne.
Jeg har personligt brugt en config.js-fil, som jeg kan importere sådan:

import Config fra ‘~ / asset / config’;

Dette gør det muligt for mig at have en klar og konfigureret slutpunktplacering for alle mine sider.

Ovenstående er delvist hentet fra en luksus rejseoperatør, Antilophia.
Webstedet er ikke live endnu, men jeg vil opdatere her, når det er. Bliv hængende ;)

Når du har ovenstående konfigurering, kan du konfigurere appen til at hente data enten på nuxtServerInit eller med fetch / asyncData.

Dermed kan du derefter udfylde hver sektion af webstedet ved hjælp af de avancerede brugerdefinerede felter plus resten af ​​de tilgængelige WordPress API-felter (hvad som helst).

Serveren opdaterer indholdet, hver gang den indlæser en session for en bruger.

Du kan oprette dynamiske sider ved hjælp af mappestrukturen:
Hvor er navnet på den ønskede parameter (f.eks .: destination)

Dette giver dig adgang til parameteren ved hjælp af:

dette. $ route.params. 

For eksempel ville /pages/:mexico/index.vue vende tilbage

dette. $ route.params.destination === 'mexico'

Husk i asyncData eller hent, har du ikke adgang til 'dette', som det kører før du monterer siden, men du kan få adgang til 'kontekst'.

async hente ({app, store, params}) {
  // dette giver dig adgang til at rute params med stenografi params
  // men også til butikken og de andre appværdier
  // Kontroller alle felter på https://nuxtjs.org/api/context/
}

Hvis du har en masse API-opkald, kan jeg foreslå to muligheder:
- Brug en WP REST API Cache-plugin som WP REST API Cache
- Cache nuxtServerInit opkald (foretrukket)

For sidstnævnte er det en smule vanskeligt og kræver, at du bruger lre-cache-mekanismer og axios-extensions-pakker.
En essens med alle filerne er linket nedenfor.

Link: https://gist.github.com/bovas85/8b5610ac94dd036628f53f702b300a64

vuex butiktilføj denne udvidelse til axios og tilføj plugin axios.js til nuxt.config.js

Dette er især nyttigt, hvis du genererer et statisk sted (nuxt-generering), da nuxtServerInit vil køre en gang pr. Genereret side (forestil dig, hvis du har 20 dynamiske sider, så kører det 20 * antal api-opkald).

Del 5: Hvad med installationen af ​​appen?

Vi prøvede to ruter med dette.
1) Vi brugte et nuxt genereret statisk sted, der serveres med en almindelig server (old school måde). Hurtig, men ulempen er, at hvis du har masser af dynamiske sider, er gengivelsen af ​​de dynamiske ruter en smule vanskelig og langsom (se her, hvordan du gør det);
2) Vi brugte en nodeJS-hostet service som Now (der er flere, eller endda bare bruge din hosting, hvis den understøtter NodeJS, vores gjorde det ikke).

Jeg skrev en artikel om en bestemt gotcha, når jeg migrerede et domæne til Now fra GoDaddy, du kan læse det her:

“Distribution af din SSR-app til Zeit Now fra GoDaddy” @MoustacheDsign https://medium.com/@moustachedesign/deploying-your-ssr-app-to-zeit-now-from-godaddy-41b51302375f

Med det nu, efter at du har installeret cli, skriver du bare nu, og det distribuerer dit SSR-sted på få sekunder (bogstaveligt, afhængigt af din forbindelse og hvor stort webstedet er;))

Resultatet er et meget lille, optimeret og asynk bundt. Der er automatisk fragmentering af sider for sider ud af kassen, så du behøver ikke at bekymre dig om de vanskelige stykker ikke mere.

ikke dårligt

Del 6: Hvad er det næste for Vue og Nuxt?

Vue og Nuxt er ikke længere nye, der er et stort økosystem af plugins, moduler og biblioteker, der er tilgængelige og vil blive større og større.

Nogle af dem, jeg brugte, inkluderer plugins til glider, karruseller, ladet billedeindlæsning, og det meste af tiden kan inkluderes, selvom ikke er hjemmehørende i Nuxt eller endda Vuejs.

Nuxt.js er en OpenCollective og selvfinansieret.
Hvis du elsker dette som jeg, kan du overveje at donere på https://opencollective.com/nuxtjs

Send spørgsmål til Nuxt her (det integreres med Github-emner, ganske pænt!):
https://nuxtjs.cmty.io

Det er en indpakning

Har du nogen spørgsmål?
I så fald er du velkommen til at kommentere nedenunder, eller tweet mig @moustacheDsign

Nogle steder har jeg lavet efter denne tilgang:

Hvis du har spørgsmål, svar her eller tweet mig @moustacheDsign

Tak fra katten