Laravel - components 4

Poznajemy lepiej komponenty Laravela oraz zastanawiamy się, czy aby na pewno chcemy ich używać. Do dzieła.

Ok, pierwsza rzecz, której nie znamy – metoda shouldRender:

public function shouldRender(): bool
{
    return Str::length($this->message) > 0;
}

Druga rzecz to znak :: zamiast : i nie jest to scope resolution operator – tylko sposób, aby komponenty Laravela nie gryzły się z frameworkami frontendowymi, które tej samej notacji (:[atrybut]) używają:

<x-button ::class="{ danger: isDeleting }">
    Submit
</x-button>

Mamy też sloty:

<div class="alert alert-danger">
    {{ $slot }}
</div>

Nazwane sloty:

<x-alert>
    <x-slot:title>
        Server Error
    </x-slot>
 
    <strong>Whoops!</strong> Something went wrong!
</x-alert>

Atrybuty:

@props([
    'heading',
    'footer',
])
 
<div {{ $attributes->class(['border']) }}>
    <h1 {{ $heading->attributes->class(['text-lg']) }}>
        {{ $heading }}
    </h1>
 
    {{ $slot }}
 
    <footer {{ $footer->attributes->class(['text-gray-700']) }}>
        {{ $footer }}
    </footer>
</div>

Nested components:

<x-menu color="purple">
    <x-menu.item>...</x-menu.item>
    <x-menu.item>...</x-menu.item>
</x-menu>

Wtedy props może służyć nie tylko do ominięcia klasy (komponenty utworzone z flagą –view) ale także do przekazywania atrybutów w dół:

@props(['color' => 'gray'])
 
<ul {{ $attributes->merge(['class' => 'bg-'.$color.'-200']) }}>
    {{ $slot }}
</ul>

Komponent-odbiorca musi potwierdzić, że jest świadomy tego, co może do niego spłynąć:

@aware(['color' => 'gray'])
 
<li {{ $attributes->merge(['class' => 'text-'.$color.'-800']) }}>
    {{ $slot }}
</li>

Natomiast zanim się zaczniemy podniecać, musimy zrozumieć pewne rzeczy:

Laravel jest frameworkiem backendowym
Komponenty to iście frontendowa rzecz
Większość frameworków frontendowych zapewnia komponenty

To wszystko oznacza, że po pierwsze, pewne rzeczy mogą nam źle działać. Komponenty nigdy nie były główną osią Laravela, ani nawet czymś o znaczeniu drugorzędnym, ale jednak ważnym. I jeżeli do dzisiaj są rozkminy jak dodać x-forwarded-by czy jakiś inny custom header do projektu Laravela, to możemy być pewni, że będą błędy w komponentach.

Nie będzie działać jak należy, będzie wymagało jakichś dodatkowych czarów (oby tylko to), które w dodatku nie są nigdzie udokumentowane i tylko niewielka grupka ludzi, którzy się tym zajmują to umie robić dobrze i dla nich jest to oczywiste.

Komponenty jako coś pobocznego i niszowego w Laravelu będą słabo udokumentowane zaś błędy będą wykrywane późno i późno naprawiane. Z obsługą komponentów będą sobie radzić ludzie, którzy poświęcili im trochę czasu.

Są też pewne ograniczenia Laravela jako frameworka backendowego w stosunku do tego co może zapewnić komponentom, oraz Laravela jako frameworka, którego Blade components jest jakimś tam niszowym elementem.

To sprawia, że wszystko, co będziemy robić przy pomocy komponentów + AlpineJS będzie od nas wymagało kreatywności. Jeżeli dotychczas robiliśmy w bardzo dobrze znanych i opisanych frameworkach, to możemy nawet nie zdawać sobie sprawy z tego, jak bardzo jesteśmy słabi gdy musimy sami coś wymyślić.

Mamy do dyspozycji i komponenty i AlpineJS i sami musimy wpaść na to jak to kreatywnie pospinać, aby wyszła działająca całość. Dodaj do tego słabą dokumentację, słabe przykłady i potencjalne błędy, późno wykrywane i wolno naprawiane i wychodzi na to, że to wcale nie jest droga na skróty.

Mało tego, jeżeli jesteśmy z tych, co to ich programować sztuczna inteligencja uczyła, to tym bardziej model językowy nam nie pomoże. Model językowy zna się na tym, co właśnie dobrze znane, dobrze opisane i ma milion przykładów. WordPressa klasycznego może nas uczyć, przy tym z Reactem się gubi i kluczy, można sobie wyobrazić, jak bardzo „mądre” będą jego rady i przykłady, gdy będzie musiał wziąć mało znaną paczkę Alpine, niszową funkcjonalność Laravela Blade Components, pomyśleć (skrót myślowy) i jakoś mądrze to pospinać.

Dlatego może warto rozważyć inny kierunek – backend w PHP, frontend w JS. Inertia spina wszystko. Plus operujemy w dwóch dobrze udokumentowanych językach, znanych i lubianych, z frameworkami dobrze opisanymi i wspieranymi, wyznaczającymi wręcz pewne standardy.

Moje zdanie jest takie, że trzeba umieć wszystko, ale należy mieć jakieś preferencje. I osobiście tak jak backend wolę zostawić PHPowi o tyle reaktywność to domena JSa i frameworków frontendowych.

A jak będę chciał napisać Apkę na androida, do się polubię z Javą i Android Studio, a jak GUI, to C#. I pal 6, że moim pierwszym językiem był Python, robienie tych rzeczy w Pythonie jest właśnie jak robienie reaktywności przez Blade Components + Alpine (Alpine sam w sobie jest świetną paczką).

Po prostu dobiera się odpowiednie narzędzia do zadania, zaś nauczenie się nowego języka wcale nie jest takie trudne, jeżeli znamy koszty i ograniczenia pozostania w tym, co niby znamy, ale do zadania się średnio nadaje, albo wręcz nie nadaje.

Decyzję pozostawiam czytelnikowi.

Laravel – components 4