Il framework Lightning Web Components

In un articolo di qualche giorno fa abbiamo introdotto Visualforce, il framework più “antico” per lo sviluppo di interfacce utente in Salesforce. Il secondo framework, più recente, è Lightning Web Components.

Lightning Web Components (abbreviato spesso in LWC) è stato introdotto nel 2019, e rappresenta un’evoluzione significativa verso gli standard web moderni. Questo framework sfrutta i Web Components nativi del browser, combinandoli con funzionalità specifiche di Salesforce.

LWC si basa infatti sugli standard web implementati direttamente nei browser moderni, anziché affidarsi esclusivamente a soluzioni proprietarie. I Web Components rappresentano un insieme di tecnologie che permettono di creare elementi HTML personalizzati con funzionalità incapsulate.

Incapsulamento vuol dire che i componenti possono “nascondere” al loro interno il proprio markup, stile e comportamento, mostrando all’esterno solo un’interfaccia ben definita.

Questi componenti nascondono quindi la complessità interna: il codice, la logica e l’implementazione dettagliata del componente rimangono isolati e inaccessibili dall’esterno.

Gli utenti del componente non hanno bisogno di conoscere come funziona internamente, ma solo come interagire con esso. I dati interni del componente sono accessibili solo attraverso metodi e proprietà esplicitamente definiti come pubblici, prevenendo modifiche accidentali o indesiderate da parte di codice esterno.

Il componente definisce esplicitamente quali proprietà, metodi ed eventi costituiscono la sua interfaccia pubblica, creando un contratto chiaro per l’interazione con il resto dell’applicazione (qui trovate il mio video sulle API).

Queste tecnologie includono ad esempio Custom Elements, Shadow DOM, HTML Templates. LWC estende queste funzionalità native aggiungendo strati specifici per Salesforce, ma la sua architettura fondamentale poggia su queste specifiche standardizzate, garantendo maggiore efficienza, prestazioni e compatibilità a lungo termine.

La forza di LWC è nella sua capacità di costruire interfacce utente modulari, riutilizzabili e performanti, particolarmente adatte all’esperienza Lightning Experience.

Quando si parla di “costruire interfacce utente modulari” vogliamo dire che suddivideremo l’interfaccia in tanti componenti indipendenti e riutilizzabili, anziché in pagine monolitiche. In pratica ogni componente LWC è una piccola unità autosufficiente, una specie di mattoncino Lego che comprende il proprio markup HTML, lo stile CSS e il suo comportamento JavaScript.

Questi componenti possono essere sviluppati, testati e mantenuti individualmente, semplificando la gestione di interfacce complesse. La modularità permette inoltre di combinare questi componenti come mattoncini per costruire applicazioni più elaborate, dove ogni pezzo ha responsabilità chiaramente definite.

Inoltre, se necessario, un componente può contenere altri componenti, creando una struttura gerarchica e nidificata che favorisce il riutilizzo e riduce la duplicazione del codice. Questo approccio modulare migliora non solo la manutenibilità del codice, ma anche l’efficienza dello sviluppo, poiché consente a team diversi di lavorare contemporaneamente su componenti distinti che poi verranno assemblati nell’interfaccia finale.

A differenza di Visualforce, LWC adotta un approccio “client-side”, dove gran parte dell’elaborazione avviene nel browser dell’utente. Come accennato, i nostri componenti saranno costituiti da più file: un file JavaScript, un file HTML, un file CSS, e (se vogliamo) dei file di configurazione XML per i metadati.

Per fare un esempio concreto possiamo pensare a un’applicazione per la gestione delle vendite in Salesforce, dove decidiamo di sviluppare componenti separati per la visualizzazione delle opportunità, la gestione dei contatti, la pianificazione delle attività e l’analisi delle performance.

Ognuno di questi componenti gestirà il proprio ciclo di vita (la sequenza di fasi che il componente attraversa dalla sua creazione alla sua rimozione) e i propri stati (i dati che un componente memorizza e gestisce internamente).

Potrà inoltre comunicare con gli altri componenti attraverso eventi o proprietà pubbliche. Ad esempio, un componente che visualizza i dettagli di un’opportunità potrebbe ricevere l’ID dell’opportunità che vogliamo visualizzare come proprietà pubblica dal suo genitore. Gli eventi, invece, facilitano la comunicazione dal figlio al genitore o tra componenti non direttamente correlati.

In LWC possiamo creare eventi personalizzati utilizzando la classe CustomEvent del browser, che può essere letta da altri componenti che sono in ascolto. Questo meccanismo di comunicazione disaccoppiata permette ai componenti di rimanere indipendenti, pur essendo in grado di coordinarsi e lavorare assieme quando necessario.

Questa architettura non solo semplifica lo sviluppo iniziale, ma facilita anche l’evoluzione dell’applicazione nel tempo, permettendo di aggiornare o sostituire singoli componenti senza dover riscrivere l’intero sistema.

Un esempio di componente LWC per il JavaScript potrebbe essere:

// opportunityEditor.js
import { LightningElement, api, wire } from 'lwc';
import { getRecord, updateRecord } from 'lightning/uiRecordApi';
import { ShowToastEvent } from 'lightning/platformShowToastEvent';

export default class OpportunityEditor extends LightningElement {
    @api recordId;
    @wire(getRecord, { recordId: '$recordId', fields: ['Opportunity.Name', 'Opportunity.CloseDate', 'Opportunity.Amount', 'Opportunity.StageName'] })
    opportunity;
    
    handleSubmit(event) {
        event.preventDefault();
        const fields = event.detail.fields;
        updateRecord({ fields: { ...fields, Id: this.recordId } })
            .then(() => {
                this.dispatchEvent(new ShowToastEvent({
                    title: 'Successo',
                    message: 'Opportunità aggiornata',
                    variant: 'success'
                }));
            })
            .catch(error => {
                // Gestione errori
            });
    }
}

Questo componente JavaScript rappresenta la logica di business di un editor di opportunità: recupera i dati dell’opportunità dal server, consente la modifica attraverso un form (definito nel file HTML correlato, che trovate qui sotto), gestisce il salvataggio delle modifiche e fornisce feedback all’utente sull’esito dell’operazione.

I cambiamenti ai dati vengono automaticamente riflessi nell’interfaccia utente e viceversa.

Questo invece potrebbe essere un esempio di HTML collegato al JavaScript:

<!-- opportunityEditor.html -->
<template>
    <lightning-card title="Modifica Opportunità" icon-name="standard:opportunity">
        <lightning-record-edit-form record-id={recordId} object-api-name="Opportunity" onsubmit={handleSubmit}>
            <lightning-messages></lightning-messages>
            <div class="slds-grid slds-gutters">
                <div class="slds-col">
                    <lightning-input-field field-name="Name"></lightning-input-field>
                    <lightning-input-field field-name="CloseDate"></lightning-input-field>
                </div>
                <div class="slds-col">
                    <lightning-input-field field-name="Amount"></lightning-input-field>
                    <lightning-input-field field-name="StageName"></lightning-input-field>
                </div>
            </div>
            <div class="slds-m-top_medium">
                <lightning-button label="Salva" type="submit" variant="brand"></lightning-button>
            </div>
        </lightning-record-edit-form>
    </lightning-card>
</template>

Questo esempio di template HTML crea un’interfaccia utente moderna e reattiva per modificare un’opportunità, utilizzando componenti predefiniti di Lightning che si integrano perfettamente con la piattaforma Salesforce. La separazione tra questo markup (HTML) e la logica (JavaScript) analizzata in precedenza riflette l’architettura modulare dei Lightning Web Components.

In un componente LWC completo, oltre ai file che abbiamo già analizzato:

• opportunityEditor.js (logica)
• opportunityEditor.html (markup)

Potrebbe esistere anche un file:

• opportunityEditor.css (stile)

Questo file CSS definirebbe le regole di stile specifiche per il componente. Un aspetto importante dell’architettura LWC è che gli stili definiti in questo file sono automaticamente incapsulati all’interno del componente grazie allo Shadow DOM, limitando la loro applicazione solo agli elementi interni del componente stesso. Questo previene conflitti di stile con altri componenti o con il CSS globale dell’applicazione.

Per esempio, un semplice file CSS per il nostro OpportunityEditor potrebbe essere:

.custom-heading {
    color: #1589ee;
    font-size: 16px;
}

.highlight-field {
    background-color: #f8f8f8;
    border-left: 3px solid #1589ee;
    padding-left: 8px;
}

.form-footer {
    border-top: 1px solid #dddbda;
    padding-top: 12px;
    margin-top: 16px;
}

Queste classi potrebbero poi essere utilizzate nel template HTML per personalizzare l’aspetto del componente oltre gli stili predefiniti del Lightning Design System.

Questa struttura a tre file (JS, HTML, CSS) per componente riflette completamente il concetto di incapsulamento e separazione delle responsabilità, rendendo ogni componente una unità autosufficiente che include i 3 elementi: comportamento, struttura e presentazione.

Vuoi lavorare meglio con Salesforce? Vuoi migliorare il tuo CV per trovare il lavoro che ti interessa?

Vedi il nostro corso online di Salesforce Administrator !

Formazione a distanza specializzata | Garanzia 100% soddisfatti o rimborsati | Oltre 1000 studenti