LWC w Salesforce: budowa komponentów, @wire i eventy

Salesforce udostępniło Lightning Web Components w 2019 roku z oficjalną rekomendacją: zawsze wybieraj LWC, chyba że potrzebujesz funkcjonalności, której LWC jeszcze nie obsługuje (oficjalna dokumentacja Salesforce Developer). Decyzja ta oznacza, że Aura – wcześniejszy framework UI Salesforce – nie jest już preferowanym wyborem dla nowych komponentów. LWC jest zbudowany na natywnych standardach webowych (HTML5, JavaScript ES6+, CSS, Web Components), co oznacza mniejszy narzut frameworkowy, lepszą wydajność i łatwiejsze przejście dla deweloperów znających nowoczesny web. Jeśli nadal piszesz Aurę lub zaczynasz z UI Salesforce, poniżej masz to, co musisz wiedzieć.

Dlaczego LWC zamiast Aury i co to zmienia w praktyce

Aura Components to Salesforce-specyficzny framework z własnym modelem zdarzeń, własnymi lifecycle hooks (init, render, afterRender) i oddzielnym plikiem JavaScript od HTML. Działa, ale wymaga nauki Aura-specyficznych abstrakcji – developer z zewnątrz ekosystemu Salesforce musi najpierw nauczyć się, jak Aura myśli, zanim napisze cokolwiek sensownego.

LWC eliminuje tę warstwę abstrakcji. Komponent LWC to standardowy plik HTML z templatem, plik JavaScript z klasą ES6, opcjonalny CSS. Lifecycle hooks jak connectedCallback, disconnectedCallback i renderedCallback to Web Components API – ten sam standard, który istnieje w React, Vue i innych frameworkach. Developer z backgroundem webowym rozumie LWC w kilka godzin, zamiast kilku dni z Aurą.

Wydajność: LWC jest szybszy ponieważ korzysta z natywnych możliwości przeglądarki bez dodatkowej warstwy abstrakcji Aura. Shadow DOM zapewnia izolację CSS i JavaScript między komponentami – style zdefiniowane w jednym komponencie nie wpływają na inne, co eliminuje klasyczny problem kaskadowych efektów ubocznych CSS.

Ważne ograniczenie koegzystencji: komponent Aura może zawierać komponent LWC. Komponent LWC nie może zawierać komponentu Aura – tylko inne LWC. Przy migracji istniejących Aura Components to istotna reguła: możesz stopniowo zastępować Aurę od liści drzewa komponentów.

Struktura komponentu LWC: co jest w folderze

Każdy komponent LWC to folder z plikami o tej samej nazwie co folder. Trzy podstawowe pliki:

myComponent.html – template z dyrektywą <template>. Tutaj HTML, warunkowe renderowanie (if:true lub nowsze lwc:if), iteracje (for:each), sloty dla treści zagnieżdżonej i powiązania z danymi przez wyrażenia {propertyName}.

myComponent.js – klasa JavaScript eksportowana jako default. Dziedziczy po LightningElement. Tutaj właściwości, metody, lifecycle hooks i logika. Trzy kluczowe dekoratory:

@api oznacza właściwości publiczne – dostępne z zewnątrz komponentu (komunikacja parent → child). Rodzic może ustawić wartość @api property dziecka przez atrybut HTML lub programatycznie. Właściwości @api są reaktywne: zmiana z zewnątrz automatycznie aktualizuje widok komponentu.

@track był w starszych wersjach LWC konieczny do reaktywności prywatnych właściwości. Od Spring ’20 wszystkie właściwości klasy są domyślnie reaktywne – @track jest potrzebny tylko dla głębokiej obserwacji zmian wewnątrz obiektów lub tablic. W nowym kodzie rzadko go zobaczysz.

@wire to deklaratywny dostęp do danych – najważniejszy dekorator do zrozumienia. Wire service automatycznie pobiera dane (Salesforce records, listy rekordów, wyniki metod Apex) i cache’uje je. Gdy dane na serwerze się zmienią, cache jest automatycznie unieważniany.

myComponent.css – opcjonalny plik stylów. Obowiązuje Shadow DOM: style zdefiniowane tutaj działają tylko wewnątrz komponentu, nie wyciekają na zewnątrz.

Czwarty opcjonalny plik: myComponent.js-meta.xml – metadata Salesforce definiująca gdzie komponent można używać (Lightning Page, App Page, komunity, email templates itp.).

Wire service: jak LWC pobiera dane z Salesforce

Wire service to most między komponentem LWC a danymi Salesforce. Działasz deklaratywnie: opisujesz co chcesz, wire service pobiera i odświeża automatycznie. Dwa główne przypadki użycia:

Wire adapters z Lightning Data Service (LDS): @wire(getRecord, { recordId: '$recordId', fields: ACCOUNT_FIELDS }) pobiera rekord Salesforce korzystając z LDS. LDS ma wbudowany cache: jeśli te same dane pobrał inny komponent na tej samej stronie, wire service nie robi kolejnego zapytania do serwera. Cache jest dzielony między LWC i Aura Components na tym samym cyklu renderowania.

Wire z metodą Apex: @wire(apexMethodName, { param: '$someProperty' }) – wire service woła metodę Apex oznaczoną jako @AuraEnabled(cacheable=true). Metoda musi być cacheable – bez tej adnotacji wire nie zadziała. Znak $ przed nazwą właściwości oznacza że parametr jest reaktywny: zmiana wartości someProperty automatycznie wywołuje ponowne zapytanie.

Wire service zwraca obiekt z dwoma właściwościami: data i error. Dobrą praktyką jest obsługiwanie obu w template – warunkowe renderowanie dla danych i osobna sekcja błędu. Wire service jest asynchroniczny – template będzie renderowany ze undefined dopóki dane nie przyjdą z serwera.

Komunikacja między komponentami: eventy i Lightning Message Service

LWC używa standardowych DOM events (CustomEvent) zamiast Aura-specyficznych Application Events. Trzy wzorce komunikacji:

Parent → child: rodzic przekazuje dane przez właściwości @api lub woła metody publiczne (oznaczone @api) dziecka przez querySelector. Bezpośrednie, proste, nie wymaga eventów.

Child → parent: dziecko dispatchuje CustomEvent, rodzic nasłuchuje w template przez oneventname. Standardowy DOM event propaguje w górę drzewa. Przykład: this.dispatchEvent(new CustomEvent('recordsaved', { detail: { recordId: this.recordId } })).

Komunikacja bez relacji rodzic-dziecko: komponenty na tej samej stronie, które nie są ze sobą bezpośrednio powiązane w hierarchii, komunikują się przez Lightning Message Service (LMS). LMS zastąpił starszy wzorzec PubSub i jest oficjalnym rozwiązaniem dla komunikacji między-komponentowej. Działa też między LWC i Aura na tej samej stronie – jeden z rzadkich mechanizmów, gdzie te dwa frameworki komunikują się bezpośrednio.

Migracja z Aura do LWC nie jest konwersją linia-po-linii, ale Salesforce dostarcza szczegółowy migration guide w developer docs. Dla teamów z dużą bazą Aury rekomendowaną strategią jest migracja stopniowa – nowe komponenty piszesz w LWC, istniejące Aura opakujesz w cienką warstwę LWC gdy potrzebujesz z nimi współpracować. Jak AI wpływa na to, które umiejętności developerów Salesforce są dziś kluczowe, piszemy w artykule o rozmywaniu specjalizacji w erze AI. LWC, Apex i architektura danych są wśród obszarów, na których egzamin PD1 skupia się najsilniej – szczegółowy podział tematyczny PD1 znajdziesz w osobnym artykule.

LWC jest dziś standardem UI Salesforce i tę pozycję będzie utrzymywać – Salesforce inwestuje w nowe funkcje wyłącznie dla tego frameworka. Aura działa i będzie działać, ale nie dostaje nowych możliwości. Które wzorce komunikacji między komponentami sprawiają Ci największy problem w praktyce?