Composers
View Composers, eller enbart Composers, kommer från ett system i Laravel med samma namn. Systemet tillåter en att att skicka med data till sina vyer (blade-mallar) och uträtta ett scope för vyn (och dess inkluderade under-vyer). Man kan göra detta med vilken mall som helst.
Tanken är att man ska hämta, bearbeta, skapa logik och i allmänhet göra datan redo för att visas i vyn. Detta gör att vy-filerna blir mer överskådliga och enklare att underhålla. Som tumregel kan man tänka att man aldrig vill skapa en ny variabel inuti en vy. Men det finns så klart undantag då man behöver göra det.
Konstruktion
Observera
Composers auto-laddas (autoload) och namngivningen måste därmed följa standarden PSR-4
Det går att skapa nya Composers med WP-CLI. Använd följande kommando:
wp dusk make:composer ExampleComposerDetta kommer att skapa en ny fil som heter ExampleComposer i app/View/Composers.
Om man inte använder WP-CLI så är det absolut minsta som krävs för att skapa en ny Composer följande:
// app/View/Composers/ExampleComposer.php
namespace App\View\Composers;
use Nobox\Dusk\View\Composer;
class ExampleComposer extends Composer
{}Just nu gör Composern inget. Här kommer lite grundläggande funktionalitet:
class ExampleComposer extends Composer
{
/**
* Det här berättar för Composern att den ska bindas till vyn `example` i mappen `partials`.
* Det går även att använda `*` för generella matchningar av vyer.
*/
protected static $views = [
'partials.example',
'partials.example-*',
];
/**
* Detta kommer skapa variabeln `$horizon` inuti den angivna vyn.
*/
public function with()
{
return [
'horizon' => 'Det bästa temat för WordPress!',
'example' => 'Some data',
];
}
/**
* Det här kommer att skriva över `horizon`-variabeln definierad ovan.
* Det gäller även för alla `horizon` som definierats i exempelvis `partials.*`.
*/
public function override()
{
return [
'horizon' => 'Ett totalt awesome tema för WordPress!'
]
}
}Variablerna som definierats i exemplet ovan kommer vara tillgängliga i filen partials/example.blade.php och exempelvis filen partials/example-1.blade.php. Variabeln kommer inte vara tillgänglig i exempelvis page.blade.php.
Datakällor
Datan som kan hämtas i vyerna kan komma från WordPress, men också från andra Composers.
Det går självklart även att göra manuella anrop mot databaser och API:er i Composern.
WordPress
Composern kommer köras i en kontext där exempelvis get_the_ID kommer fungera som förväntat och returnera id:et för sidan eller inlägget man är på.
Ärvd data
Data kan även komma från en annan Composer. Om vi utgår från exemplet ovan kan man göra följande:
class Example1 extends Composer
{
protected static $views = [
'example-one',
];
public function with()
{
return [
'edited_example' => str_replace(
'data',
'text',
$this->data->get('example'),
),
];
}
}Cache:a data
Composers kommer instantieras för varje view som matchas i $views. Detta betyder att ifall man gör ex. API anrop i en Composer kommer denna ske för varje view som matchar.
Ifall man gör tung bearbetning eller API anrop är det därför bra att cache:a den sortens data.
Det finns flera tillvägagångssätt att lösa problemet på, denna sida kommer beskriva dessa två sätt:
- Cache genom
wp_cache - Cache genom
staticfält
Cache genom wp_cache
wp_cache funktionsgruppen kan användas för att läsa och skriva till WordPress objekt cache.
Normalflödet är att man hämtar datan med wp_cache_get och kollar om datan är false. Om datan inte är false betyder det att datan är cache:ad. Om den är false betyder det att datan inte hittades i cache:n och behöver hämtas.
Observera
Detta innebär att det inte är idealt att spara false som värde.
När man har gjort klart datan sparar man det i cache:n med wp_cache_set.
Notera
Datan du sparar i databasen bör vara samma som du returnerar från metoden.
Ett grundligt exempel ser ut så här:
public function with()
{
return [
'apiData' => $this->fetchFromApi(),
];
}
protected function fetchFromApi()
{
$data = wp_cache_get('api-data', 'post-api');
if ($data === false) {
$result = /* någon långkörande bearbetning */;
$data = $result;
wp_cache_set('api-data', $data, 'post-api');
}
return $data;
}Tips
'post-api' är ett gruppnamn. Grupper kan användas för att använda samma nyckel mellan flera grupper.
Varning
Normalt sett håller wp_cache endast för nuvarande request, men kör sidan ex Object Cache (Redis) så kommer det sparas i Redis. Ifall användarspecifik data ska cache:as bör man använda ett gruppnamn som gör det unik, ex. genom att lägga till användar ID:t eller annan nyckel man kan derivera från nuvarande användare.
Cache genom static fält
Det går att spara ner datan som ett static fält. static fält ominstantieras inte, och kan därför användas för att lagra data.
Datan lagras endast under nuvarande request.
Ett grundligt exempel ser ut så här:
protected static $apiData = null;
public function with()
{
return [
'apiData' => $this->fetchFromApi(),
];
}
protected function fetchFromApi()
{
if (static::$apiData === null) {
$result = /* någon långkörande bearbetning */;
static::$apiData = $result;
}
return static::$apiData;
}$apiData skapas med null första gången och efter första körningen av fetchFromApi() kommer $apiData inte vara null längre.
Automatisk vy val
Om man vill binda en Composer till en enda vy kan man istället för att använda $views-variabeln utnyttja Horizons automatiska vy-väljare.
Om man exempelvis har vyn /resources/views/partials/page-header.blade.php och Composern /app/View/Composers/PageHeader.php kommer Composern automatiskt bli bunden till den vyn för att deras namn matchar.
Assets
Notera
Kräver Dusk 2.4.0 eller högre.
Om man vill ladda scripts och/eller styles som är specifika till vyerna som hanteras av en Composer kan man lägga till metoden assets.
Detta kommer endast köras en gång per Composer, dvs. assets kommer inte läggas till varje gång den instantieras. Ingen extra cache behövs för assets.
protected function assets(): void
{
asset('scripts/your-script.ts')->enqueue('your-script');
}