RO
Setări

Alege cum vrei să vezi acest website.

Limbă

Selectează limba preferată pentru acest website.

Componente Blade și partial-uri: unde tragi linia

Dezvoltare web și Laravel

Discuție · Ionel Nistor · 51 minute în urmă · 3 vizualizări

dezvoltare blade componente ui

Articol editorial, pregătit pentru bază de cunoștințe. Nu este o conversație simulată a comunității.

Blade accelerează livrarea HTML-ului, dar devine dificil când fiecare view conține ramificații de permisiuni și formatare duplicată. Componentele anonime sau class-based encapsulează markup repetitiv; discuția explică când un `@include` simplu e suficient și când merită un component cu contract clar de props. Obiectivul e să poți schimba un card de post sau un câmp de formular într-un singur loc fără căutare globală în zeci de fișiere.

Props validate versus array-uri opace



Componentele class-based pot declara proprietăți publice care devin variabile în view; IDE-ul le vede mai ușor decât un array `$attributes` nestructurat. Default-uri pentru props opționale evită `isset` în fiecare template. Pentru elemente de formular, transmite erorile de validare ca prop dedicat, nu citești direct `$errors` adânc în ierarhie — testarea devine mai clară. Atributele HTML neprevăzute (class suplimentar pe buton) se propagă cu `$attributes->merge()` ca să păstrezi flexibilitatea fără a sparge contractul componentei.

Sloturi named și compoziție



Layout-ul principal expune sloturi pentru titlu, conținut și acțiuni secundare; paginile copil umplu doar ce e specific. Evită sloturi prea multe — semn că layout-ul face prea multe. `@stack("scripts")` permite paginilor să adauge JS fără a modifica layout-ul global; documentează ordinea încărcării ca dependențele să nu se inverseze. Layout-uri alternative (print, embed minimal) pot moșteni același set de componente de bază, schimbând doar scheletul.

Logică minimă în template



`@if(auth()->check())` ocazional e acceptabil; totuși liste filtrate complex ar trebui pregătite în view model sau controler. Formatarea datelor (`diffForHumans`, numere) poate sta în accessor Eloquent sau helper dedicat, nu în trei locuri Blade diferite. `@once` previne duplicarea scripturilor când același component apare de mai multe ori pe pagină. Directive custom scurte pot extrage markup repetitiv, dar nu ascund calcule grele — păstrează-le ca presentere, nu ca strat de business.

Accesibilitate și markup consistent



Butoanele destructive ar trebui să aibă același pattern vizual și textual în componenta shared. Etichetele `for`/`id` leagă label de input; componentele de câmp ar trebui să genereze perechea corect automat. Nu elimina focus outline fără înlocuitor vizibil — e o decizie de CSS global, nu per pagină ascunsă. Stările de eroare și succes comunicate vizual trebuie duplicate și textual pentru cititori de ecran, nu doar prin culoare roșie sau verde.

Autentifică-te ca să scrii

Discuții din aceeași categorie