La darrera lliçó del mòdul anterior es tancava amb una promesa: amb TaskFlow funcionalment complet —<task-board> com a orquestrador i proveïdor de context, <task-list> filtrant i renderitzant amb repeat, <task-card> amb les seves insígnies, el seu avatar i la seva urgència calculada, i <task-filter> llegint i escrivint el context compartit—, toca veure com aquesta mateixa aplicació s'integra amb la resta del món: HTML pla, altres frameworks, renderitzat al servidor i empaquetatge. Aquesta lliçó comença pel cas més senzill de tots, i precisament per això el més revelador: utilitzar un component Lit dins d'una pàgina HTML corrent, sense cap projecte Vite al darrere, sense cap pas de compilació, sense cap framework d'aplicació. Si alguna cosa d'això sorprèn, és el senyal de que convé repassar per què és possible abans de veure com es fa.

1. Per què un component Lit funciona en qualsevol HTML
2. Carregar Lit i un component sense cap pas de compilació
3. <script type="module"> des d'un CDN: unpkg i esm.sh
4. La limitació dels atributs: per què no n'hi ha prou d'escriure tareas="..."
5. Establint propietats complexes des de JavaScript pur
6. Exemple complet: <task-card> en una pàgina HTML estàtica
7. Quan encara fa falta un projecte amb build

La lliçó 01-01 ja va avançar la idea, sense desenvolupar-la encara: un component Lit, un cop definit amb customElements.define(...), és un Custom Element estàndard, exactament el mateix tipus d'objecte que <video> o <details>. Lit no inventa un mecanisme propi de registre de components ni exigeix cap entorn d'execució especial perquè un element personalitzat funcioni; es basa, en tot moment, en l'API customElements que qualsevol navegador modern implementa de forma nativa. La conseqüència pràctica és tan directa com sorprenent per a qui ve d'un framework d'aplicació: qualsevol pàgina HTML que carregui el codi JavaScript d'un component Lit pot utilitzar l'etiqueta d'aquest component, sense necessitat de React, sense necessitat de Vue, sense necessitat de cap compilador ni empaquetador.

Això no és una casualitat de disseny, sinó l'objectiu explícit de Lit des de la primera lliçó d'aquest curs: produir components que siguin, per damunt de tot, estàndards de la plataforma web, i que la capa de conveniència que Lit hi afegeix per sobre (plantilles reactives, actualitzacions eficients, static properties) desaparegui en temps d'execució, deixant només el Custom Element resultant. Tot el projecte Vite utilitzat durant el curs fins ara ha estat una comoditat per al desenvolupament —recàrrega en calent, resolució de mòduls, servidor local—, no un requisit del propi Lit per funcionar en un navegador.

El projecte Vite de TaskFlow, utilitzat en totes les lliçons anteriors, resol les importacions (import { LitElement, html, css } from 'lit') a través de node_modules, processant-les amb un empaquetador abans de servir-les al navegador. Una pàgina HTML plana, sense cap servidor de desenvolupament al darrere, no té aquest pas intermedi: el navegador necessita rebre directament una URL vàlida per a cada mòdul que importa. Els navegadors moderns ja saben executar mòduls ES natius amb <script type="module">, i ja saben resoldre importacions amb ruta relativa o absoluta, però no saben, per si mateixos, quin fitxer correspon al nom 'lit' sense més context; aquest és exactament el treball que fa un empaquetador amb node_modules, i que falta per complet en una pàgina sense build.

Hi ha dues formes de resoldre aquesta absència: apuntar directament a un CDN que serveixi Lit ja empaquetat amb una URL completa, o generar un bundle propi del component (incloent-hi Lit dins) amb les eines que es veuran a la lliçó 08-04. Aquesta lliçó se centra en la primera opció, la més immediata per a un cas d'ús puntual —una demo, una pàgina de documentació, un widget aïllat— que no justifica muntar un projecte complet de build.

Els dos CDN més habituals per consumir paquets npm directament com a mòduls ES, sense cap pas d'instal·lació local, són unpkg i esm.sh. Tots dos agafen un paquet publicat a npm (com lit) i el serveixen ja convertit en un mòdul ES que un navegador pot importar directament per URL:

Aquest fitxer, desat com index.html i obert directament en un navegador (o servit per qualsevol servidor HTTP mínim, inclòs el propi python -m http.server), renderitza <task-card> sense cap package.json, sense cap instal·lació de dependències i sense cap pas de compilació previ. El navegador descarrega https://esm.sh/lit@3 en el moment en què executa l'import, exactament com descarregaria qualsevol altre recurs extern, i a partir d'aquí LitElement, html i css estan disponibles per a la resta de l'script, igual que en el projecte Vite del curs.

La diferència pràctica entre unpkg i esm.sh és sobretot de format d'URL i d'opcions de resolució: esm.sh tendeix a generar mòduls ES més directament utilitzables sense paràmetres addicionals, mentre que unpkg serveix el contingut tal com està publicat al paquet npm, que a vegades requereix apuntar explícitament al fitxer del build ja en format de mòdul ES (per exemple, https://unpkg.com/lit@3/index.js?module). Per a un cas d'ús puntual, qualsevol dels dos compleix; l'important és fixar sempre una versió concreta (lit@3, no lit sense més), perquè la pàgina no canviï de comportament sense avís si el paquet publica una versió nova amb canvis incompatibles.

L'exemple de l'apartat anterior utilitza només atributs de tipus cadena o número (titulo, estado, prioridad), i per això funciona sense cap matís addicional: HTML és, per definició, un llenguatge d'atributs de text, i Lit converteix automàticament aquestes cadenes al tipus declarat a static properties (com es va explicar a la lliçó 03-03 sobre conversors de tipus). El problema apareix tan bon punt cal establir una propietat complexa —un array, un objecte— directament des del marcat HTML, cosa que TaskFlow necessita constantment: <task-list> rep un array complet de tasques a través de la seva propietat tareas.

Res no impedeix, tècnicament, escriure un atribut amb una cadena que contingui JSON serialitzat a mà, amb les cometes escapades com a entitats HTML ("), però és una solució fràgil i incòmoda de mantenir, i a més exigeix que el propi component s'encarregui d'invocar JSON.parse(...) sobre el valor de l'atribut abans de poder-lo utilitzar com un array real, un pas que cap dels components de TaskFlow implementa (tareas es declara { type: Array }, i el conversor per defecte de Lit per a Array no fa aquesta feina de deserialitzar JSON de forma automàtica i segura per a qualsevol estructura arbitrària). La limitació de fons és la mateixa que ja va aparèixer, des d'un altre angle, a la lliçó 03-04: els atributs HTML són sempre cadenes de text; les propietats de JavaScript poden ser qualsevol valor del llenguatge, inclosos objectes i arrays, però només són accessibles des de codi, no des del marcat HTML en si mateix.

La solució, exactament igual que dins del propi Lit, és establir la propietat directament en JavaScript, no com un atribut de marcat:

document.querySelector('#lista-principal') retorna la instància real de l'element <task-list> ja connectat al DOM, i lista.tareas = [...] assigna directament la propietat reactiva tareas, exactament el mateix mecanisme que dispara Lit quan una plantilla utilitza .tareas="${...}" amb el prefix de punt (vist per primera vegada a la lliçó 05-03). No hi ha cap diferència de fons entre assignar una propietat des d'una plantilla Lit dins d'un altre component i assignar-la directament des d'una línia de JavaScript solta en una pàgina HTML plana: en tots dos casos, Lit detecta el canvi de valor a través del mateix mecanisme de propietats reactives estudiat des del mòdul 3, i programa un nou renderitzat si correspon.

Aquest és, en definitiva, el criteri general per decidir entre atribut i propietat en integrar un component Lit en HTML pla: qualsevol valor que sigui de forma natural una cadena, un número o un booleà simple es pot escriure directament com a atribut al marcat; qualsevol valor que sigui un objecte, un array, una funció o qualsevol estructura que no tingui una representació textual raonable necessita assignar-se com a propietat des de JavaScript, després d'obtenir una referència a l'element amb document.querySelector o equivalent.

Unint les dues tècniques anteriors, així es veuria una pàgina HTML completament estàtica, sense cap projecte Vite ni pas de build, mostrant una única <task-card> de TaskFlow amb dades mixtes —unes com a atributs, una altra (una funció de callback) com a propietat assignada des de JavaScript—:

./task-card.js és aquí un fitxer propi del projecte (no un component de tercers), que defineix <task-card> exactament com s'ha construït al llarg del curs, amb l'única diferència que les seves pròpies importacions de lit també s'han de resoldre contra una URL de CDN si el fitxer se serveix tal com és, sense cap pas de build previ (cosa que la lliçó 08-04 explicarà com evitar, generant en el seu lloc un bundle autocontingut). L'import 'https://esm.sh/lit@3'; solt, sense capturar cap valor, no és necessari si task-card.js ja importa Lit pel seu compte des de la mateixa URL; s'inclou aquí només per deixar explícita la dependència en l'exemple.

Res del que precedeix invalida el projecte Vite utilitzat durant la resta del curs: per a un desenvolupament seriós de TaskFlow, amb diversos components que s'importen entre si, amb recàrrega en calent durant el desenvolupament, amb comprovació de tipus (si s'opta per TypeScript, com es veurà a la lliçó 08-04) i amb un procés de construcció que optimitzi el resultat final, un projecte amb build continua sent l'opció correcta. El cas d'aquesta lliçó —HTML pla carregant components des d'un CDN— té el seu lloc en escenaris més acotats: una demo ràpida, una pàgina de documentació que mostra un component aïllat, un widget que un tercer ha de poder incrustar en la seva pròpia web sense dependre de la cadena de build de TaskFlow, o simplement una forma de comprovar que un component exportat funciona igual de bé fora del projecte que el va originar. Reconèixer en quin escenari s'està, en cada cas, evita tant muntar un projecte de build innecessari per a una demo puntual com intentar mantenir una aplicació complexa sencera a base de <script type="module"> solts sense cap eina de per mig.

• Intentar passar un array o un objecte com a atribut de text: com s'ha explicat a l'apartat 4, els atributs HTML són sempre cadenes; una propietat complexa s'ha d'assignar des de JavaScript (elemento.propiedad = valor), mai escriure-la serialitzada a mà dins d'un atribut, tret que el propi component implementi explícitament aquesta deserialització.
• Oblidar fixar una versió concreta en importar des d'un CDN: escriure https://esm.sh/lit sense cap versió pot servir, en un moment donat, una versió diferent de la que es va provar, amb canvis de comportament inesperats; fixar sempre lit@3 (o la versió exacta que correspongui) evita aquest risc.
• Intentar accedir a la propietat abans que l'element estigui definit: si l'script que assigna elemento.tareas = [...] s'executa abans que customElements.define('task-list', TaskList) hagi corregut (per exemple, per un ordre de scripts incorrecte), l'assignació continua funcionant gràcies al mecanisme d'upgrade de Custom Elements (Lit recorda els valors assignats abans de la definició i els aplica tan bon punt l'element es registra), però convé no dependre d'aquest detall per a codi nou i mantenir sempre l'ordre lògic: definir el component abans de manipular les seves instàncies.
• Servir la pàgina amb file:// en lloc d'un servidor HTTP mínim: alguns navegadors restringeixen l'import de mòduls ES quan la pàgina s'obre directament des del sistema de fitxers, sense cap servidor al darrere; un servidor HTTP mínim com npx serve o python -m http.server resol aquest problema en segons i evita errors de CORS confusos.

1. Escriu una pàgina HTML plana, sense cap projecte Vite, que carregui Lit des de https://esm.sh/lit@3, defineixi un component <contador-simple> amb una propietat d'estat valor (inicialitzada a 0) i un botó que la incrementi a cada clic, i la mostri a la seva plantilla.
2. Un company d'equip, integrant <task-list> en una pàgina HTML plana, escriu <task-list tareas="3"></task-list> esperant mostrar tres tasques, i es sorprèn que no funcioni. Explica, basant-te en l'apartat 4, per què aquesta expressió no aconsegueix l'efecte esperat i què caldria escriure en el seu lloc.
3. Retorna a l'exemple de l'apartat 6 i modifica l'script perquè, en lloc d'assignar asignadoImagen de forma síncrona, l'assigni després d'una crida a fetch(...) que tarda un temps a resoldre's. Continua funcionant el mecanisme de propietats reactives de Lit igual de bé en aquest cas? Raona la teva resposta basant-te en el que s'ha estudiat sobre el cicle de renderitzat a la lliçó 02-05.

2. tareas="3" estableix un atribut de text amb el valor "3", no una propietat amb un array de tres elements; com s'ha explicat a l'apartat 4, HTML no té cap sintaxi per expressar directament "un array amb tres tasques" dins d'un atribut, i el conversor de tipus Array de Lit no interpreta "3" com una instrucció per generar tres tasques de cap tipus. Per aconseguir l'efecte esperat cal obtenir una referència a l'element des de JavaScript i assignar la propietat directament, com a l'apartat 5: document.querySelector('task-list').tareas = [tarea1, tarea2, tarea3].
3. Sí, continua funcionant exactament igual: el mecanisme de propietats reactives de Lit, estudiat des del mòdul 3, no depèn de que l'assignació passi de forma síncrona tot just carregar la pàgina; reacciona a qualsevol assignació a la propietat en qualsevol moment de la vida del component, ja estigui connectat des del principi o es connecti més endavant. Tan bon punt la promesa de fetch(...) es resolgui i l'script executi tarjeta.asignadoImagen = ..., Lit detecta el canvi de valor i programa un nou renderitzat pel mateix cicle asíncron per microtasca explicat a la lliçó 02-05, exactament com si aquesta mateixa assignació hagués passat dins d'un altre component Lit en lloc d'en un script solt d'una pàgina HTML plana.

Aquesta lliçó ha mostrat que un component Lit no necessita cap entorn especial per funcionar: en ser, en última instància, un Custom Element estàndard, n'hi ha prou de carregar el seu codi —des d'un CDN o des d'un fitxer propi— en qualsevol pàgina HTML per utilitzar-lo amb normalitat, amb l'únic matís que les propietats complexes (arrays, objectes) s'han d'assignar des de JavaScript, no escriure's com a atributs de marcat. Aquest és el cas més simple d'interoperabilitat, però no l'únic: la lliçó següent fa un pas més enllà i examina com s'integra un component Lit dins d'aplicacions construïdes amb altres frameworks —React, Vue i Angular—, cadascun amb el seu propi conjunt de friccions en tractar amb Custom Elements que els seus propis models de components no anticipen del tot.