DEV Community: Julio Castillo Anselmi

Redacta: Elevating Video Content with GitHub Copilot CLI

Julio Castillo Anselmi — Sun, 15 Feb 2026 23:11:05 +0000

What I Built

Redacta is a personal solution born from a specific need: the desire to reclaim knowledge trapped in audio and video formats.

As someone with a strong visual memory, I’ve always found reading to be far more effective than watching a video or listening to a podcast. Phrases and images stick better in my mind when I can see them on a page. I can scan text to find concepts, refresh my memory on specific sections, or quickly identify the core message of a paragraph.

However, the world is full of incredible content delivered via video and audio. Unfortunately, I often feel I'm not getting the most out of it because it’s not written down. Searching within a video is a pain, and finding that one specific episode of a podcast I want to revisit is nearly impossible.

I tried reading raw transcriptions, but they are often unreadable—especially YouTube’s auto-generated captions, which lack punctuation, formatting, and proper structure.

Redacta was built to solve this. It takes a raw transcription and, using the power of GitHub Copilot and LLMs, transforms it into a well-redacted, properly punctuated document that remains strictly faithful to the original content.

Since its inception, I’ve expanded Redacta to:

Illustrate the text: Automatically adding images and schematics to aid visual learning.
Generate Summaries and Posts: Creating different formats tailored for quick reading or deep study.
Break Language Barriers: Translating content into other languages, allowing me to access knowledge originally shared in languages I don't speak fluently.
Redacta isn't just a tool; it's a bridge between the vast world of video/audio content and the way my brain actually processes knowledge.

Core Capabilities

Semantic Redaction: Transforms disjointed, messy transcripts into cohesive, well-structured documents.
Visual Enrichment: Automatically inserts relevant images and ASCII diagrams to illustrate complex concepts.
Multilingual Intelligence: Processes transcripts and generates outputs in various languages seamlessly.
Interactive TUI: A beautiful, real-time terminal interface using ink to monitor progress.
Batch Mastery: Efficiently processes entire directories of transcripts in one go.

Available Commands

Redacta is designed to be flexible. Here are the primary ways to interact with it:

Command	Action
`--blog`	Generates a polished blog post (`_blog.md`)
`--summary`	Creates a concise executive summary (`_summary.md`)
`--language=<lang>`	Sets the target output language
`--with-illustration`	Adds key images and diagrams for clarity
`--with-illustration-all`	Deep illustration: adds comprehensive visual aids
`--directory=<dir>`	Batch process all `.srt` files in a folder
`--model=<id>`	Choose your preferred LLM model

How to Use It

Getting started with Redacta is straightforward.

1. Installation

npm install -g redacta

2. Configuration

export CUSTOM_SEARCH_KEY='your_key'
export CUSTOM_SEARCH_PROJECT='your_id'

3. Usage Examples

Basic cleanup in a specific language:

redacta tutorial.srt --language=spanish

Complete transformation (Blog + Summary + Diagrams):

redacta lecture.srt --blog --summary --with-illustration-all

Proposing Use Cases

Redacta isn't just for cleaning text; it's for unlocking the value in your media library.

Course Accelerator: Students can take a semester's worth of video lectures and turn them into a structured, illustrated study guide in minutes.
Podcast Content Engine: Creators can transform their audio episodes into SEO-friendly blog posts and social media summaries with zero manual writing.
Technical Documentation: Engineers can record a "brain dump" video of a complex architecture and let Redacta generate a formatted technical doc with diagrams.
Meeting Archivist: Turn recorded town halls or technical syncs into searchable, structured summaries for team members who couldn't attend.
Cross-Border Learning: Understand high-quality technical content from global experts by translating and formatting transcripts from languages you don't speak.

Demo

To see Redacta in action, let's look at two very different scenarios that showcase its versatility.

1. High-Level Technical Education

The first example is a technical talk by Andrej Karpathy about Large Language Models.

Source: Intro to Large Language Models by Andrej Karpathy.

Command:

node ./dist/bin/redacta.js ./examples/Intro_Large_Language_Model_LLM_talk.srt --with-illustration --blog

For technical content, Redacta focuses on structural clarity and visual aids. It doesn't just clean the text; it identifies core architectural concepts and generates ASCII diagrams to bridge the gap between spoken word and visual understanding.

Generated Snippet (Knowledge Scaffolding):

A large language model is just two files. For example: the Llama 2 70B model. It consists of the parameters file (weights) and the run file (code).

+---------------------+           uses         +---------------------+
|                     |----------------------->|                     |
|  PARAMETERS FILE    |                        |     RUN FILE        |
|  (140GB, float16    |                        |  (C/Python code,    |
|   weights)          |                        |   ~500 lines)       |
|                     |                        |                     |
+---------------------+                        +---------------------+

This is the raw transcript (input):
- transcript: Intro_Large_Language_Model_LLM_talk.srt
And these are the generated texts (output):
- formatted text: Intro_Large_Language_Model_LLM_talk_formatted.md
- blog: Intro_Large_Language_Model_LLM_talk_blog.md

2. Art History & Analysis (Multilingual)

Source: Las 5 alegorías (Analysis of Baroque Art).
Command:

node ./dist/bin/redacta.js ./examples/analisis_de_las_5_alegorias.srt --with-illustration --summary --language=English --blog

This example highlights Redacta's ability to handle cross-language translation and precision image insertion. The tool translated the Spanish lecture into a structured English blog post while automatically finding the specific masterpieces being discussed.

Generated Snippet (Visual Context):

Claesz ingeniously weaves each sense into the composition:

Hearing: Musical instruments evoke the sense of sound.

Sight: The painting itself, along with a mirror reflecting a wine glass.

Image: Still Life with Musical Instruments - 1623

Redacta successfully identified the specific painting (Still Life with Musical Instruments) from the transcript context and embedded it exactly where the description occurs.

This is the raw transcript (input):
- transcript: analisis_de_las_5_alegorias.srt
And these are the generated texts (output):
- formatted text: analisis_de_las_5_alegorias_formatted.md
- blog: analisis_de_las_5_alegorias_blog.md
- summary: analisis_de_las_5_alegorias_summary.md

Repository

Here you can find the repository:

Redacta

My Experience with GitHub Copilot CLI

I used GitHub Copilot CLI from the very first line of code. It wasn't just a helper; it was a fundamental partner in the architectural journey of Redacta.

Philosophical Approach: "CLI First, Automation Second"

My workflow followed a strict "CLI First" philosophy. Before writing a single line of automation logic, I used the GitHub Copilot CLI to "sketch" my ideas. I would explain my high-level goal to the CLI and work with it to set up the project structure and basic foundations.

This prevented over-engineering. I only started building the actual script once I had physically verified the core logic (like specific prompt outputs) manually within the CLI environment.

Pros of Using GitHub Copilot CLI

Iterative Prompt Engineering: The biggest advantage was the speed of testing. I started with the 'Editor' prompt—the core of Redacta. In the CLI, I could pipe a raw transcript to Copilot, apply a prompt, and see results in seconds. If the punctuation was off, I'd adjust the prompt and re-run instantly.
Zero-Boilerplate Prototyping: I didn't have to set up unit tests or local environments just to see if an LLM could handle a specific formatting task. The CLI provided a sandbox where I could test models and prompts as if they were simple shell commands.
Context-Aware Scaffolding: When I was ready to move from a manual prompt to a script, I could ask the CLI to read my project files and suggest the automation logic, ensuring the new code fit perfectly with existing patterns.

Seamless Integration with Copilot SDK

The Copilot SDK was the secret weapon that bridged the gap between experimentation and production. Once I was happy with a prompt's performance in the CLI, I used the SDK to embed that exact intelligence into my code.

The transition was frictionless; the SDK allowed me to keep the same models and prompt structures I had already "stress-tested" in the CLI. This "Copy-Paste Intelligence" approach significantly reduced the debugging time usually associated with integrating LLMs into a codebase.

High-Impact Improvements

As Redacta grew, the CLI handled the "heavy lifting" that usually slows down a project:

TypeScript Migration: It assisted in migrating the entire project from JavaScript to TypeScript, suggesting types and handling the boilerplate with precision.
Testing Suite: It helped scaffold a comprehensive testing suite with Vitest, ensuring that as I refined the prompts, I wasn't breaking core functionality.

All CORS explained from A to Z

Julio Castillo Anselmi — Sat, 24 Jun 2023 08:54:05 +0000

CORS definition

Before defining CORS, some fundamental concepts to understand CORS will be defined.

origin

Given a URL, the origin is the first part that is made up of the scheme: the host and the port (if present).

source = scheme + host + port

For example, in https://localhost:8080/surveys the source is https://localhost:8080 and /survey is the path

same-origin

It refers to the case where the client makes a request to a server and the server has the same origin as the client.

https://aurora.net/home -> https://aurora.net/api/pos?id=290

cross-origin (cross-origin)

The client makes a request to a server whose origin is different from that of the client.

https://localhost:8080/home -> https://aurora.net/api/pos?id=290
https://localhost:8080/home -> https://127.0.0.1:8080/api/pos?id=290
https://localhost:8080/home -> https://127.0.0.1:3000/api/pos?id=290

Same-origin policy and CORS

By default and by security policy, browsers only allow HTTP requests to the same origin, that is, to the same domain as the page that makes the request.

CORS (Cross-Origin Resource Sharing) is the mechanism by which browsers allow a request to be made from one origin to a different one, cross-origin.

In order to make a CORS request, the client does not have to do anything, it simply launches the request. The browser makes the request and it is the server that must respond if it accepts requests from that origin. It does this by sending the Access-Control-Allow-Origin header response. This header can have an asterisk (*) or a specific origin. The * means that the server accepts requests from any origin.
The browser reviews the browser's response. If you have the Access-Control-Allow-Origin header and it has the value * or the origin matches the client origin, then the browser accepts the response. Otherwise, it discards it and generally displays a CORS-descriptive error on the console.

 1. browser with origin X makes a request to origin Y
 2. server responds
 3. If the response from the server includes the header `Access-Control-Allow-Origin` Then
 4. If (Access-Control-Allow-Origin == '*') or (Access-Control-Allow-Origin == X) Then
 5. browser accepts the response
 6. If not
 7. discard response and show error
 8. End Yes
 9. If not
10. discard response and show error
11. End Yes

Access-Control-Allow-Origin can also be set to null for unknown origins (such as accessing from a file instead of a website). This is useful while you are in a development or testing phase, this way you don't need to put '*' which is less restrictive. Access-Control-Allow-Origin: null

Preflight

Above we have seen in a generic way how a cross-origin request should be treated using CORS. Actually, before making a cross-origin request, browsers that implement CORS will "meta" the actual request.

A preflight is a request that the browser makes before making a CORS request if the request meets one of these criteria:

Use an HTTP method other than GET, POST, or HEAD
Set the Content-Type header to a value other than: -application/x-www-form-urlencoded
- multipart/form-data -text/plain
Set additional headers other than: -Accept
- Accept-Language
- Content-Language
The XMLHttpRequest object contains upload events

The HTTP methods GET, POST and HEAD are called simple methods. Simple methods do not need to be listed in the Control-Allow-Methods header.

The preflight is a request with the OPTIONS HTTP method. This "meta" request that the browser makes is for the server to decide how to respond to CORS. In the preflight the browser sends the headers:

Origin
Access-Control-Request-Method (supports only one method)
Access-Control-Request-Headers (only if the headers are not simple. You can have a comma-separated list of headers)

The server checks if the HTTP origin and method are in its list of allowed origins and methods (it will also check the headers indicated in Access-Control-Request-Headers, if any). If this check is favorable, it responds with a status code in the range 200. The answer should not wear a bodysuit. The headers sent by the server are:

Access-Control-Allow-Origin
Access-Control-Allow-Methods (in this case it can be a comma separated list of commands)
Access-Control-Allow-Headers

Example of preflight request:

OPTIONS /api/posts HTTP/1.1
User-Agent: Chrome
Host: 127.0.0.1:8080
Accept: */*
Origin: http://localhost:3000
Access-Control-Request-Method: GET
Access-Control-Request-Headers: Security-Level, App-Name

Example preflight response:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http//localhost:3000
Access-Control-Allow-Methods: GET, DELETE
Access-Control-Allow-Headers: Security-Level, App-Name

Request example:

GET /api/posts HTTP/1.1
User-Agent: Chrome
Host: 127.0.0.1:8080
Accept: */*
Origin: http://localhost:3000
Security-Level: High
App-Name: Survey

The previous algorithm, now modified with the preflights, would look like this:

  1. the Javascript client whose origin is X, makes a request P to the server with origin Y.
        P contains the HTTP method M and a set of headers C
  2. If M is a simple HTTP method and all C headers are simple Then
  3. send the request P to the server
  4. If not
  5. prepare a preflight request F with HTTP OPTIONS method and a set of headers C' with:
         Origin = X, Access-Control-Request-Method = M
  6. If in C there are headers that are not simple Then
  7. add to C' the Access-Control-Request-Headers header with the list of non-simple C headers
  8. End Yes
  9. send preflight F to server
10 If server responds to preflight with status in the range of 200 Then
11. send the request P to the server
12. If not
13. Check the Access-Control-Allow-Origin response headers,
           Access-Control-Allow-Methods and Access-Control-Allow-Headers to determine which
           are the validations that have failed and report the error
14. End Yes
15. End Yes

Cache. The browser can cache the preflights and thus avoid making an extra request for each client request that would require a preflight. The cache saves on its origin + path entries.

Canvas and images

For images whose src attribute is a different origin than the client, the browser loads the resource and displays it but does not allow manipulations with it such as toBlob, toDataURL, and getImageData.
To enable CORS in the case of images, there is the crossOrigin attribute that can take the values anonymous or user-credentials. user-credentials is like withCredentials in XMLHttpRequest, ie user credentials (eg cookies) are sent with the request. If it is not necessary to send the credentials, it is preferable to send anonymous.

Cookies and user credentials

By default the browser does not send user credentials as cookies in cross-origin requests. The browser also does not expose all the response headers that the server sends.
That's why CORS has mechanisms to remedy those restrictions: the Access-Control-Allow-Credentials and Access-Control-Expose-Headers response headers.

So for the use of cookies it is necessary for the client to indicate:

xhr.withCredentials = true;
document.cookie = someUniqueId;

The server must respond to the preflight and the request with the headers
Access-Control-Allow-Credentials and Access-Control-Allow-Origin.

When the server sends the Access-Control-Allow-Credentials header with the value true, it must send the Access-Control-Allow-Origin header with a specific origin; Access-Control-Allow-Origin: * is invalid because accepting cookies from any origin can cause security problems.

Valid:

Access-Control-Allow-Origin: http://localhost:1111
Access-Control-Allow-Credentials: true

Invalid:

Access-Control-Allow-Origin: \*
Access-Control-Allow-Credentials: true

In the case where the client has xhr.withCredentials = true and the server responds with Access-Control-Allow-Origin: true, the server can set cookies on the client. These cookies will be sent by the browser in successive requests, however, the client will not be able to read these cookies with Javascript.

Response headers

The XMLHttpRequest object exposes two methods for reading response headers: getResponseHeader and getAllResponseHeaders. In a same-origin request these methods return all the headers sent by the server. When dealing with a cross-origin request, only the plain headers can be read.

Using the Access-Control-Expose-Headers header the server can specify which headers the client can read.

Access-Control-Expose-Headers: X-Powered-By

Simple headers:

Cache-Control

Content-Language

Content-Type

Expires

Last-Modified

Pragma

Summary of headers used in CORS

Request headers (sent by client browser)

Origin: Header added by the browser. Contains the origin of the client in the request. Counterpart: Access-Control-Allow-Origin.
Access-Control-Request-Method: Header added by the browser in the preflight. Contains the HTTP method that the client will do on the actual request. Counterpart: Access-Control-Allow-Methods.
Access-Control-Request-Headers: Header added by the browser in the preflight. Contains the HTTP headers that the client will send in the actual request. Counterpart: Access-Control-Allow-Headers.

Response headers (sent by the server)

Access-Control-Allow-Origin: The value * indicates that all origins are allowed
A specific value indicates that the server only accepts requests from that source
The value null indicates that it only accepts requests from sources that are not a web site, for example a file (only recommended for development and testing). Counterpart: Origin
Access-Control-Allow-Credentials: The value true indicates that the server supports the use of user credentials such as cookies.
Access-Control-Allow-Methods: Has a list of HTTP methods accepted by the server.
It is not necessary to include the simple methods, although it is good practice to do so.
This header should only be sent in response to preflight requests. Counterpart: Access-Control-Request-Methods
Access-Control-Allow-Headers: Has a list of HTTP headers accepted by the server.
This header should only be sent in response to preflight requests. Counterpart: Access-Control-Request-Headers
Access-Control-Max-Age: Its value specifies the maximum time in seconds that it is recommended to keep a preflight cache, although the browser can have its own maximum value.
This header should only be sent in response to preflight requests.
Access-Control-Expose-Headers: Contains the headers that can be read by the browser. You can have a comma separated list of headers.
It is optional and is not required for the CORS request to be successful.

Todo CORS explicado de la A a la Z

Julio Castillo Anselmi — Mon, 02 Jan 2023 19:19:40 +0000

Definición de CORS

Antes de definir CORS se definirán algunos conceptos fundamentales para entender CORS.

origen

Dada una URL, el origen es la primera parte que está compuesta por el esquema: el host y el puerto (si está presente).

origen = esquema + host + puerto

Por ejemplo, en https://localhost:8080/encuestas el origen es https://localhost:8080 y /encuesta es el path

mismo-origen (same-origin)

Se refiere al caso en el que cliente hace una petición a un servidor y el servidor tiene el mismo origen que el cliente.

https://aurora.net/home -> https://aurora.net/api/pos?id=290

origen-cruzado (cross-origen)

El cliente hace una petición a un servidor cuyo origen es distinto al del cliente.

https://localhost:8080/home -> https://aurora.net/api/pos?id=290
https://localhost:8080/home -> https://127.0.0.1:8080/api/pos?id=290
https://localhost:8080/home -> https://127.0.0.1:3000/api/pos?id=290

Política de mismo-origen y CORS

Por defecto y por política de seguridad, los navegadores sólo permiten hacer peticiones HTTP al mismo origen, es decir al mismo dominio del de la página que hace la petición.

CORS (Cross-Origin Resource Sharing) es el mecanismo por el cual los navegadores permiten que una petición se haga desde un origen a otro distinto, origen-cruzado.

Para poder realizar una petición CORS el cliente no debe hacer nada, simplemente lanza la petición. El navegador hace la petición y es el servidor el que debe responder si acepta peticiones desde ese origen. Esto lo hace enviando la cabecera (header response) Access-Control-Allow-Origin. Esta cabecera puede tener un asterisco (*) o un origen específico. El * significa que el servidor acepta peticiones de cualquier origen.
El navegador revisa la respuesta del navegador. Si tiene la cabecera Access-Control-Allow-Origin y ésta tiene el valor * o el origen coincide con el origen del cliente, entonces el navegador acepta la respuesta. En caso contrario la descarta y generalmente muestra en consola un error descriptivo de CORS.

 1. navegador con origen X hace petición a origen Y
 2. servidor responde
 3. Si la respuesta del servidor incluye la cabecera `Access-Control-Allow-Origin` Entonces
 4.   Si (Access-Control-Allow-Origin == '*') o (Access-Control-Allow-Origin == X) Entonces
 5.     navegador acepta la respuesta
 6.   Si no
 7.     descarta respuesta y muestra error
 8.   Fin Si
 9. Si no
10.   descarta respuesta y muestra error
11. Fin Si

Access-Control-Allow-Origin también puede tomar el valor null para orígenes desconocidos (como por ejemplo en el caso de acceder desde un fichero en vez de un sitio web). Esto es útil mientras se está en una fase de desarrollo o pruebas, de esta manera no hace falta poner '*' que es menos restrictivo. Access-Control-Allow-Origin: null

Preflight

Arriba se ha visto de manera genérica cómo se debe tratar una petición de origen-cruzado usando CORS. En realidad, antes de hacer una petición de origen-cruzado, los navegadores que implementan CORS harán una "meta" petición previa (preflight) a la petición real.

Un preflight es una petición que hace el navegador antes de efectuar una petición CORS si dicha petición cumple uno de estos criterios:

Usa un método HTTP distinto de GET, POST, o HEAD
Establece la cabecera Content-Type con un valor distinto de:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
Establece cabeceras adicionales distintas de:
- Accept
- Accept-Language
- Content-Language
El objeto XMLHttpRequest contiene eventos upload

A los métodos HTTP GET, POST y HEAD se los denomina métodos simples. Los métodos simples no necesitan ser listados en la cabecera Control-Allow-Methods.

El preflight es una petición con el método HTTP OPTIONS. Esta "meta" petición que hace el navegador sirve para que el servidor decida cómo responder al CORS. En el preflight el navegador envía las cabeceras:

Origin
Access-Control-Request-Method (admite sólo un método)
Access-Control-Request-Headers (sólo si las cabeceras no son simples. Puede tener una lista de cabeceras separada por comas)

El servidor comprueba si el origen y el método HTTP están en su lista de orígenes y métodos permitidos (también comprobará las cabeceras indicadas en Access-Control-Request-Headers, si es que lo hay). Si esta comprobación es favorable responde con un código de status en el rango 200. La respuesta no debería llevar un body. Las cabeceras enviadas por el servidor son:

Access-Control-Allow-Origin
Access-Control-Allow-Methods (en este caso puede ser una lista de comandos separados por coma)
Access-Control-Allow-Headers

Ejemplo de petición preflight:

OPTIONS /api/posts HTTP/1.1
User-Agent: Chrome
Host: 127.0.0.1:8080
Accept: */*
Origin: http://localhost:3000
Access-Control-Request-Method: GET
Access-Control-Request-Headers: Security-Level, App-Name

Ejemplo de respuesta preflight:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http//localhost:3000
Access-Control-Allow-Methods: GET, DELETE
Access-Control-Allow-Headers: Security-Level, App-Name

Ejemplo de petición:

GET /api/posts HTTP/1.1
User-Agent: Chrome
Host: 127.0.0.1:8080
Accept: */*
Origin: http://localhost:3000
Security-Level: High
App-Name: Encuesta

El algoritmo anterior, ahora modificado con los preflight quedaría así:

 1. el cliente Javascript cuyo origen es X, hace una petición P al servidor con origen Y.
       P contiene el método HTTP M y un conjunto de cabeceras C
 2. Si M es un método HTTP simple y todas las cabeceras de C son simples Entonces
 3.   enviar la petición P al servidor
 4. Si no
 5.   preparar una petición preflight F con método HTTP OPTIONS y un conjunto de cabeceras C' con:
        Origin = X, Access-Control-Request-Method = M
 6.   Si en C hay cabeceras que no son simples Entonces
 7.     agregar a C' la cabecera Access-Control-Request-Headers con el listado de cabeceras no simples de C
 8.   Fin Si
 9.   enviar preflight F al servidor
10    Si servidor responde el preflight con status en el rango de 200 Entonces
11.     enviar la petición P al servidor
12.   Si no
13.     comprobar las cabeceras de respuesta Access-Control-Allow-Origin,
          Access-Control-Allow-Methods y Access-Control-Allow-Headers para determinar cuáles
          son las validaciones que han fallado e informar el error
14.   Fin Si
15. Fin Si

Cache. El navegador puede guardar en caché los preflights y así evitar hacer una petición extra por cada petición del cliente que requeriría preflight. La caché guarda en sus entradas origen + path.

Canvas e imágenes

En el caso de imágenes cuyo atributo src es un origen distinto al del cliente, el navegador carga el recurso y lo muestra pero no permite hacer manipulaciones con ella como toBlob, toDataURL y getImageData.
Para habilitar el CORS en el caso de imágenes, existe el atributo crossOrigin que puede tomar los valores anonymous o user-credentials. user-credentials es como el withCredentials de XMLHttpRequest, es decir que las credenciales de usuario (por ejemplo, cookies) se envían con la petición. Si no es necesario enviar las credenciales, es preferible enviar anonymous.

Cookies y credenciales de usuario

Por defecto el navegador no envía las credenciales de usuario como las cookies en las peticiones de origen-cruzado. El navegador tampoco expone todos las cabeceras de respuesta que envía el servidor.
Por eso CORS tiene mecanismos para remediar esas restricciones: las cabeceras de respuesta Access-Control-Allow-Credentials y Access-Control-Expose-Headers.

Entonces para que el uso de cookies es necesario que el cliente indique:

xhr.withCredentials = true;
document.cookie = someUniqueId;

El servidor debe responder al preflight y a la petición con las cabeceras
Access-Control-Allow-Credentials y Access-Control-Allow-Origin.

Cuando servidor envía la cabecera Access-Control-Allow-Credentials con el valor true, debe enviar la cabecera Access-Control-Allow-Origin con un origen específico; Access-Control-Allow-Origin: * es inválido porque aceptar cookies de cualquier origen puede generar problemas de seguridad.

Válido:

Access-Control-Allow-Origin: http://localhost:1111
Access-Control-Allow-Credentials: true

Inválido:

Access-Control-Allow-Origin: \*
Access-Control-Allow-Credentials: true

En el caso en el que el cliente tiene xhr.withCredentials = true y el servidor responde con Access-Control-Allow-Origin: true, el servidor puede establecer cookies en el cliente. Estas cookies serán enviadas por el navegador en las peticiones sucesivas, sin embargo, el client no podrá leer dichas cookies con Javascript.

Cabeceras de respuesta

El objeto XMLHttpRequest expone dos métodos para leer las cabeceras de respuesta: getResponseHeader y getAllResponseHeaders. En una petición mismo-origen estos métodos devuelven todas las cabeceras enviadas por el servidor. Cuando se trata de una petición de origen-cruzado, sólo se pueden leer las cabeceras simples.

Usando la cabecera Access-Control-Expose-Headers el servidor puede especificar qué cabeceras puede leer el cliente.

Access-Control-Expose-Headers: X-Powered-By

Cabeceras simples:

Cache-Control

Content-Language

Content-Type

Expires

Last-Modified

Pragma

Resumen de cabeceras usadas en CORS

Cabeceras de petición (enviadas por el navegador cliente)

Origin: Cabecera que añade el navegador. Contiene el origen del cliente en la petición. Contraparte: Access-Control-Allow-Origin.
Access-Control-Request-Method: Cabecera que añade el navegador en el preflight. Contiene el método HTTP que se hará el cliente en la petición real. Contraparte: Access-Control-Allow-Methods.
Access-Control-Request-Headers: Cabecera que añade el navegador en el preflight. Contiene las cabeceras HTTP que enviará el cliente en la petición real. Contraparte: Access-Control-Allow-Headers.

Cabeceras de respuesta (enviadas por el servidor)

Access-Control-Allow-Origin: El valor * indica que se permiten todos los orígenes
Un valor específico indica que el servidor sólo acepta peticiones de ese origen
El valor null indica que sólo acepta peticiones de orígenes que no son un sitio web, por ejemplo un fichero (sólo recomendado para desarrollo y pruebas). Contraparte: Origin
Access-Control-Allow-Credentials: El valor true indica que el servidor soporta el uso de credenciales de usuario tales como las cookies.
Access-Control-Allow-Methods: Tiene una lista de métodos HTTP aceptados por el servidor.
No es necesario incluir los métodos simples, aunque es buena práctica hacerlo.
Esta cabecera sólo debe enviarse en respuesta a peticiones preflight. Contraparte: Access-Control-Request-Methods
Access-Control-Allow-Headers: Tiene una lista de cabeceras HTTP aceptadas por el servidor.
Esta cabecera sólo debe enviarse en respuesta a peticiones preflight. Contraparte:Access-Control-Request-Headers
Access-Control-Max-Age: Su valor especifica el tiempo máximo en segundos que se recomienda mantener en caché un preflight, aunque el navegador puede tener su propio valor máximo.
Esta cabecera sólo debe enviarse en respuesta a peticiones preflight.
Access-Control-Expose-Headers: Contiene las cabeceras que pueden ser leídos por el navegador. Puede tener una lista de cabeceras separada por comas.
Es opcional y no es necesario para que la petición CORS sea exitosa.

LitElement in depth: the update lifecycle

Julio Castillo Anselmi — Sat, 07 Mar 2020 10:50:07 +0000

📣 UPDATE! 📣
Now lit-html and LitElement are unified under Lit.
I'm writing new posts about Lit, meanwhile you can:

read this post because the principles are the same

upgrade your code with this guide

visit Lit site to know what's new

You can also use lit-html standalone

Although lit-html is very efficient rendering, it is better to render only when necessary. That is why LitElement differs the re-rendering of the UI by batching the property updates. In other words, re-rendering is done asynchronously to ensure efficiency and good performance. Let's see how the update process works.

Recall from the previous post that all the properties defined in the properties getter become properties "controlled" by LitElement.

For each property defined in the properties getter, LitElement will generate:

a hasChanged function
a setter and a getter
an observed attribute
a fromAttribute function
a toAttribute function

In particular, we are interested in the hasChanged function and the setters because they play an important role in the update life cycle.

Almost all the "magic" is based on the setter that causes the component to be re-rendered when the property changes. First, it checks if the property has changed (invoking the hasChanged function) and, if that is the case, it will make a rendering request.
Also, if the property is reflected in an attribute, the setter will update the observed attribute using the toAttribute function.

In the LitElement class we find the following methods that participate in the update of the UI:

requestUpdate
performUpdate
shouldUpdate
update
render
firstUpdated
updated
updateComplete

Now that we have seen the main pieces involved in the re-rendering, we will go into detail on how this process occurs.

The update cycle in action

Imagine you have a function with this piece of code:



const el = document.querySelector('#myElement');
el.title = 'Movements'; //previous value was 'No title'
el.icon = 'book.ico'; //previous value was undefined
await el.updateComplete;

1. The title property setter is executed. This setter calls hasChanged function of the title property. As it has changed, it returns true and in that case it calls performUpdate, a method of the LitElement class. This method verifies if there is a previous request pending, in that case it does nothing. If there isn't, it will create a micro-task (a promise) to execute the rendering. This is LitElement's way of asynchronously executing the render method and batch property changes.
2. We continue with the following line. Now the icon property setter is executed. The setter calls hasChanged function, which returns true, so it calls theperformUpdate method, but as a UI update operation is already pending, it does nothing else.
3. Finally, our code is awaiting for the updateComplete promise to be resolved, that will occur when the update cycle is over.
4. Now that there are no tasks on the stack, it is time to execute the micro task that was scheduled (in the step 1). It does the following:
4.1. It invokes shouldUpdate, another method of the LitElement class. This method receives the properties that have changed and their old values. The purpose of this method is to evaluate all the batched changes that have occurred and based on that decide whether or not the update should be done. By default it returns true, but LitElement gives us this hook in case we want to put a special logic to avoid the update. Following our example, shouldUpdate receives title => 'No title', icon => undefined and returns true, so the update continues.
4.2. It executes the update method of the LitElement class. Here the changes are reflected to the attributes to maintain synchrony between properties and attributes (only for those properties defined with reflect). Then it calls the render method.
4.2.1. The render function is executed, the DOM is updated.
4.2.2. If it is the first time the component is rendered, the firstUpdated method will be executed. It's a hook that LitElement gives us to over-write if we need to do initialization tasks once the component is rendered.
4.2.3. Then the updated method of the LitElement class is executed. This is another hook. Unlike firstUpdated, this method will always be called after every rendering.
4.2.4. The updateComplete promise get resolved.

👉 All the properties defined in the properties getter become properties "controlled" by LitElement and any update of their values will cause a rendering. This is why we should put there only the properties that affect the visual representation of the component: those that we have used in the template.
For example, if we have a debug property that is used to indicate if traces are written by console.log, changing this property should not cause an UI update.

Live example

To understand it better, I have made this very silly component. The important part is that I have traced each method of the update lifecycle.

When the component is rendered the first time you can find among the traces that there is an invocation to the firstUpdated method.
I have traced the _requestUpdate and _enqueueUpdate methods that are private methods of UpdatingElement which is the class of which LitElement class extends. Although these methods are not an "official" part of the update lifecycle, seeing how LitElement uses them internally helps to understand the update process. We can see that _requestUpdate is called for every property that changes but _enqueueUpdate it's called only once: with the first property that changed. When there's an update process pending, _enqueueUpdate is not invoked again.
The first time you press the button, it will update the title and icon properties. At this moment the component will be already rendered so you won't find a call to firstUpdate.
The second time you press the button, it will update again the title and icon properties with the same values it did before. As the property values have no changes, the update cycle is not triggered.
I have included the source code of the UpdatingElement class because I think you can understand it and see in detail how the UI update process is implemented.

requestUpdate

Sometimes it may be necessary to manually trigger the re-rendering cycle. It is not enough to invoke the render method, because as we have seen, the process is much more complex. For these cases, LitElement provides the requestUpdate method that will trigger the whole lifecycle update.

A typical case where we should invoke requestUpdate is when we define our own setter and we want that a change in the property to cause a re-rendering. As we have seen before, for each controlled property LitElement generates a setter that evaluates whether the property has changed and if so, it updates the UI. But when we write our own setter, we lose the setter that would be generated by LitElement, because of this, we have to do by ourselves what LitElement does. We should do:



set title(value) {
  if (this._title !=== value) {
    const oldValue = this._title;
    this._title = value;
    this.requestUpdate('title', oldValue); // Called from within a custom property setter
  }
}

👉 When we invoke requestUpdate from a setter we must pass the property name and the old value as arguments. On the other hand, if we force a re-render from elsewhere, requestUpdate has no arguments.

This is the end

With this last topic about the UI update lifecycle we complete the basics of LitElement. You already have the fundamental knowledge to continue your path in lit-html and LitElement.

To go deeper in these libraries I highly recommend reading the official documentation. It's It is very clear, concise and very well organised. In addition, each topic is accompanied by a live example in Stackblitz.

Lit project guide

I also suggest you read the source code of lit-html and LitElement. It is relatively short, well documented and with what you already know you will not find it difficult to understand. This way everything will be much clearer.

Lit source code

Last but not least, two important contributions from the community:

awesome lit - A wonderful collection of resources made by @serhiikulykov.
open-wc - Web component recommendations with a bunch of powerful and battle-tested setup for sharing open source web components.

Last words...

With this post I finish my series on LitElement. I hope you found it useful and enjoyed it as much as I did writing it. Thank you for having come this far! ❤️

PolymerElement is dead, long live LitElement!

Julio Castillo Anselmi — Wed, 20 Nov 2019 22:03:36 +0000

📣 UPDATE! 📣
Now lit-html and LitElement are unified under Lit.
I'm writing new posts about Lit, meanwhile you can:

read this post because the principles are the same

upgrade your code with this guide

visit Lit site to know what's new

You can also use lit-html standalone

Hello my friends! We've finally reached the main subject of this series: LitElement.

A new class to rule web components

To understand what LitElement is and what it does for us, we will return to where we left in the previous post. Let's remember what we did last time, we used lit-html to create a web component capable of re-rendering when the value of a component's property changed.

To achieve that, we had to create a class with a constructor that was responsible for creating the shadow DOM and reflecting the values of the HTML attributes to the component properties. Then, to get the component re-render every time a property changes we had to write a setter for each one of them and call the lit-html render function inside that setter.
And last but not least, we had to write code in order to keep HTML properties and attributes in sync.

All this results in repetitive code that increases according to the number of properties that the component has. To create a better developer experience, the Polymer team thought that it would be good to have a class that handles all this burden for us. As well as they made PolymerElement, but this time they had to evolve and take advantage of their wonderful lit-html, so it wouldn't be a new version of PolymerElement, it had to be totally new, and so they created LitElement.

LitElement not only frees us from repetitive code, it also makes lit-html rendering even more efficient by making it happen asynchronously.

So, LitElement is a lightweight class to create web components. It handles for us all the repetitive code needed to:

use shadow DOM
keep in sync HTML attributes and component properties
efficiently render (using lit-html) the component every time a property changes

Let's see the minimal code that a LitElement needs:

// Import the LitElement base class and html helper function
import { LitElement, html } from 'lit-element';
// Import other element if it needed
import 'package-name/other-element.js';

// Extend the LitElement base class
class MyElement extends LitElement {

  /**
   * Implement `render` to define a template for your element.
   *
   * You must provide an implementation of `render` for any element
   * that uses LitElement as a base class.
   */
  render() {
    /**
     * `render` must return a lit-html `TemplateResult`.
     *
     * To create a `TemplateResult`, tag a JavaScript template literal
     * with the `html` helper function:
     */
    return html`
      <!-- template content -->
      <p>A paragraph</p>
      <other-element></other-element>
    `;
  }
}

// Register the new element with the browser.
customElements.define('my-element', MyElement);

As you've seen the only requirement is to implement the render function that draws the component's UI. This function must return a TemplateResult and that is because it will call the render function provided by lit-html (notice we also import the html function). This is very important because everything that we've seen in previous posts of lit-html applies to LitElement.

We could summarize LitElement in a very simplistic formula:

LitElement = lit-html + shadow DOM + auto async render

LitElement's render function

The render function has a great importance in LitElement because it defines how the component will look. When you see the defined template you should understand how the component will be painted in every situation. There's no other place where the component's UI can be modified or updated. And what is more, whenever a property changes (the component's state changes) LitElement will call the render function to update the component representation. So it turns out that the UI is expressed as function of the component's state.

UI = f(state)

According to this functional approach the template should be written as a pure function of the properties of the component, such that:

It doesn't change the status of the component
It has no side effects
It only depends on the properties of the component
It always returns the same value if the properties have not changed

This results in a great developer experience because you don't need to worry about how to update the component when something has changed. It will be re-rendered according to the new state and the performance impact of the rendering action has no value due to the efficiency of lit-html plus the asynchronous optimization added by LitElement.

Without this solution, we would have rendered the component once (the first time) and would have written additional code to update some part of the component for each possible state change and, in general, this code would have had many conditions and considerations. In the long run, updating the visual representation depending on the changes in the state of the component becomes an arduous task and a lot of code to maintain.

Also in the re-render approach, the component's UI is defined declaratively and in one place. The classic approach (update UI parts) is imperative and the logic is distributed in many functions.

Our first LitElement component

Do you remember the <password-checker> component that we created with lit-html in the previous post?

import { html, render } from 'lit-html';

class PasswordChecker extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
    this.password = this.getAttribute('password');
  }

  get password() { return this._password; }

  set password(value) {
    this._password = value;
    this.setAttribute('password', value);
    this.update();
  }

  update() {
    render(this.template(), this.shadowRoot, {eventContext: this});
  }

  isValid(passwd) {
    const re = /(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{4,}/;
    return re.test(passwd);
  }

  template() {
    return html`
      <span>Your password is <strong>${this.isValid(this.password) ? 'valid 👍' : 'INVALID 👎'}</strong></span>
      ${this.isValid(this.password) ?
        html`<div>Strength: <progress value=${this.password.length-3} max="5"</progress></div>` : ``}`;

  }
}

customElements.define('password-checker', PasswordChecker);

Now let's see how that component is implemented using LitElement.

import { LitElement, html } from 'lit-element';

class PasswordChecker extends LitElement {
  static get properties() {
    return {
      password: String
    }
  }

  isValid(passwd) {
    const re = /(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{4,}/;
    return re.test(passwd);
  }

  render() {
    return html`
      <span>Your password is <strong>${this.isValid(this.password) ? 'valid 👍' : 'INVALID 👎'}</strong></span>
      ${this.isValid(this.password) ?
        html`<div>Strength: <progress value=${this.password.length-3} max="5"</progress></div>` : ``}`;

  }
}

customElements.define('password-checker', PasswordChecker);

The first thing to notice is that there is no constructor. We don't need it in this case. We don't need to add a shadow root because LitElement does that for us. When LitElement renders a component, it calls lit-html's render function and that function expects an argument that is a node where to paint the component. LitElement creates the shadow root for the component and passes it to the lit-html's render function. It's very similar to what we did in the update function of the lit-html version.
If for whatever reason we don't want our component to use shadow DOM, we can overwrite the createRenderRoot function and return a this value.

createRenderRoot() {
  return this;
}

Although LitElement does many things for us, it also lets us customize the default behaviour by overriding some functions. We'll see that LitElement is very flexible.

Properties and update

Our lit-html version of <password-checker> had a setter for the property password and in that function we updated the HTML attribute and invoked the render function. LitElement does the same thing for us. All the brilliance things happens when we define the getter function properties:

  static get properties() {
    return {
      password: String
    }
  }

Every property that is defined inside this function will be controlled by LitElement so that a change of its value will cause the component to be re-rendered.
Thus for each declared property LitElement will provide:

an observed attribute
accessors
hasChanged function
fromAttribute function
toAttribute function

Let's see in detail what they are:

Observed attribute

Suppose your component has a property called birthYear, you will be able to use the attribute birthyear in the markup

<my-comp birthyear="1973">

and LitElement will assign that value to the property but it previously converts the String value to the property's type (Number in this case) using the fromAttribute function.

👉 Notice that, by default, the attribute's name is the property's name in lowercase. You can change it by using the attribute key in the property definition:

static get properties() {
  return {
    birthYear: {
      type: Number,
      // the observed attribute will be birth-year instead of birthyear
      attribute: 'birth-year'
    }
  }
}

Although by default LitElement passes values from attributes to properties, the opposite is not true. If you want a change in a property value to be reflected in HTML attribute you must explicitly tell so using the key reflect.

static get properties() {
  return {
    birthYear: {
      type: Number,
      // the observed attribute will be birth-year instead of birthyear
      attribute: 'birth-year'
      reflect: true
    }
  }
}

hasChanged

It's a function that checks if the new value is different from the previous value. In that case it returns true.

⚠️ Be careful with values that are objects or arrays because the comparison is made at top level, it doesn't do a shallow comparison, so if you evaluate obj1 === obj2 you're comparing references. In that cases you should override hasChanged to do the proper comparison.

fromAttribute

It is the function that converts the String value of the observed attribute to the real type of the property. You can provide your custom converter by overriding fromAttribute.

toAttribute

It is the function used to convert the property value into a String value so that it can be assigned to the observed attribute in the markup code (HTML). This function is used by LitElement when the property has been set to reflect.
If you need a custom converter, then override toAttribute.

Accessors

LitElement generates accessors, a getter and a setter, for declared properties. In the setter relies almost all the 'magic' that causes the component to be re-rendered when a property changes. First it checks if the property has changed (invoke hasChanged function) and if that's the case, then it will trigger an UI update.
Also if, the property is reflected to an attribute, the setter will update the observed attribute using the function toAttribute.

If you provide your own getter or setter or both, then LitElement won't create any accessor for that property. Just keep in mind that if you write your own setter and you want that a change causes a re-render, you'll have to make the same things that ** LitElement ** 's getter does.
You can also avoid auto-generated getter and setter using the key noAccessor.

static get properties() {
  return { birthYear: { type: Number, noAccessor: true } };
}

I summarize these points in an example:

// properties getter
static get properties() {
  return {
    // by default, every declared property: 
    //  - has an observed attribute,
    //  - when the attribute changes, it updates the property
    //  - has a getter and a setter
    //  - changes in value triggers a render update
    //  - has a default hasChanged function
    //  - has default converters: fromAttribute, toAttribute
    //  - all of this can be customized
    firstName: { type: String }, // type is the minimum required information
    lastName:  { type: String,
                 attribute: 'last-name'
               },
    enrolled:  { type: Boolean },
    address:   { type: Object,
                 reflect: false,
                 noAccessor: true,
                 hasChanged(newValue, oldValue) {
                    return newValue.zipCode != oldValue.zipCode;
                 }
               },
    age:       {
                 converter: {
                   toAttribute(value) {
                     return String(value);
                   }
                   fromAttribute(value) {
                     return Number(value);
                   }
                }
    }
  };
}

As last remarks, we observe that the properties getter is very similar to the properties getter that we used in PolymerElement but the LitElement version lacks the following features:

initial value

In PolymerElement's properties getter we can assign an initial value to a property, but that's not possible in LitElement, we must do that in the constructor.

// PolymerElement 
static get properties() {
  return { birthYear: { type: Number, value: 1973 } };
}

// LitElement
constructor() {
  super(); // Don't forget to call super() !!!
  this.birthYear = 1973;
}

observed properties

LitElement has no observed attributes. You can use a setter to perform actions when the property changes.

// PolymerElement 
static get properties() {
  return { birthYear: { type: Number, observer: '_yearChanged' } };
}

// LitElement
set birthYear(value) {
  // Code to check if property hasChanged
  // and request UI update should go here
  // ...
  this._birthYear = value;  // private _birthYear with getter birthYear
  this._yearChanged();
}

computed properties

LitElement doesn't have computed properties. To achieve the same result use getters.

// PolymerElement 
static get properties() {
  return { birthYear: { type: Number },
           age: { type: Number, computed: '_computeAge(birthYear)' }
 };
}

// LitElement
get age() {
  return (new Date()).getFullYear() - this.birthYear;
}

Well, we've had enough already.
So far the first part about LitElement. In the next post I will tell you in detail how is the asynchronous rendering process and the life cycle of a LitElement component.
See you!

Use lit-html to create web components (à la React)

Julio Castillo Anselmi — Fri, 05 Jul 2019 21:23:51 +0000

📣 UPDATE! 📣
Now lit-html and LitElement are unified under Lit.
I'm writing new posts about Lit, meanwhile you can:

read this post because the principles are the same

upgrade your code with this guide

visit Lit site to know what's new

You can also use lit-html standalone

This post was going to be about directives in lit-html, which is the way we can extend the library but I didn't want to keep delaying the arrival to our central theme of the series that is LitElement. So I decided to leave the directives for later and enter the doors of LitElement. I'm going to show you how to create web components using lit-html and we'll see how we get to LitElement from there. Let's get started!

The idea

We are going to build a web component using only lit-html but with a similar approach to React, that is, we'll have a declarative template that defines exactly how the component UI is for its entire state and we'll also make that when a component property changes, a new rendering will update its UI.

To define the UI, instead of JSX, we'll use template literals and the html tag as we have seen in previous posts.
We also know that lit-html is super efficient rendering so we won't have any issues if we invoke the render function every time a property changes.

The component that we will create will be very simple at a visual and functional level. Do not expect us to make a mega component, not for now. In this publication we want to focus on the basic concepts for creating web components.

So our component will be a password checker: a component that given a password it tells if it is valid or invalid and if it is valid it also tells us how strong it is.

The rules that apply are these:

The password is valid if:
- it has at least 4
- It has at least one lower case letter.
- It has at least one capital letter.
- it has at least one digit
If it is valid, a bar that measures its strength is shown.
If it is invalid, the strength bar is not shown.

Valid password example

<password-checker password="aB1sgX4"></password-checker>

Invalid password example

<password-checker password="aB1"></password-checker>

The code

We create a password-checker.js file and in the first line we'll import the html and render functions from lit-html:

import { html, render } from 'lit-html';

Then, as we do with any other web component, we create a class that:

extends HTMLElement.
has a constructor that creates the component's shadow DOM.

Also, our component has a property to keep the password and it should be initialized with the value defined by the user in the HTML file, as we can see here: <password-checker password="aB1">. We do that in the last line of the constructor.

class PasswordChecker extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
    this.password = this.getAttribute('password');
  }

Now let's think of the visual representation and define the template:

  template() {
    return html`
      <span>Your password is <strong>${this.isValid(this.password) ? 
            'valid 👍' : 'INVALID 👎'}</strong></span>
      ${this.isValid(this.password) ? 
        html`<div>Strength: <progress value=${this.password.length-3} max="5"</progress></div>` : ``}`;

  }

The template uses a conditional expression to show the strength bar only if the password is valid. Also note that the property password is the essential part of the template, its value defines how the component is presented. Any change to the password property has to trigger an UI update causing a re-rendering of the component. How can we achieve that?

It's easy, we create a setter for the password property so that when updating its value we force an update of the component. We also want the password attribute of the HTML element to have the new value. This is the code:

  set password(value) {
    this._password = value;
    this.setAttribute('password', value);
    this.update();
  }

  get password() { return this._password; }

  update() {
    render(this.template(), this.shadowRoot, {eventContext: this});
  }

As we define a setter we also define a getter.
The update function invokes the render function that will cause the component's UI to be updated.

👉 The point to remark here is that we call the render function passing the shadowRoot of the component so that the template goes inside the component's shadow DOM. The third argument has the context that will be used in the event handlers (if there were). So we can have in our template something like this:
<button @click=${this.start}>Start</button>. The this in @click=${this.start} has the context passed in the eventContext property. If we don't pass the context, this.start will fail.

Finally we register the web component:

customElements.define('password-checker', PasswordChecker);

The final code, all together is like this:

import { html, render } from 'lit-html';

class PasswordChecker extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
    this.password = this.getAttribute('password');
  }

  get password() { return this._password; }

  set password(value) {
    this._password = value;
    this.setAttribute('password', value);
    this.update();
  }

  update() {
    render(this.template(), this.shadowRoot, {eventContext: this});
  }

  isValid(passwd) { 
    const re = /(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{4,}/;
    return re.test(passwd);
  }

  template() {
    return html`
      <span>Your password is <strong>${this.isValid(this.password) ? 'valid 👍' : 'INVALID 👎'}</strong></span>
      ${this.isValid(this.password) ? 
        html`<div>Strength: <progress value=${this.password.length-3} max="5"</progress></div>` : ``}`;

  }
}

customElements.define('password-checker', PasswordChecker);

Recap

This is the recipe we have used to create web components à la React.

Import html and render from lit-html.
Create a class that extends HTMLElement.
Write a constructor that:
- creates the shadow DOM.
- initializes properties from values in the HTML tag.
Write the template for the components UI.
Write an update function that calls render.
For every property that a value change requires an update of the UI:
- write a setter that updates the UI and synchronizes the property with its related HTML attribute.
- Write a getter.
Register the component.

Live on Glitch

You can see the code and play with it on my Glitch page.

Final thoughts

Similar to React but not like React

The approach we used to create the component is similar to React but it is not exactly the same. We could say that the way we define the template it's the same but with a different implementation: React uses JSX, a language that must be processed to generate JavaScript code, and lit-html is based on JavaScript features so it doesn't require extra processing.
The part in which they differ is in the update of the UI: React updates the component when we make a call to the setState function and in our approach the update occurs 'automatically' when a property changes. It may seem a very subtle difference but it will be more evident when we see this same idea in LitElement.

lit-html in the real world

Previously we have seen that lit-html doesn't require a component model and therefore we can use it in a variety of projects even mixing it with other frameworks and libraries. And now we have just seen that with this library we can implement web components which makes it even more powerful and easier to integrate into other projects.

There are several projects that use lit-hmtl. I leave here some of them. The source of this information is this fantastic collection of resources on lit-html that I recommend you take a look: Awesome Lit.

Of course I also recommend the official lit-html documentation that is clear and complete.

Some projects based on lit-html

LitElement is coming...

Finally, in the next post I'll talk about LitElement! See you soon.

lit-html templates from zero to hero

Julio Castillo Anselmi — Mon, 17 Jun 2019 20:33:20 +0000

📣 UPDATE! 📣
Now lit-html and LitElement are unified under Lit.
I'm writing new posts about Lit, meanwhile you can:

read this post because the principles are the same

upgrade your code with this guide

visit Lit site to know what's new

You can also use lit-html standalone

After a very smooth introduction to lit-html, I will go hard and get my hands dirty. I will show you how to write templates so this will be a session full of code!

I know you are here because you want to learn LitElement, so you read this title and find out that we continue with lit-html. The reason why I've structured these sessions this way is because lit-html is the basis for LitElement and also because I want you to see the great potential and versatility of lit-html by itself, probably the perfect match for a small or medium project. I assure you that everything you learn about lit-html will be used in LitElement. Be patient, we will arrive soon.

Writing templates

☝️Remember from last post: templates are written using tagged template literals. We tag the template literal with the html function provided by lit-html. This function returns a TemplateResult object.
render is the other function provided by lit-html. render receives a TemplateResult object and renders it into the DOM.

This is a very simple example:

// import functions from lit-html library
import {html, render} from 'lit-html';

// define the template as function that takes the data
// and returns a TemplateResult object
const template = name => {
  return html`
    <p>Hello ${name}</p>
  `;
};

// node where the template will be rendered
const mainNode = document.getElementById('main');

// render the template
render(template('Silvia'), mainNode);

// render the template again with different data
render(template('Benjamin'), mainNode);

The dynamic parts of a template are JavaScript expressions that are binded with values. TemplateResult supports bindings of certain data types that we will see now.

Supported bindings

Text: An expression that is resolved as text can be used as the text content of a node. Be aware that an empty string ('') in a text binding will render an empty text node.
Attribute: an expression that returns a text can be used as the value of an attribute. When an attribute behaves like a boolean (it is present or not) we denote it with the name of the attribute preceded by ?. The value of the expression must be boolean, if it is true lit-html puts the attribute and if it is false it removes it.
Property: An expression can also be binded to a JavaScript node's property. We write the property name with a . at the beginning. In that case, the type of expression must match the type of the property (it could be any type even a complex object).
Event: An expression can be the handler of an event. For this we write the event name preceded by @ and in this case we have several alternatives for the binding.
- Global handler function: the expression resolves to a global function that will handle the event.
- Inline function: the expression resolves to an inline function.
- Instance function: the expression resolves to a function that belongs to your object.
- Event listener object: the expression returns an object that must have a function named clickHandler.
HTML node element: the expression can return a DOM node.
TemplateResult: the expression can be another TemplateResult object. This makes it possible to have composition of nested templates.
Iterable of TemplateResult objects: expressions that returns an array or iterables of TemplateResult objects.
Promise: the expression can return a promise that must be resolved returning a valid binding value.

// Text binding
html`<p>${someText}</p>`;
html`<div>${capitalize(user.name, user.firstName)}</div>`;

/**** Given theses variables and values... **************

let someText = 'Lorem ipsum';
let user = { name : 'JEN', firstName: 'MONROE' };  

***** The code above will render... *********************

<p>Lore ipsum</p>
<div>Jen Monroe</div>
*********************************************************/


// Attribute binding
html`<div class=${classList}>Stylish text.</div>`;

/**** Given these variables and values... *****************

let classList = ['main', 'required', 'modern'].join(' ');

***** The code above will render... ***********************

<div class="main required modern">Stylish text.</div>
***********************************************************/


// Attribute binding (boolean)
html`<input type="submit" ?disabled=${formWithErrors} value="Submit">
     <span ?hidden=${!formWithErrors}>Form has errors!</span>`;


/**** Given these variables and values... *****************

let formWithErrors = true;

***** The code above will render... ***********************

<input type="submit" disabled value="Submit">`;
<span>Form has errors!</span>`
***********************************************************/


// Property binding
html`<custom-list .items=${users} id="user-list"></custom-list>`;

/**** Given these variables and values... *****************

const users = ['Diego', 'Ana', 'Laura', 'Piero'];
const customList = document.getElementById('user-list');
console.log(customList.items);

***** The code above will show in console *****************

 ["Diego", "Ana", "Laura", "Piero"]

***********************************************************/


// Event binding to a global handler function
html`<button @click=${handleClick}>Click Me!</button>`; 


// Event binding to an inline function
html`<button @click=${()=>console.log('clicked')}>Click Me!</button>`; 


// Event binding to an instance function
html`<button @click=${this.handleClick}>Click Me!</button>`;


// Event binding to listener object
html`<button @click=${clickHandler}>Click Me!</button>`;

const clickHandler = {
  handleEvent(e) { console.log('clicked!'); }
};


// Binding to a DOM node
const h1 = document.createElement('h1');
h1.textContent = 'Chapter 1'
const page = html`${h1}<p>Once upon a time...</p>`;

/***** The code above will render... **********************

<h1>Chapter 1</h1>
<p>Once upon a time...</p>
***********************************************************/


// Binding to a TemplateResult object
const header = html`<h1>Chapter 1</h1>`;
const article = html`<article>${header}<p>Once upon a time...</p></article>`;

/***** The code above will render... **********************

<article>
  <h1>Chapter 1</h1>
  <p>Once upon a time...</p>
</article>
***********************************************************/


// Binding to arrays/iterables
const items = [1, 2, 3];
const listItems = items.map(i => html`<li>${2*i}</li>`);
const template = html`<ul>${listItems}</ul>`;

/***** The code above will render... **********************

<ul>
 <li>2</li>
 <li>4</li>
 <li>6</li>
</ul>
***********************************************************/


// Binding to a promise
const text = fetch(url).then(response => response.text());
const page = () => html`<p>${text}</p>`;

/***********************************************************
Let's say that after some seconds the fetch operation 
resolves with a the string 'some text...'

Until the promise is resolved, the code above will render
<p></p> 

Once the promise is resolved, it will render...
<p>some text...</p>

***********************************************************/

Composition

One consequence of having bindings to expressions that return TemplateResult objects is that by composition we can create templates using other templates. The composition allows:

Create a complex template using simpler templates.
Refactor a complex template by diving it into simpler templates.
Reuse of templates (the use of JavaScript modules makes reuse much easier, for example, a module of common templates, partial templates, etc.)

const header = data => html`
    <h1>${data.title}<h1>
    ${data.subtitle ? html`<h2>${data.subtitle}<h2>` : ''}`;


const main = data => html`<p>${makeParagraph(data.text)}</p>`;

const composedTemplate = data => html`
    ${header(data)}
    ${main(data)}`;

Conditionals

A template can have parts that are only visible if a condition is met, or it could have parts that are represented in different ways depending on one or more conditions. These behaviors can be expressed using conditional expressions such as the ternary operator ? or conditional structures such as the if or switch-case statements.

// using ternary operator
const main = data => html`
    ${data.text ?
        html`<p>${data.text}</p>` :
        html`<img src=${data.image}></img>`}`;

// using if
const main = data => {
    if (data.text) {
        return html`<p>${data.text}</p>` :
    } else {
        return html`<img src=${data.image}></img>`;
    }
}

// using switch-case
const main = data => {
    switch (data.screenSize) {
    case 's':
        return html`<img src="${data.image}-small.png"></img>`;
    case 'm':
        return html`<img src="${data.image}-medium.png"></img>`;
    case 'l':
        return html`<img src="${data.image}-medium.png"></img>
                    <img src="${data.logo}.png"></img>`;
    default:
        return html`<p>${data.text}</p>`;
    }
}

Iterations

It is very common for a part of a template to be repeated with different values. Think of a list, where the part that paints each item is always the same but with different values. For these cases we have already seen that it is possible to make a binding to expressions that return iterables from TemplateResult objects. This is the way we can repeat parts or blocks in a template.

const weekDays = ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Staurday', 'Sunday'];

// loops with arrays
html`<ul>${weekDays.map((day) => html`<li>${day}</li>`)}</ul>`;

// loop statement (better if DOM node update is cheap)
const itemTemplates = [];
for (const day of weekDays) {
  itemTemplates.push(html`<li>${day}</li>`);
}
html`<ul>${itemTemplates}</ul>`;

/*************************************
* We'll see the use of directives 
* in a future post !!
*************************************/
// repeat directive (better if moving DOM node is cheap)
html`<ul>${repeat(weekDays, day => day /*id*/, (day, index) => html`<li>${day}</li>`)}</ul>`;

Setting things up

lit-html is distributed as a npm package so to install it run the command:

npm install --save lit-html

lit-html uses JavaScript modules therefore to use the html and render functions we have to import them from the module.

At the moment, browsers don't import ES6 modules using the short syntax:

import {html, render} from 'lit-html'

We should write the full path to the module

import {html, render} from './node_modules/lit-html/lit-html.js'

But if you want to use the short syntax you can use a built tool such as Webpack or you can install the Polymer command line tool that can handle the short syntax import when it serves the application.

With Polymer CLI:

## install it
npm install -g polymer-cli

## use it
polymer serve

You're ready to start coding! I strongly recommend you to experiment and try your own examples. The best way to learn is by doing!

Conclusion

As we have seen, a template is pure JavaScript code so any expression and valid structure of the language can be used inside the template. There are so many ways to define a template that is only limited by the preferences or styles of each developer. The result is that the templates turn out to be tremendously expressive and because it is just JavaScript you don't need to learn nothing new.

lit-html templates from zero to hero for beginners

Julio Castillo Anselmi — Mon, 17 Jun 2019 20:33:02 +0000

📣 UPDATE! 📣
Now lit-html and LitElement are unified under Lit.
I'm writing new posts about Lit, meanwhile you can:

read this post because the principles are the same

upgrade your code with this guide

visit Lit site to know what's new

You can also use lit-html standalone

After a very smooth introduction to lit-html, I will go hard and get my hands dirty. I will show you how to write templates so this will be a session full of code!

I know you are here because you want to learn LitElement, so you read this title and find out that we continue with lit-html. The reason why I've structured these sessions this way is because lit-html is the basis for LitElement and also because I want you to see the great potential and versatility of lit-html by itself, probably the perfect match for a small or medium project. I assure you that everything you learn about lit-html will be used in LitElement. Be patient, we will arrive soon.

Setting things up

First of all, we'll create a project where you'll be able to try each example you see here. I also suggest you make changes, experiment and create your own examples. The best way to learn is by doing.

We create the project:

mkdir lit-train
cd lit-train
npm init --yes

The last command creates the package.json file that we'll use to handle the dependencies.

The next step is to install lit-html using npm.

npm install --save lit-html

At the moment, browsers don't import ES6 modules using the short syntax:

import {html, render} from 'lit-html'

We must write the full path to the module

import {html, render} from './node_modules/lit-html/lit-html.js'

So, to use the short syntax we'll install polymer-cli. The Polymer command line tool is able to serve our project and at the same time it handles the short syntax import. To do that just run the command polymer serve. To make things easier we'll install polymer-cli in our local project and in our package.json will add a script to run it.

npm install --save-dev polymer-cli

package.json

{
  "name": "lit-train",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "polymer serve"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Create an index.html file and write in it this code:

index.html

<!DOCTYPE html>
<html lang="en">
<body>
  <div id="main"></div>
  <script type="module">
    import {html, render} from 'lit-html.js';

    // write your code here

  </script>
</body>
</html>

To run the project execute this command:

npm run start

You're ready to start coding! Now you can continue reading and trying the examples in the project that you've just configured.

Writing templates

This is a very simple example:

// import functions from lit-html library
import {html, render} from 'lit-html';

// define the template as function that takes the data
// and returns a TemplateResult object
const template = name => {
  return html`
    <p>Hello ${name}</p>
  `;
};

// node where the template will be rendered
const mainNode = document.getElementById('main');

// render the template
render(template('Silvia'), mainNode);

// render the template again with different data
render(template('Benjamin'), mainNode);

The dynamic parts of a template are JavaScript expressions that are binded with values. TemplateResult supports bindings of certain data types that we will see now.

Supported bindings

Text: An expression that is resolved as text can be used as the text content of a node. Be aware that an empty string ('') in a text binding will render an empty text node.

// Text binding
html`<p>${someText}</p>`;
html`<div>${capitalize(user.name, user.firstName)}</div>`;

/**** Given these variables and values... ***************

let someText = 'Lorem ipsum';
let user = { name : 'JEN', firstName: 'MONROE' };  

***** The code above will render... *********************

<p>Lore ipsum</p>
<div>Jen Monroe</div>
*********************************************************/

Attribute: an expression that returns a text can be used as the value of an attribute.

// Attribute binding
html`<div class=${classList}>Stylish text.</div>`;

/**** Given these variables and values... ****************

let classList = ['main', 'required', 'modern'].join(' ');

***** The code above will render... ***********************

<div class="main required modern">Stylish text.</div>
***********************************************************/

When an attribute behaves like a boolean (it is present or not) we denote it with the name of the attribute preceded by ?. The value of the expression must be boolean, if it is true lit-html puts the attribute and if it is false it removes it.

// Attribute binding (boolean)

html`<input type="submit" ?disabled=${formWithErrors} value="Submit">
     <span ?hidden=${!formWithErrors}>Form has errors!</span>`;


/**** Given these variables and values... *****************

let formWithErrors = true;

***** The code above will render... ***********************

<input type="submit" disabled value="Submit">`;
<span>Form has errors!</span>`
***********************************************************/

Property: An expression can also be binded to a JavaScript node's property. We write the property name with a . at the beginning. In that case, the type of expression must match the type of the property (it could be any type even a complex object).

// Property binding
html`<custom-list .items=${users} id="user-list"></custom-list>`;

/**** Given these variables and values... ****************

const users = ['Diego', 'Ana', 'Laura', 'Piero'];
const customList = document.getElementById('user-list');
console.log(customList.items);

***** The code above will show in console *****************

 ["Diego", "Ana", "Laura", "Piero"]

***********************************************************/

Event: An expression can be the handler of an event. For this we write the event name preceded by @ and in this case we have several alternatives for the binding.

Global handler function: the expression resolves to a global function that will handle the event.

// Event binding to a global handler function
html`<button @click=${handleClick}>Click Me!</button>`;

Inline function: the expression resolves to an inline function.

html`<button @click=${()=>console.log('clicked')}>Click Me!</button>`;

Instance function: the expression resolves to a function that belongs to your object.

html`<button @click=${this.handleClick}>Click Me!</button>`;

Event listener object: the expression returns an object that must have a function named clickHandler.

html`<button @click=${clickHandler}>Click Me!</button>`;

const clickHandler = {
  handleEvent(e) { console.log('clicked!'); }
};

HTML node element: the expression can return a DOM node.

const h1 = document.createElement('h1');
h1.textContent = 'Chapter 1'
const page = html`${h1}<p>Once upon a time...</p>`;

/***** The code above will render... **********************

<h1>Chapter 1</h1>
<p>Once upon a time...</p>
***********************************************************/

TemplateResult: the expression can be another TemplateResult object. This makes it possible to have composition of nested templates.

const header = html`<h1>Chapter 1</h1>`;
const article = html`<article>${header}<p>Once upon a time...</p></article>`;

/***** The code above will render... **********************

<article>
  <h1>Chapter 1</h1>
  <p>Once upon a time...</p>
</article>
***********************************************************/

Iterable of TemplateResult objects: expressions that returns an array or iterables of TemplateResult objects.

const items = [1, 2, 3];
const listItems = items.map(i => html`<li>${2*i}</li>`);
const template = html`<ul>${listItems}</ul>`;

/***** The code above will render... **********************

<ul>
 <li>2</li>
 <li>4</li>
 <li>6</li>
</ul>
***********************************************************/

Promise: the expression can return a promise that must be resolved returning a valid binding value.

const text = fetch(url).then(response => response.text());
const page = () => html`<p>${text}</p>`;

/***********************************************************
Let's say that after some seconds the fetch operation 
resolves with a the string 'some text...'

Until the promise is resolved, the code above will render
<p></p> 

Once the promise is resolved, it will render...
<p>some text...</p>

***********************************************************/

Composition

One consequence of having bindings to expressions that return TemplateResult objects is that by composition we can create templates using other templates. The composition allows:

Create a complex template using simpler templates.
Refactor a complex template by diving it into simpler templates.
Reuse of templates (the use of JavaScript modules makes reuse much easier, for example, a module of common templates, partial templates, etc.)

const header = data => html`
    <h1>${data.title}<h1>
    ${data.subtitle ? html`<h2>${data.subtitle}<h2>` : ''}`;


const main = data => html`<p>${makeParagraph(data.text)}</p>`;

const composedTemplate = data => html`
    ${header(data)}
    ${main(data)}`;

Conditionals

// using ternary operator
const main = data => html`
    ${data.text ?
        html`<p>${data.text}</p>` :
        html`<img src=${data.image}></img>`}`;

// using if
const main = data => {
    if (data.text) {
        return html`<p>${data.text}</p>` :
    } else {
        return html`<img src=${data.image}></img>`;
    }
}

// using switch-case
const main = data => {
    switch (data.screenSize) {
    case 's':
        return html`<img src="${data.image}-small.png"></img>`;
    case 'm':
        return html`<img src="${data.image}-medium.png"></img>`;
    case 'l':
        return html`<img src="${data.image}-medium.png"></img>
                    <img src="${data.logo}.png"></img>`;
    default:
        return html`<p>${data.text}</p>`;
    }
}

Iterations

const weekDays = ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Staurday', 'Sunday'];

// loops with arrays
html`<ul>${weekDays.map((day) => html`<li>${day}</li>`)}</ul>`;

// loop statement (better if DOM node update is cheap)
const itemTemplates = [];
for (const day of weekDays) {
  itemTemplates.push(html`<li>${day}</li>`);
}
html`<ul>${itemTemplates}</ul>`;

/*************************************
* We'll see the use of directives 
* in a future post !!
*************************************/
// repeat directive (better if moving DOM node is cheap)
<ul>${repeat(weekDays, day => day /*id*/, (day, index) => html`<li>${day}</li>`)}</ul>`;

Conclusion

LitElement series: I need your help!

Julio Castillo Anselmi — Mon, 17 Jun 2019 20:32:25 +0000

📣Hi Dev people!

This is the first time I make a series of posts and I have doubts on how to face it. Do I write detailed articles step by step explaining everything or is it better to explain briefly the basics but focusing on complex topics and things that are not obvious and aren't in the official documentation? Do I write for newbies or for those already initiated?

The posts for beginners are longer and can be boring for those who already have some experience, but they explain all the details and do not take anything for granted.
On the other hand, posts with an intermediate level are shorter and go straight to the point, but they can be more difficult to understand for those who are starting to develop. They would rely less on words, and more on code samples with comments. They are easy to use as a reference.

As these posts have to be useful and of interest to you I ask you:

Girls and guys, what do you prefer???

Posts for beginners developers
Posts for experienced developers

For this time, the second post for the LitElement series goes in two flavours. Please 🙏 read them and tell me your opinion!

Thank you!

A gentle introduction to lit-html

Julio Castillo Anselmi — Tue, 04 Jun 2019 18:12:48 +0000

📣 UPDATE! 📣
Now lit-html and LitElement are unified under Lit.
I'm writing new posts about Lit, meanwhile you can:

read this post because the principles are the same

upgrade your code with this guide

visit Lit site to know what's new

You can also use lit-html standalone

Hello! I start my blog with a series of LitElement entries. I'll start with the most basic concepts and then I'll go deeper into the details of the use of this library. As LitElement is based on lit-html the first step will be the study of lit-html. I hope you like it and find it useful.

lit-html is an HTML templating library made by the Polymer team. This library stands out for being simple, very small, extremely efficient in terms of speed and use of resources, and all this is because it is based on web standards.

A very important point to note is that lit-html doesn't define any component model and therefore can be used in any project with other frameworks or libraries.

So what is a template?

Think of a payment receipt, it's a pice of paper that has written words and spaces to fill in. It has a text part that is always the same and other parts that can vary. It could be something like this:

Date: ___/___/___
Received from ___________, the amount of $__________
for _____________________________________________
Received by: __________________

This template can be printed and used many times filling in the blanks with the data of each payment.

And what is an HTML template?

Think of a piece of HTML code that has some parts to fill in, the content of those parts can change but the rest remains always the same, so the HTML code has static parts and dynamic parts (the gaps to fill in).

If the above receipt template had been written using HTML it could be:

<div>
  <p>Date: <span> ______</span></p>
  <p>Received from <span> ______ </span>, 
     the amount of <span> $ ______ </span> </p>
  <p> for <span> _______ </span></p>
  <p> Received by: <span> _______ </span></p>
</div>

lit-html lets you define an HTML template like the one above so that it can be rendered and reused with different values in the dynamic parts. This is not something new, there are other libraries like MoustacheJS or HandlebarJS that do the same, but lit-html is special because it does it in a very, very efficient way. Why so efficient? Well, the usual approach is to parse the template and then render the HTML in a DOM node with the new values in the changing parts. Every time the dynamic parts change, a parsing and rendering process is needed. The cost of re-rendering the DOM is high because it replaces the old node with the new node. lit-html is efficient because it doesn't parse the template and it only renders the HTML in the DOM once, just the first time. It also remembers where the dynamic parts are so that when a value of these parts changes lit-html just has to directly access that part and update the value in the DOM (normally it will be just text content, although it could also be a node).

lit-html is extremely efficient because it uses features of the web platform that are implemented natively in browsers. These characteristics are:

Tagged template literals of JavaScript.
HTML template tag.

The use of these features makes the library small and fast because it doesn't need to implement the parsing of the string templates. It's done by JavaScript natively.

The creation of the DOM represented by the template is also efficient, since it does so through the <template> tag, cloning its content.
Therefore, using what the platform offers, lit-html doesn't have to resort to the use of ad-hoc languages like JSX that requires extra processing, nor create complex solutions like a virtual DOM.

How to define a template?

Too many words so far, let's see how a template is defined in lit-html.

html`
  <div>
    <p>Date: <span>${data.date}</span></p>
    <p>Received from <span>${data.title} ${data.name} ${data.surname} 
    </span>, the amount of <span> ${data.amount}</span> </p>
    <p> for <span> ${data.concept} </span></p>
    <p> Received by: <span> ${data.receiver} </span></p>
  </div>`

Here we have a template literal tagged with a function called html. This is one of the two functions provided by lit-html.
As I said before, lit-html uses tagged template literals to define a template. These strings contain normal HTML code, there is nothing special, except for the tag function and the marks with ${}.

Enclosed in ${} are JavaScript expressions that when interpolated are replaced by the results of evaluating them. Also, when JavaScript finds a tagged template literal it processes the string (kind of parsing task) and pass it to the tag function. As you can see, it's all pure JavaScript's work, there's no need for anything else (I mean, not like JSX).

That's what a template in lit-html looks like. To make it useful we can define a function that takes the data that will be applied inside the template literal and it will return a ResultTemplate object (it is what the html tag function produces but we don't need to go into detail now, I'll talk about it in a future post).

const receiptTemplate = (data) => html`
<div>
  <p>Date: <span>${data.date}</span></p>
  <p>Received from <span>${data.title} ${data.name} ${data.surname} 
  </span>, the amount of <span> ${data.amount}</span> </p>
  <p> for <span> ${data.concept} </span></p>
  <p> Received by: <span> ${data.receiver} </span></p>
</div>`

Now that we have the template definition we can use it many times with different values.

receiptTemplate(myData);
receiptTemplate(otherData);

What about rendering the template?

We have seen how to define a template, now we'll see how to render it. This is the easiest part. For this we'll use the other function provided by lit-html: the render function.

render requires two mandatory arguments: the first is the TemplateResult object to render and the second is the DOM node where the template will be placed. The third argument is optional and is an object that contains additional options (for now you do not have to know this).

const templateResult = receiptTemplate(myData);
render(templateResult, document.getElementById('mainContent'));

Recap

lit-html is a simple, modern, safe, small and fast HTML templating library for JavaScript.
It can be used in any project.
It's based on web standards.
It's framework agnostic.
It provides two functions: html and render.
html is used as a tag in front of the template literal that defines the HTML template.
html returns a TemplateResult object.
render is the function used to render the template in the DOM.
render receives a TemplateResult object and a node where to place the template.

This is all the basic, minimum and elementary you should know to use this modern library. In the next post I will show you how to install lit-html and explain in detail how to write complex templates. Until next time!