Wydzielanie komponentów i partiale

W miarę rozrastania się bazy kodu HTML te same fragmenty znaczników pojawiają się na wielu stronach — nagłówek witryny, stopka, nawigacja, karta produktu, pole formularza. Kopiowanie i wklejanie prowadzi do koszmaru związanego z utrzymaniem; zmiana stopki oznacza konieczność edycji każdej strony.

Większość języków szablonów po stronie serwera (Jinja, Liquid, ERB, EJS, Handlebars, Twig) obsługuje dyrektywy include: {% include "header.html" %} lub <%- include("header") %>. Proces budowania lub serwer wstawia partial do każdej strony, która go dołącza.

JSX/TSX (React), komponenty Vue SFC, komponenty Svelte i komponenty Astro wyrażają tę samą ideę za pomocą bardziej precyzyjnej semantyki: komponent hermetyzuje strukturę, style i zachowanie. Są kompilowane do HTML podczas budowania (SSG) albo w czasie działania (SSR/CSR).

Partial i komponenty należy grupować według przeznaczenia: partials/layout/ dla nagłówka, stopki i nawigacji, partials/blocks/ dla bloków hero, feature i CTA, a partials/forms/ dla pól, przycisków i list wyboru. Spójna organizacja ułatwia poruszanie się po bibliotece partiali w miarę jej rozrastania.

Partial stają się bardziej użyteczne, gdy przyjmują parametry: {% include "button.html" with label="Save", variant="primary" %}. Wewnątrz partiala należy odwoływać się do parametrów po nazwie. Ten sam szablon może renderować różne przyciski w całej witrynie.

W przypadku partiali opakowujących dowolną zawartość (karty, okna dialogowe) należy używać wzorców slotów: {% block content %}{% endblock %} w Jinja, {% block %} w Twig oraz właściwości {children} w JSX. Partial opakowujący dostarcza powłokę, a użytkownik dostarcza jej zawartość.

Generatory statycznych witryn (11ty, Astro, Hugo, Jekyll) rozwiązują dołączenia podczas budowania — wdrożony HTML nie zawiera składni szablonów. Dynamiczne szablony (PHP, Rails, Express+EJS) są przetwarzane w chwili żądania — zapewniają elastyczność, ale działają wolniej. Należy wybrać rozwiązanie zależnie od tego, czy zawartość musi być dynamiczna dla każdego żądania.

Partial powinny zawierać własny CSS. Partial stopki powinien korzystać z footer.css, a partial przycisku — z button.css. W połączeniu z etapem budowania, który łączy tylko CSS partiali faktycznie używanych na danej stronie, pozwala to uniknąć ładowania CSS wszystkich komponentów w każdym miejscu.

Każdy partial powinien dać się testować niezależnie: należy renderować go z różnymi danymi i sprawdzać wynik. Narzędzia takie jak testowanie komponentów w Cypress lub testowanie snapshotów w Jest można stosować także do partiali HTML. Przetestowane partiale można bezpiecznie zmieniać bez ręcznego sprawdzania każdej korzystającej z nich strony.

Partial jest interfejsem API. Zmiana nazw parametrów, konwencji slotów lub wymaganych właściwości powoduje niezgodność ze wszystkimi użytkownikami tego partiala. Należy udokumentować jego interfejs, stopniowo wycofywać starsze rozwiązania i przed refaktoryzacją użyć narzędzia wyszukiwania, aby znaleźć każde użycie.

Strony należy budować przez komponowanie partiali: partiala nagłówka + panelu bocznego + zawartości + stopki + analityki. Każdy partial jest niewielki i skupiony na jednym zadaniu, a sama strona staje się krótkim skryptem montującym, który łączy te elementy. Znacznie łatwiej ją zrozumieć niż jednoplikowy HTML liczący 800 wierszy.

Aby wyodrębnić partial: należy znaleźć powielone znaczniki na stronach, skopiować je do partials/X.html, zastąpić każde wystąpienie dyrektywą include i sparametryzować wartości różniące się u poszczególnych wywołujących. Należy robić to po jednym partialu — baza kodu będzie ulepszana stopniowo.

Jaka jest główna korzyść z wyodrębnienia powtarzającego się fragmentu HTML (takiego jak stopka witryny) do partiala?

Powtarzający się kod HTML należy wyodrębniać do partiali lub komponentów za pomocą dołączania po stronie serwera (Jinja, Twig, EJS) albo komponentów frameworków (React, Vue, Svelte, Astro). Dane należy przekazywać przez parametry, a elementy komponować za pomocą slotów. Partiale należy grupować według przeznaczenia, testować niezależnie i traktować ich sygnaturę jak interfejs API. Migrację należy przeprowadzać stopniowo — każde wyodrębnienie ogranicza powielanie i poprawia łatwość utrzymania.