
El desarrollo móvil rápido requiere que adoptemos flujos de trabajo de integración continua. La parte más difícil de las pruebas automatizadas en dispositivos móviles es la punta de la pirámide de pruebas, las **pruebas E2E (de extremo a extremo)**.

Las pruebas E2E, cuando se realizan manualmente, **requieren mucho tiempo, son repetitivas y aburridas**. A veces, también pueden ser **no deterministas**, dependiendo de operaciones asincrónas que pueden tener lugar en un orden diferente en tu aplicación. Otra dificultad es que no hay muchas opciones para realizar pruebas E2E automatizadas usando React Native.

En esta publicación, presentaré [Detox](https://github.com/wix/Detox) como una herramienta para realizar pruebas de extremo a extremo para React Native. Detox nos ayuda a reducir nuestra dependencia del QA manual.

Detox prueba tu aplicación móvil mientras se ejecuta en un dispositivo/simulador real, interactuando con ella como un usuario real.

La filosofía de Detox promueve las pruebas de caja gris en lugar de las pruebas de caja negra:

- **Black Box Testing:** Técnica de testeo de software en la que el evaluador no conoce la estructura interna, el diseño y la implementación de la aplicación de software que se está probando.
- **Gray Box Testing:** Técnica de testeo de software que es una combinación de la técnica de Black Box Testing y la técnica de White Box Testing. La estructura interna, el diseño y la implementación se conocen parcialmente en Gray Box Testing.

En teoría, suena mejor probar exactamente lo que despliegas como una caja negra. En la práctica, cambiar a caja gris permite que el marco de prueba controle la aplicación desde el interior y proporciona mejoras importantes, como luchar contra los problemas de determinismo.

Detox está construido desde cero para soportar proyectos React Native, así como proyectos nativos puros. Actualmente es compatible con las versiones React Native <= 0.64.

## Instalación

El setup completo de Detox se describe en este link:

https://github.com/wix/Detox/blob/master/docs/Introduction.GettingStarted.md

Repasaremos los pasos principales que debe seguir un desarrollador para usar Detox, con el fin de crear y ejecutar las descripciones de las pruebas. También se puede configurar para ser utilizado como parte del pipeline de CI.

**Detox CLI** debe instalarse globalmente:

```sh
# Install detox globally
npm install -g detox-cli
```

Algunas librerías deben ser añadidas al `package.json` de nuestra app de React Native.

- Añadir `detox` como dependencia de desarrollo
- Añadir o actualizar `jest` a jest@^27.0.0

```sh
# Add detox as dev dependency
yarn add detox --dev

# Upgrade jest
yarn add jest@^27.0.0 --dev
```

Ahora lanzar el script de inicialización automático:

```
# Init detox
detox init -r jest
```

Dicho script crea varios archivos:

- Un archivo `.detoxrc.json`.**(\*)**
- Una carpeta `e2e/` en la raiz del proyecto
- Un archivo `e2e/config.json`
- Un archivo `e2e/environment.js`
- Un archivo `e2e/firstTest.e2e.js`

**(\*) NOTA** Las propiedades `build` y `binaryPath` tanto para la app de iOS como para la de Android en este archivo no están definidos.

Algunos parámetros en `.detoxrc.json` deben ser definidos o modificados. En particular, las propiedades `build` y `binaryPath` faltan o tienen placeholders, y también `avdName` y `testBinaryPath` en Android. Los siguientes valores funcionan en iOS (hasta cierto punto también para Android, pero en el momento de escribir este artículo hay algunos problemas que impiden que funcione completamente):

```json
{
  "testRunner": "jest",
  "runnerConfig": "e2e/config.json",
  "skipLegacyWorkersInjection": true,
  "apps": {
    "ios": {
      "build": "xcodebuild -workspace ios/pushdemo.xcworkspace -scheme pushdemo -configuration Debug -sdk iphonesimulator -derivedDataPath ios/build",
      "type": "ios.app",
      "binaryPath": "ios/build/Build/Products/Debug-iphonesimulator/pushdemo.app"
    },
    "android": {
      "build": "cd android && ./gradlew assembleAndroidTest -DTestBuildType=debug && cd ..",
      "type": "android.apk",
      "binaryPath": "android/app/build/outputs/apk/debug/app-debug.apk",
      "testBinaryPath": "android/app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk"
    }
  },
  "devices": {
    "simulator": {
      "type": "ios.simulator",
      "device": {
        "type": "iPhone 11"
      }
    },
    "emulator": {
      "type": "android.emulator",
      "device": {
        "avdName": "Pixel_3a_API_30_x86"
      }
    }
  },
  "configurations": {
    "ios": {
      "device": "simulator",
      "app": "ios"
    },
    "android": {
      "device": "emulator",
      "app": "android"
    }
  }
```

### Pasos específicos para Android

Sigue este enlace para comprobar que existe el entorno apropiado con Java, SDK de Android y emuladores AOSP:

https://github.com/wix/Detox/blob/master/docs/Introduction.AndroidDevEnv.md

Actualmente, Android tiene algunos problemas. El build de Detox funciona pero los tests de Detox no. Hay muchas issues abiertas en el proyecto Detox relacionadas con Android, por lo que probablemente tendremos que esperar para verlo funcionar con la versión actual.

Por otro lado, pude descargar el ejemplo de React Native de Detox y ejecutar las pruebas de Android. No pude traducir los pasos exactos necesarios para trabajar en mi proyecto demo, ni encontré esos pasos en la documentación, pero supongo que podría lograrse trabajando más en ello.

### Pasos específicos para iOS

Sigue este enlace para comprobar que existe un entorno apropiado con las herramientas de línea de comandos de XCode y las utilidades del simulador:

https://github.com/wix/Detox/blob/master/docs/Introduction.iOSDevEnv.md

## Construyendo y corriendo los tests

Cuando se usa Detox con Jest como test runner, los tests son muy similares a los tests unitarios. Deberíamos configurarlos para que tengan una extensión diferente a las pruebas unitarias, es decir, `*.e2e.js` y `*.e2e.ts` serían una buena opción.

Los tests de Detox utilizan un campo `testID` en los templates JSX para hacer coincidir un determinado elemento por ID. Por ejemplo, podemos escribir una prueba como esta para comprobar que se muestra una determinada Vista o texto.

```javascript
it('should show a title and a description', async () => {
  await expect(element(by.id('title'))).toBeVisible();
  await expect(element(by.id('description'))).toBeVisible();
});
```

Ahora el JSX debería incluir dichos atributos `testID`, así:

```javascript
<View>
  <View>
    <Text testID="title">E2E testing with Detox</Text>
    <Text testID="description">
      This app is testeable with Detox. Push the button to display a greeting
      message.
    </Text>
    {isMessageVisible && <Text testID="message">Hello world!</Text>}
  </View>

  <View>
    <Button testID="message_button" title="Say Hello" onPress={buttonHandler} />
  </View>
</View>
```

La especificación de test puede activar botones, escribir texto dentro de los campos de entrada, etc. Por ejemplo, la siguiente prueba comprueba que aparece un texto en un contenedor después de hacer clic en un botón.

```javascript
it('should show a hello world message after tapping the button', async () => {
  await element(by.id('message_button')).tap();
  await expect(element(by.id('message'))).toBeVisible();
  await expect(element(by.text('Hello world!'))).toBeVisible();
});
```

Para ejecutar los tests, debemos construirlos con Detox y luego ejecutarlos. Estos comandos también se pueden incluir en `package.json` para facilitar su uso con `npm` o `yarn`.

```sh
# build and test for ios
detox build -c ios
detox test -c ios

# build and test for android
detox build -c android
detox test -c android
```

Después de ejecutar los tests, obtenemos una lista de los tests que pasan y los que fallan, como es habitual con el test runner de jest.

```sh
  App
    ✓ should show a title and a description (1029 ms)
    ✓ should show a hello world message after tapping the button (1377 ms)

  2 passing
```

Así es como se ejecuta el test E2E en un simulador:

![E2E test run](/img/blog/2021-10-31_e2e-testing-in-rn-with-detox/detox_e2e_test.gif)

Puedes encontrar el código fuente de este post en:

https://github.com/jguix/detox-demo

## Más sobre testeo en React Native

Durante el trabajo en este post encontré útil la información contenida en este sitio, además de la documentación oficial de Detox:

https://reactnativetesting.io/e2e/intro.html

Cubre pruebas unitarias, pruebas de componentes, pruebas de extremo a extremo e integración continua para proyectos React Native. La documentación es bastante sencilla y llena algunos de los huecos de la documentación de Detox.

## Créditos

Foto por [Joshua Mayo](https://unsplash.com/@mayofi) en [Unsplash](https://unsplash.com).


En esta publicación, presentaré Detox como una herramienta para realizar pruebas de extremo a extremo para React Native. Detox nos ayuda a reducir nuestra dependencia del QA manual.

Testeo de extremo a extremo en React Native con Detox


Hoy comienzo un nuevo proyecto. Lo llamaré por ahora _"No Más Colas"_ pero podría tener dudas sobre eso una vez que haga una investigación de UX.

El objetivo del proyecto es **poner en práctica lo que aprendí** en algunos tutoriales de Udemy que completé recientemente, o estoy a punto de terminar, dedicados a NextJS y Flutter. También estoy tratando de **encontrar una solución para el prototipado rápido de aplicaciones**, creando MVP que sean simples pero todavía escalables. Y finalmente, creo que puedo **ayudar a otros en el proceso**. Quizás las personas que ya son competentes en JavaScript puedan seguir mis pasos para crear una aplicación diferente, o incluso ayudarme cuando me atasque en algo.

Escribiré en el blog sobre el proceso para ayudarme a reflexionar sobre las cosas que aprendí. Creo que **la práctica es completamente necesaria para aprender realmente**. Así, generalmente no me quedo satisfecho con ver los videos, sino que también sigo los pasos por mí mismo. Considero que esto es el _"nivel básico de práctica"_, por así decirlo. El siguiente nivel llega cuando **pruebas algo diferente aplicando lo que has aprendido**. Y si eres capaz de **resumir, sintetizar, escribir sobre el tema o enseñar a otras personas**, entonces podrás aprenderlo más a fondo.

A alguien le habrá chirriado escuchar que la pila técnica para este proyecto será NextJS + Flutter. Si vas a usar React, ¿por qué no usar React Native para dispositivos móviles? o ¿por qué no crear una PWA? O al revés, ¿por qué no crear todo en Flutter + Flutter web?

La verdad es que ya he sufrido suficientes problemas con React Native y quiero probar algo nuevo. Con suerte, Flutter proporcionará una mejor experiencia de desarrollador -durante el tiempo que lo he estado probando, lo hace- y me dará lo suficiente para crear un proyecto simple. No quiero usar PWA porque quiero que mi aplicación esté en las tiendas de aplicaciones. Por otro lado, no confío mucho en Flutter web por ahora. No conozco sitios de producción donde lo usen y no recomendaría a mis clientes que lo hagan, así que por ahora lo dejaré fuera de la ecuación.

Ese es el _por qué_, pero falta el _qué_. **Voy a crear un sitio web y una aplicación móvil para administrar colas**, no colas de mensajes o colas de eventos, sino **colas en la vida real con personas en una fila**. Básicamente, la aplicación permitirá que alguien ponga en marcha un sistema de colas, donde el usuario podrá obtener información a través de la aplicación sobre cuántas personas hay delante de él, el tiempo de espera estimado y notificaciones cuando se acerque su turno.

Creo que esto puede resolver un problema que ha existido durante mucho tiempo, pero que incluso ha empeorado después del COVID. **Nunca nos gustó esperar mucho tiempo en una fila**. Ahora, con el COVID, **ni siquiera es seguro hacerlo**. Tener un grupo de personas en un espacio cerrado durante mucho tiempo ya no es deseable, y podría haber restricciones o cuotas para en relación a ello. Con esta aplicación, un usuario puede elegir su turno -algo que incluso podría hacerse de forma remota- y luego, si el tiempo estimado es largo, puede simplemente irse de compras un rato, esperar en casa o tomar un café en algún lugar, mientras avanza la cola.

El sitio web manejará el backoffice para el sistema de colas y un sitio frontend para mostrar en el lugar, donde los usuarios podrán ver las siguientes ID de cola que serán atendidas y donde pueden obtener su ID de cola.

La aplicación móvil será la encargada de leer este ID e informar al usuario sobre su posición en la cola y tiempos estimados.

**En el próximo post crearé la aplicación NextJS con soporte typescript**. Seguid atentos para ver crecer esta aplicación.

## Créditos

Foto por [Zichao Zhang](https://unsplash.com/@shakusky) en [Unsplash](https://unsplash.com).


Hoy comienzo un nuevo proyecto. Lo llamaré por ahora _"No Más Colas"_ pero podría tener dudas sobre eso una vez que haga algo de investigación de UX.

Inicio del proyecto "No Más Colas"


En este post presentaré algunos trucos que he aprendido al crear demos para publicaciones de blogs y PoC. Aprenderás a configurar una API usando JSON-server y desplegarlo en el mismo sitio Heroku que la aplicación frontend. También aprenderás a utilizar Faker para generar datos falsos para JSON-server.

A menudo he usado [JSON-server](https://github.com/typicode/json-server) para crear rápidamente una simple API como backend para una demo o prueba de concepto. No me malinterpretes: no estoy animando a nadie a usar esto como servidor de producción, sino solo para ese tipo de proyectos pequeños.

`JSON server` proporciona una API REST completa desde un único archivo `db.json`, que incluye rutas `GET`, `POST`, `PUT`, `PATCH` y `DELETE` para obtener y modificar tus entidades.

En este escenario suelo encontrar dos problemas:

1. Tener suficientes datos. Si creas los datos JSON manualmente, te cansarás después de haber creado 10 entidades. Imagínate si necesitas cientos de entidades con diferentes modelos.

2. Servir los datos. Si deseas implementar tu demo en Heroku, necesitas un sitio para alojar tu aplicación y un segundo para alojar la API.

Con respecto al primer problema, usaremos [Faker](https://github.com/marak/Faker.js) para crear programáticamente el archivo `db.json`. Esto también simplificará la modificación de los modelos, es decir, si el modelo cambia, no es necesario cambiar manualmente varios cientos de entidades.

En cuanto al segundo, usaremos `concurrently` para lanzar las aplicaciones frontend y backend en diferentes puertos, y agregaremos configuraciones específicas para Heroku.

## Inicialización de la app

Para este post vamos a generar una app react de ejemplo. Podríamos hacer configuraciones similares con otros frameworks Javascript.

Creamos una app react con template typescript:

```bash
npx create-react-app json-server-demo --template typescript
```

Vamos a añadir `json-server`, `concurrently` y `axios` como dependencias, y `faker` como dependencia de desarrollo del proyecto:

```bash
yarn
yarn add json-server concurrently axios
yarn add --dev faker
```

Probamos nuestra app de ejemplo:

```bash
yarn start
```

Abre el navegador en [http://localhost:3000/](http://localhost:3000/) y podrás ver la app React de ejemplo.

## Creando la API

Nuestra app de ejemplo mostrará una lista de empleados, con su nombre, email y residencia.

Crearemos un fichero `db.json` con `faker` con no menos de 1000 empleados, porque pensamos a lo grande 😏

Crea un fichero en la carpeta `src/db/index.json` con el siguiente contenido:

```javascript
var fs = require('fs');
var faker = require('faker/locale/es');
faker.locale = 'es';

let employees = [];

for (let i = 1; i <= 1000; i++) {
  const firstName = faker.name.firstName();
  const lastName = faker.name.lastName();
  employees.push({
    address: `${faker.address.streetAddress()}, ${faker.address.zipCode()}, ${faker.address.city()}, ${faker.address.country()}`,
    email: faker.internet.email(firstName, lastName),
    id: i,
    name: faker.name.findName(firstName, lastName),
  });
}

const data = {
  employees,
};

fs.writeFile('src/db/db.json', JSON.stringify(data, null, 2), (err) => {
  if (err) return console.log(err);
  console.log('Created database at src/db/db.json');
});
```

El código es fácilmente legible. Este script creará un archivo `src/db/db.json` con 1000 empleados, generando `name`, `address` e `email` aleatorios para cada empleado. La configuración regional utilizada es `"es"`, esto es, los nombres y correos electrónicos se crearán en español. Presta atención a cómo se crean los campos `name` e `email` usando el mismo `firstName` y `lastName`, para que sean coherentes.

Ahora añadimos el siguiente script a la sección `"scripts"` en el `package.json`:

```json
  "create-db": "node src/db/index.js",
```

Para correr el script, simplemente ejecuta:

```bash
yarn create-db
```

Y ya estamos listos para crear la API `json-server` con nuestra flamante nueva base de datos JSON de empleados.

Podemos probarlo ahora mismo desde la línea de comandos. Usaremos la opción `--port` para configurarlo en el puerto 3001, de modo que no entre en conflicto con nuestra app react que ya se está ejecutando en el puerto 3000:

```bash
json-server src/db/db.json --port 3001
```

Si abres [http://localhost:3001/employees](http://localhost:3001/employees) en tu navegador podrás ver la lista completa de empleados.

```json
[
  {
    "address": "92349 Hurtado Ramal, 88648, Fuengirola Alejandrotown, Gabón",
    "email": "JosEmilio57@gmail.com",
    "id": 21,
    "name": "José Emilio Pizarro"
  },
  {
    "address": "536 Margarita Ronda, 45257, Las Vegas, Eslovenia",
    "email": "Dorotea_Ocasio72@hotmail.com",
    "id": 22,
    "name": "Dorotea Ocasio"
  },
  {
    "address": "69354 Candelaria Chalet, 17110, Archuletaburgh, Sri Lanka",
    "email": "Benjamn_Menchaca65@yahoo.com",
    "id": 23,
    "name": "Sta. Benjamín Menchaca"
  },
  ...
]
```

Puedes también probar varias URLs con parámetros, como paginación o búsqueda completa de texto:

http://localhost:3001/employees/1

http://localhost:3001/employees?\_page=3&\_limit=10

http://localhost:3001/employees?q=Pedro

## Consumiendo la API

Crearemos una simple app que presenta un cuadro de búsqueda y una lista de resultados. Omitiremos el contenido del archivo CSS, que solo agrega algunos estilos a la aplicación. Puedes encontrarlo en el repositorio que se encuentra al final de esta publicación.

```typescript
import React, { useEffect, useState } from 'react';
import axios from 'axios';
import './App.css';

type Employee = {
  address: string;
  email: string;
  id: number;
  name: string;
};

const App = () => {
  const [query, setQuery] = useState('');
  const [employees, setEmployees] = useState<Employee[]>([]);

  useEffect(() => {
    loadEmployees(1, 20);
  }, []);

  useEffect(() => {
    loadEmployees(1, 20, query.length > 2 ? query : '');
  }, [query]);

  const loadEmployees = async (page: number, limit: number, query = '') => {
    const url = `http://localhost:3001/employees?_page=${page}&_limit=${limit}&q=${query}`;
    const _employees = await axios
      .get<Employee[]>(url)
      .then(({ data }) => data);

    setEmployees(_employees);
  };

  return (
    <div className="App">
      <div className="search_form">
        <label className="search_form--label">Search employees</label>
        <input
          className="search_form--input"
          type="text"
          value={query}
          onChange={(event) => setQuery(event.target.value)}
        ></input>
      </div>
      <div className="employee_list">
        {employees.map((employee) => {
          return (
            <div className="employee_list--item">
              <div className="employee_list--item-name">{employee.name}</div>
              <div className="employee_list--item-address">
                {employee.address}
              </div>
              <div className="employee_list--item-email">{employee.email}</div>
            </div>
          );
        })}
      </div>
    </div>
  );
};

export default App;
```

Así se ve la aplicación.

![Demo application](/img/blog/2021-07_deploy-demo-with-api-heroku/demo_app.png)

## Mejorando la configuración de desarrollo

Hagamos algunos cambios para simplificar el ciclo de desarrollo. Agregaremos la configuración de `proxy` al `package.json`, para que las llamadas de red se redirijan al puerto 3001.

```json
  "proxy": "http://localhost:3001",
```

De este modo podemos simplificar la URL en `App.tsx`:

```typescript
const url = `/employees?_page=${page}&_limit=${limit}&q=${query}`;
```

Ahora podemos reiniciar la app y debería seguir funcionando.

Luego, usaremos `concurrently` para iniciar tanto el backend como el frontend desde un script de una sola línea. Reemplaza el script `start` de `package.json` por lo siguiente:

```json
    "start": "concurrently \"react-scripts start\" \"json-server --watch src/db/db.json --port 3001\"",
```

Ahora puedes parar el proceso del terminal corriendo `json-server src/db/db.json --port 3001`. Simplemente lanza el desde la raíz del proyecto:

```bash
yarn start
```

Y ya está todo listo.

## Desplegando en Heroku

Hacer que tanto el `json-server` como la app se ejecuten en la misma instancia de un servicio como Heroku es más complicado. Por lo general, harían falta dos sitios, uno para el frontend y otro para el backend.

Vamos a beneficiarnos del soporte para servir sitios estáticos de `json-server`.

Primero que nada, construyamos nuestra aplicación `react`.

```bash
yarn build
```

Esto generará una versión estática de la aplicación en `/build`. Luego elimina estas líneas de `.gitignore` para poder subir el sitio estático a nuestro repositorio remoto:

```bash
# production
/build
```

Crea un archivo `server.js` en la raíz del proyecto con el siguiente contenido:

```javascript
const jsonServer = require('json-server');
const server = jsonServer.create();
const router = jsonServer.router('src/db/db.json');
const middlewares = jsonServer.defaults({ static: './build' });
const port = process.env.PORT || 3000;

server.use(middlewares);
server.use(router);

server.listen(port);
```

Si detienes el script `yarn start` y ejecutas este script localmente, la app se ejecutará desde los archivos estáticos en el directorio `/build`, servida por `json-server`.

```bash
node server.js
```

Esto es exactamente lo que Heroku usará para servir tu aplicación usando un solo sitio.

Ahora, para decirle a Heroku que llame a este `node server.js` necesitas crear un archivo `Procfile` en la raíz de tu repositorio con el contenido:

```
web: node server.js
```

Y esa es toda la configuración que necesitas.

Omitiré la parte en la que debes crear una cuenta de Heroku, agregar una nueva aplicación y conectarla a tu repositorio de Github. Puedes encontrar muchos tutoriales sobre eso por ahí.

Puedes encontrar el código de esta demo en el siguiente enlace:

[https://github.com/jguix/json-server-demo](https://github.com/jguix/json-server-demo)

Y la app desplegada en Heroku:

[https://json-server-demo1.herokuapp.com](https://json-server-demo1.herokuapp.com)

## Netlify y Vercel

Desafortunadamente, no podemos hacer lo mismo en Netlify o Vercel. La razón es que estos servicios no nos permiten ejecutar comandos node, en su lugar deberías crear tu API utilizando funciones serverless. Por supuesto, también puedes alojar allí tu aplicación y tener la API en otro servicio, pero ese no era el objetivo de este artículo.

## Conclusión

Quería reunir todos los pasos que he aprendido creando y alojando apps simples con fines de demostración, incluyendo una API. Esto podría ayudarte a dar los primeros pasos de tu próximo proyecto, alojar una demo para una publicación de blog o impresionar a alguna empresa en una entrevista técnica.

## Créditos

Foto por Austin Neill en [Unsplash](https://unsplash.com/@arstyy).


En este post presentaré algunos trucos que he aprendido al crear demos para publicaciones de blogs y PoC. Aprenderás a configurar una API usando JSON-server y desplegarlo en el mismo sitio Heroku que la aplicación frontend. También aprenderás a utilizar Faker para generar datos falsos para JSON-server.

Desplegar una demo con una API JSON en Heroku


Esta publicación muestra cómo usar git hooks, para evitar commit o push bajo ciertas circunstancias, y particularmente cómo versionar esos git hooks.

Git hooks son una colección de disparadores que están vinculados a los comandos de git, como checkout, commit o push. Te permiten ejecutar un script antes/después de que se ejecute realmente el comando git y devuelven un código de salida. En el caso de git hooks que se ejecutan antes, si el código de salida no es cero, el comando git no se ejecutará.

Los git hooks deben usarse en un proyecto versionado con git, ya que no son más que scripts bash que viven en la carpeta `.git/hooks`. Hay hooks del lado del cliente y del lado del servidor. En esta publicación hablaremos sobre los hooks del lado del cliente.

Los git hooks del lado del cliente incluyen:

- **Hooks del Workflow de Commit.** Son hooks que tienen que ver con el proceso de commit: `pre-commit`, `prepare-commit-msg`, `commit-msg` y `post-commit`.

- **Hooks del Workflow de Email.** Usados para un workflow basado en email: `applypatch-msg`, `pre-applypatch` y `post-applypatch`.

- **Otros Hooks de Cliente.** Incluyen: `pre-rebase`, `post-rewrite`, `post-checkout`, `post-merge` y `pre-push`

No entraré en detalles sobre cuál es el uso de cada hook. Puedes encontrar más información sobre el propósito de cada hook y el escenario de activación en [Customizing-Git-Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks).

Solo mencionaré un ejemplo. Algunos proyectos requieren por convención que el mensaje de confirmación incluya un nombre de tarea JIRA, de modo que los miembros del equipo puedan rastrear fácilmente qué commit estaba vinculado a qué tareas en JIRA. Si los nombres de tus tareas de JIRA incluyen todos un prefijo como `PROJ`, eso se puede lograr con un hook `pre-commit` como este:

```sh
#!/bin/bash
MSG="$1"

if ! grep -qE "PROJ" "$MSG";then
    cat "$MSG"
    echo "Your commit message must contain the task name starting with 'PROJ'"
    exit 1
fi
```

La secuencia de comandos anterior devuelve un `1` si el mensaje del commit no incluye la palabra `PROJ`, y eso evitará que se ejecute el commit. Si el mensaje del commit lo incluye, como en `"PROJ-202 - Estilos CSS refactorizados"`, entonces se llevará a cabo el commit.

Quizás te estés preguntando, _"ok, pero cómo puedo almacenar los hooks en mi proyecto versionado con git si se encuentran dentro de la carpeta `.git`"_, y eso es realmente imposible. No puede hacer commit de archivos dentro de ese directorio. Deberías decirle a cada desarrollador de tu proyecto que los copie, o tener un script que copie los hooks, y luego decirle a todos que lo ejecuten. Nada práctico, ¿no?

## Versionado de git hooks en proyectos Javascript

En proyectos Javascript con un `package.json` podemos usar [Husky](https://typicode.github.io/husky) para ocuparnos de los git hooks y su control de versiones dentro del proyecto.

En primer lugar, debemos instalar Husky en el proyecto:

```sh
npx husky-init && yarn
```

Esto agregará un par de cosas en `package.json`:

- la dependencia de husky a nuestra sección `devDependencies`
- un script `prepare` en nuestra sección de `scripts`

La parte `yarn` instalará las dependencias y ejecutará el script `prepare`. Después de eso, se creará un directorio `.husky` en la raíz del proyecto que contiene un ejemplo de hook `pre-commit`, un archivo `.gitignore` y una carpeta `_` con el script `husky.sh`.

Con esa configuración no se necesita copiar manualmente los hooks en la carpeta `.git/hooks`: el script `husky.sh` se encargará de usar los hooks que se encuentran en la carpeta `.husky`.

Ahora puedes editar el hook de muestra `pre-commit`, eliminarlo o crear uno nuevo en la carpeta `.husky`, manualmente o mediante el comando bash `npx husky add`. Por ejemplo, si tuviéramos que crear un hook `pre-push` que ejecute `lint` y `test`, podríamos ejecutar:

```sh
npx husky add .husky/pre-push "yarn lint && yarn test"
```

El resultado será algo como:

```sh
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

yarn lint && yarn test

```

## Versionado de git hooks en proyectos Java con Maven

En cuanto a los proyectos Java administrados por Maven con un archivo `pom.xml`, no pude encontrar nada como Husky.

La mejor solución aquí fue usar el `maven-resources-plugin` para copiar los hooks de un directorio de origen `git-hooks` a la carpeta de destino `.git/hooks`.

Esto es lo que agregué a mi sección `build` en el `pom.xml`:

```xml
<build>
  <plugins>
    <plugin>
      <artifactId>maven-resources-plugin</artifactId>
      <version>3.2.0</version>
      <executions>
        <execution>
          <id>copy-hooks</id>
          <phase>validate</phase>
          <goals>
            <goal>copy-resources</goal>
          </goals>
          <configuration>
            <outputDirectory>${basedir}/.git/hooks</outputDirectory>
            <resources>
              <resource>
                <directory>git-hooks</directory>
              </resource>
            </resources>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
```

Después de eso, llamar al comando `mvn validate` o cualquier otro comando maven que llame a `validate`, como `package`, instalará los hooks en primer lugar.

## Ignorando git hooks

¿Qué pasa si tenemos un git hook que requiere mucho tiempo para ejecutarse y se interpone en nuestro camino para las tareas de programación diarias? Por ejemplo, si tuviéramos un hook `pre-commit` que lanzara nuestras pruebas unitarias y esas pruebas tardaran 30 minutos en ejecutarse, entonces cada vez que hiciéramos commit tendríamos que esperar todo ese tiempo. Es posible que queramos ejecutar las pruebas en el último commit antes del push, y no en cada commit, para ahorrarnos algo de tiempo.

En tales casos, podemos omitir los git hooks, si sabemos lo que estamos haciendo:

```sh
git commit --no-verify -m "An unverifed commit"
```

## Conclusión

Espero que este post te ayude a integrar git hooks en tus proyectos. Pueden ayudar a hacer cumplir algunas políticas y directivas para mejorar los estándares de calidad en tu equipo.

## Créditos

Foto por Anne Nygard en [Unsplash](https://unsplash.com/).


Esta publicación muestra cómo usar git hooks, para evitar commit o push bajo ciertas circunstancias, y particularmente cómo versionar esos git hooks.

Añadiendo git hooks

En esta serie de posts crearemos una aplicación usando react y redux, en la que manejaremos datos relacionales. En esta segunda parte implementaremos la store.

Usando redux con datos relacionales (2/3)


## Parte 1. Modelando la store de redux

En esta serie de posts crearemos una aplicación usando **react** y **redux**, en la que manejaremos datos relacionales. En esta primera parte modelaremos la store.

A menudo, los tutoriales sobre redux son demasiado simples y manejan una estructura de datos plana. Es el caso de la típica app de TODOs (lista de tareas), o una lista de la compra, etc. En estos casos solemos tener unos pocos reducers, los cuales son independientes entre sí.

Por ejemplo:

- La lista de TODOs, incluyendo el estado de cada tarea.
- El valor de un filtro de mostrar/ocultar, por ejemplo, "ocultar completas".
- El valor de un filtro de orden, por ejemplo, "ordenar por fecha de creación ascendente".

En un caso así de simple, la store no tiene que manejar relaciones, y se puede representar en un objeto similar a este:

```json
{
  "todos": [
    {
      "id": 1,
      "completed": true,
      "creationDate": "2020-08-07",
      "description": "Create github repo"
    },
    {
      "id": 2,
      "completed": false,
      "creationDate": "2020-08-11",
      "description": "Finish part 1 of this post"
    },
    {
      "id": 3,
      "completed": false,
      "creationDate": "2020-08-12",
      "description": "Create part 2"
    }
  ],
  "filterBy": "completed",
  "orderBy": "date-asc"
}
```

Sin embargo, las aplicaciones reales suelen ser más complejas. Algunos datos dependen de otros y existen jerarquías: relaciones uno a uno, uno a muchos y muchos a muchos. Esto nos va a presentar varios retos, tanto en la representación del estado en la store, como en la eficiencia de la comunicación con el backend.

Para ilustrarlo, usaremos el ejemplo de una red social. Las entidades principales que manejaremos son usuarios, posts y comentarios. Los usuarios podrán crear posts, y los posts podrán contener comentarios de otros usuarios. Simple, ¿verdad?

Veamos en primer lugar algunos de los diseños de nuestra red social, para modelar estos datos.

La página inicial de nuestra red social será **Mi Muro**, la página donde aparecen mis posts y los de todos mis amigos, con sus respectivos comentarios.

![My Wall](/img/blog/2020-08_redux-normalized-store-part-1/my_wall.png)

También habrá una página de **Amigos**, donde se listan los usuarios que son contactos directos míos.

![My Friends](/img/blog/2020-08_redux-normalized-store-part-1/my_friends.png)

Desde esta página, si pulso sobre uno de mis amigos visitaré el **Muro del amigo**, esto es, una página donde aparecerán sus posts, junto con los comentarios de otros usuarios.

![Friend Page](/img/blog/2020-08_redux-normalized-store-part-1/friend.png)

Cada post incluirá el avatar y nombre del usuario, y la fecha. Cada comentario incluirá también el avatar, nombre del usuario y la fecha.

![Posts and comments](/img/blog/2020-08_redux-normalized-store-part-1/post_and_comments.png)

Sin entrar en las relaciones o jerarquías, podemos definir los tipos de las entidades como usuario (`User`), post (`Post`) y comentario (`Comment`):

```typescript
// user.types.ts
export type User = {
  avatar: string;
  email: string;
  id: number;
  name: string;
};

// post.types.ts
export type Post = {
  body: string;
  date: Date;
  id: number;
};

// comment.types.ts
export type Comment = {
  body: string;
  date: Date;
  id: number;
};
```

Una representación extremadamente simple, basada en la aplicación de los TODOs, consiste en tener un reducer por cada tipo de entidad:

```json
{
  users: [
    { id: 1, name: "Josh", email: "josh@gmail.com", avatar: "josh.jpg" },
    { id: 2, name: "Anne", email: "anne@gmail.com", avatar: "anne.jpg" },
    { id: 3, name: "Mike", email: "mike@gmail.com", avatar: "mike.jpg" },
  ],
  posts: [
    {
      id: 1,
      body: "hi all",
      date: "2020-08-01",
      user: { id: 2, name: "Anne", email: "anne@gmail.com", avatar: "anne.jpg" },
    }
  ],
  comments: [
    {
      {
        id: 1,
        body: "hello!",
        date: "2020-08-02",
        user: { id: 1, name: "Josh", email: "josh@gmail.com", avatar: "josh.jpg" },
      },
      {
        id: 2,
        body: "hi there!",
        date: "2020-08-02",
        user: { id: 3, name: "Mike", email: "mike@gmail.com", avatar: "mike.jpg" },
      },
    }
  ],
}
```

Si entro en la página de **Friends** la store almacena los amigos en `users`; si entro en la página de un amigo la store almacena los posts en `posts`, y si muestro un post, los comentarios se almacenan en `comments`.

Esta estrategia me va a obligar a traerme todos los posts del backend cada vez que cambie al muro de un amigo distinto, y además no va a funcionar porque en las páginas de **Amigo** y **Mi muro** debo mostrar varios posts a la vez, donde cada post tiene distintos comentarios. Según la store diseñada arriba, todos los posts visualizados mostrarían siempre los mismos comentarios.

Para evitar este problema podríamos anidar los comentarios dentro de los posts, así:

```json
{
  users: [
    { id: 1, name: "Josh", email: "josh@gmail.com", avatar: "josh.jpg" },
    { id: 2, name: "Anne", email: "anne@gmail.com", avatar: "anne.jpg" },
    { id: 3, name: "Mike", email: "mike@gmail.com", avatar: "mike.jpg" },
  ],
  posts: [
    {
      id: 1,
      body: "hi all",
      date: "2020-08-01",
      user: { id: 2, name: "Anne", email: "anne@gmail.com", avatar: "anne.jpg" },
      comments: [
        {
          {
            id: 1,
            body: "hello!",
            date: "2020-08-02",
            user: { id: 1, name: "Josh", email: "josh@gmail.com", avatar: "josh.jpg" },
          },
          {
            id: 2,
            body: "hi there!",
            date: "2020-08-02",
            user: { id: 3, name: "Mike", email: "mike@gmail.com", avatar: "mike.jpg" },
          },
        }
      ],
    }
  ],
}
```

Sin embargo, todavía tenemos varios problemas. No estamos cacheando datos, por ejemplo, si navego de un amigo a otro y vuelvo al primero, tendré que cargar de nuevo todos los posts y comments del backend. También hay muchos datos replicados, como los usuarios, ocupando más espacio del necesario.

Lo ideal sería normalizar la store, como se recomienda en la [documentación de redux](https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape). Podríamos pensar algo así, donde a cada entidad hemos añadido uno o varios ids (`userId`, `postId`) que apuntan a las entidades con las que está relacionada:

```json
{
  users: [
    { id: 1, name: "Josh", email: "josh@gmail.com", avatar: "josh.jpg" },
    { id: 2, name: "Anne", email: "anne@gmail.com", avatar: "anne.jpg" },
    { id: 3, name: "Mike", email: "mike@gmail.com", avatar: "mike.jpg" },
  ],
  posts: [
    {
      id: 1,
      body: "hi all",
      date: "2020-08-01",
      userId: 2,
    }
  ],
  comments: [
    {
      {
        id: 1,
        body: "hello!",
        date: "2020-08-02",
        postId: 1,
        userId: 1,
      },
      {
        id: 2,
        body: "hi there!",
        date: "2020-08-02",
        postId: 1,
        userId: 3,
      },
    }
  ],
}
```

De esta forma aplanamos la store y evitamos los datos replicados. Sin embargo, la búsqueda por id del usuario asociado a cada post o comentario, y la búsqueda de todos los comentarios asociados a un post no va a ser nada óptima, ya que nos va a obligar a recorrer todos los usuarios o comentarios y filtrar por id. Cuando la store crezca durante una sesión, este proceso se va a volver más y más lento e impactará a la experiencia de usuario.

Podemos mejorar esto indexando cada dato, como se sugiere en la documentación de redux.

```json
{
  "users": {
    "byId": {
      "1": {
        "id": 1,
        "name": "Josh",
        "email": "josh@gmail.com",
        "avatar": "josh.jpg"
      },
      "2": {
        "id": 2,
        "name": "Anne",
        "email": "anne@gmail.com",
        "avatar": "anne.jpg"
      },
      "3": {
        "id": 3,
        "name": "Mike",
        "email": "mike@gmail.com",
        "avatar": "mike.jpg"
      }
    }
  },
  "posts": {
    "byId": {
      "1": {
        "id": 1,
        "body": "hi all",
        "date": "2020-08-01",
        "userId": 2
      }
    }
  },
  "comments": {
    "byId": {
      "1": {
        "id": 1,
        "body": "hello!",
        "date": "2020-08-02",
        "postId": 1,
        "userId": 1
      },
      "2": {
        "id": 2,
        "body": "hi there!",
        "date": "2020-08-02",
        "postId": 1,
        "userId": 3
      }
    }
  }
}
```

Ahora es mucho más sencillo y rápido buscar el `user` asociado a un `post` o un `comment`. Sin embargo, sigue siendo complejo obtener la lista de `posts` por `user`, o la lista de `comments` por `post`. De hecho, ahora es más difícil e ineficiente filtrar estos datos.

Vamos pues a crear estructuras relacionales que nos indiquen qué posts pertenecen a cada usuario (uno a muchos), y qué comentarios a cada post.

```json
{
  users: {
    byId: {
      1: { id: 1, name: "Josh", email: "josh@gmail.com", avatar: "josh.jpg" },
      2: { id: 2, name: "Anne", email: "anne@gmail.com", avatar: "anne.jpg" },
      3: { id: 3, name: "Mike", email: "mike@gmail.com", avatar: "mike.jpg" },
    },
    postIdsById: {
      2: [ 1 ],
    }
  },
  posts: {
    byId: {
      1: {
        id: 1,
        body: "hi all",
        date: "2020-08-01",
        userId: 2,
      }
    },
    commentIdsById: :{
      1:[ 1, 2],
    }
  },
  comments: {
    byId: {
      1: {
        id: 1,
        body: "hello!",
        date: "2020-08-02",
        postId: 1,
        userId: 1,
      },
      2: {
        id: 2,
        body: "hi there!",
        date: "2020-08-02",
        postId: 1,
        userId: 3,
      },
    }
  },
}
```

La lectura del reducer `postIdsById` sería _"el usuario con id 2 tiene el post con id 1"_. La lectura de `commentIdsById` sería _"el post con id 1 tiene los comentarios con ids 1 y 2"_. Ahora ya tenemos todo indexado y la estructura de base de datos está totalmente normalizada.

Únicamente nos faltan estructuras que nos permitan almacenar los ids de los posts que serán visibles en cada muro, ya sea el del usuario o el de sus amigos, así como los ids de los usuarios que deben aparecer en la página de amigos. Incluiremos en la página de amigos un filtro para ordenar alfabéticamente de forma ascendente o descendente.

Para separar las estructuras que modelan entidades que pertenecen a la base de datos, de las estructuras que modelan elementos de la interfaz de usuario, crearemos 2 reducers de mayor nivel, uno llamado `entities` donde almacenaremos **entidades de la base de datos**, y otro llamado `ui` donde almacenaremos todos los **elementos de la interfaz de usuario**.

Este es finalmente el modelo de la store, que evita la replicación de datos, facilita la búsqueda gracias a la indexación, y nos va a permitir cachear los datos ya cargados, ya que las estructuras asociadas a la interfaz de usuario solo almacenan ids, y cualquier entidad ya descargada del backend va a permanecer en la store hasta que borremos la caché del navegador.

```json
{
  entities: {
    users: {
      byId: {
        1: { id: 1, name: "Josh", email: "josh@gmail.com", avatar: "josh.jpg" },
        2: { id: 2, name: "Anne", email: "anne@gmail.com", avatar: "anne.jpg" },
        3: { id: 3, name: "Mike", email: "mike@gmail.com", avatar: "mike.jpg" },
      },
      postIdsById: {
        2: [ 1 ],
      },
    },
    posts: {
      byId: {
        1: {
          id: 1,
          body: "hi all",
          date: "2020-08-01",
          userId: 2,
        },
      },
      commentIdsById: :{
        1: [ 1, 2 ],
      },
    },
    comments: {
      byId: {
        1: {
          id: 1,
          body: "hello!",
          date: "2020-08-02",
          postId: 1,
          userId: 1,
        },
        2: {
          id: 2,
          body: "hi there!",
          date: "2020-08-02",
          postId: 1,
          userId: 3,
        },
      },
    },
  },
  ui: {
    friends: {
      orderFilter: "asc",
      userIds: [ 2, 3 ],
    },
    friendWall: {
      postIdsById: {
        2: [ 1 ],
      },
    },
    wall: {
      postIds: [ 1 ],
    },
  },
}
```

En próximos posts veremos la implementación de esta store y los métodos de cacheado.

## Credits

Fotografía por [Jeremy Bishop](https://unsplash.com/@jeremybishop) en [Unsplash](https://unsplash.com/).


En esta serie de posts crearemos una aplicación usando react y redux, en la que manejaremos datos relacionales. En esta primera parte modelaremos la store.

Usando redux con datos relacionales (1/3)


En este post, te mostraré cómo crear una simple [Chrome extension](https://chrome.google.com/webstore/category/extensions). Resumiré lo que una extensión de Chrome puede hacer, y también voy a explicar cómo crear extensiones más complejas basadas en JavaScript, React, Angular o Vue.

¿Qué es una extensión de Chrome? Las extensiones de Google Chrome son como pequeñas aplicaciones que viven en tu navegador, basadas en tecnologías web estándar, como HTML, CSS y JavaScript. Aprovechan algunas API de Chrome, proporcionando las bases para construir una aplicación, como el almacenamiento y la mensajería. Las extensiones de Google Chrome pueden interactuar con las páginas web abiertas en las pestañas de tu navegador, pero en realidad no están pensadas para ello. Pueden "vivir" por sí solas y proporcionar cualquier tipo de funcionalidad, más allá de la experiencia de navegación. Puedes crear cualquier cosa, desde una agenda, pasando por un temporizador pomodoro, hasta un web image scrapper. Puedes pensar en Chrome como la plataforma Electron, proporcionando una base para construir aplicaciones JavaScript que pueden interactuar con la experiencia de navegación.

Las extensiones de Chrome pueden permanecer inactivas hasta que algún trigger las despierte, haciendo que se inyecte algún contenido o script, se ejecute o se muestre algún popup. Estos scripts viven en algo llamado "Mundos Aislados" en relación con las páginas web que se están navegando, lo que significa que una extensión de Chrome sólo puede compartir el DOM con una página en particular, pero no las variables o funciones del script. Por lo tanto, las extensiones de Chrome pueden modificar el DOM, inyectar scripts CSS o JavaScript adicionales que interactúan con el mismo DOM, pero no pueden modificar directamente la página original CSS o JavaScript. Por otro lado, las extensiones pueden comunicarse con la página a través de mensajes, por lo que puede crear una página que interactúe con una extensión de Chrome.

## Capacidades de la extensión

Este es un resumen incompleto de lo que puede hacer una extensión:

- **Mostrar un icono**. El icono de la extensión puede ser modificado en tiempo de ejecución, o mostrar una insignia sobre él, con un fondo de color y un texto de 4 letras en él.
- **Mostrar un popup**. Al hacer clic en el icono de la extensión se puede activar un popup con contenido.
- **Mostrar un menú secundario**. Haciendo clic con el botón derecho del ratón en el icono de la extensión puede activar un menú secundario.
- **Responder a atajos de teclado**. Los atajos de teclado pueden asociarse a las acciones de extensión (CTRL+SHIFT+V).
- **Responder a acciones de la barra de direcciones** (la así llamada omnibox). Los atajos de texto pueden usarse en la omnibox para activar acciones en la extensión (p.ej. “myext+<TAB>").
- **Responder a la visita a cierta página web**. Por ejemplo, modificar el estado del icono o el contenido de la ventana emergente
  Modifica el contenido de un sitio web. Por ejemplo, modificar el DOM por un script de contenido o aplicar archivos CSS adicionales.
- **Tener una página de opciones** para la configuración de la extensión.
- **Reemplazar la página de Historial, Favoritos o Nueva Pestaña** de Google Chrome.
- **Intercambiar mensajes** con un sitio web o consigo mismo. Una extensión puede utilizar la mensajería para hablar con alguna página web que se esté navegando, o para comunicarse entre partes de la propia extensión.
- **Almacenar información** en el almacenamiento local, el almacenamiento Chrome (almacenamiento que se sincroniza a través de diferentes dispositivos donde el usuario está conectado) o cualquier almacenamiento nativo de JS, por ejemplo sessionStoragef.
- **Mostrar notificaciones** como un "toast".
- **Usar varias APIs proporcionadas por Google Chrome**.
- **Ser gratis, o de pago**. Al crear una extensión de pago, puedes elegir usar la tienda Chrome o tus propios medios de pago.

## Lo básico

El único archivo obligatorio de una extensión de Chrome es el manifiesto. Debe estar colocado en el directorio raíz, y comunica los metadatos de la extensión, los permisos y otros archivos involucrados.

El formato del manifiesto tiene un montón de opciones, que se pueden ver en esta página (https://developer.chrome.com/extensions/manifest), pero nos centraremos en los más importantes. Presentemos el manifiesto de la extensión "Cat detector":

```json
{
  "name": "Cat detector",
  "description": "Spots cats in the page you are browsing",
  "manifest_version": 2,
  "version": "1.0",
  "background": {
    "persistent": false,
    "scripts": ["background.js"]
  },
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content.js"]
    }
  ],
  "browser_action": {
    "default_popup": "popup.html"
  },
  "icons": {
    "16": "images/footprint-16.png",
    "32": "images/footprint-32.png",
    "48": "images/footprint-48.png",
    "128": "images/footprint-128.png"
  },
  "permissions": ["activeTab"]
}
```

El manifiesto declara algunas capacidades que serán utilizadas por la extensión:

- Declara un background script. Los background scripts pueden activarse en cualquier momento, pero no tienen acceso directo al contenido de los tabs.
- Declara un content script. Los scripts de contenido se implementan en la misma página en la que se está navegando y tienen acceso al contenido. Una expresión de coincidencia es usada para determinar cuándo el script es inyectado. En este caso elegimos `<all urls>`, lo que significa que se implementa en cualquier página web.
- Declara una acción del navegador, es decir, una extensión que es capaz de funcionar independientemente de la página por la que se está navegando. Si quisiéramos crear una extensión que sólo se activa cuando se cumplen algunas condiciones en la página que se está navegando, utilizaríamos una "page action". La razón por la que elegimos la acción de navegación es que los gatos se pueden ver casi en todas partes en Internet. Una segunda razón es que queremos mostrar un badge sobre el icono de la extensión, y eso sólo es posible usando una acción del navegador.
- Dentro de la acción del navegador, declara un popup que se abrirá al hacer clic en el icono de la extensión.
- Declara los iconos. Los más pequeños se utilizan para el icono del navegador, dependiendo de la resolución de la pantalla, y los más grandes se usan en el menú de extensiones de Chrome y el Chrome Store.

## Nuestra extensión de ejemplo

Vamos al grano de este post: esta page action utiliza un background script que, al cargar la página, envía un mensaje al content script, que a su vez cuenta el número de veces que las palabras "cat", "kitten" o "kitty" aparecen en nuestra página. Después de recibir una respuesta, la tarea de background muestra un badge sobre el icono para comunicar el número de gatitos que aparecen. Al hacer clic en el icono de la extensión, se mostrará un popup con una imagen de un gatito feliz junto con el contador.

Echemos un vistazo a la estructura de los archivos de extensión:

```
-audios
 |-meow_0.mp3
 |-meow_1.mp3
 |-meow_2.mp3
 |-meow_3.mp3
 |-meow_4.mp3
 |-meow_5.mp3
 |-meow_6.mp3
-images
 |-footprint-16.png
 |-footprint-32.png
 |-footprint-48.png
 |-footprint-128.png
-background.js
-content.js
-manifest.js
-popup.html
-popup.js
```

Incluye los iconos de extensión, algunos archivos de audio, el manifiesto, el background script, el content script y los archivos del popup html y js.

Así queda el background script. Se han incluido comentarios para señalar las cosas importantes:

```
const maxMeows = 6;

// The extension listens to the onUpdated event, and executes when the page is loaded
chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {
  if (changeInfo.status === "complete" && tab.active) {
    detectCats(tabId);
  }
});

// It executes the cat detection as well when we switch tabs on the active tab
chrome.tabs.onActivated.addListener((activeTab) => detectCats(activeTab.tabId));

const detectCats = (tabId) => {
  // Here we clear the badge
  chrome.browserAction.setBadgeText({ text: "" });
  // Then we send a message to the content script, together with a callback
  chrome.tabs.sendMessage(tabId, { text: "cat_count" }, onCatCount);
};

// This is the callback called by the content script
const onCatCount = (catNumber) => {
  if (!catNumber) {
    deactivateIcon();
  } else {
    // When cats are detected, show an animation on the badge
    animateBadge(catNumber);
  }
};

const deactivateIcon = () => {
  // Here we detect what the active tab is and disable the action
  chrome.tabs.query({ active: true, currentWindow: true }, (activeTab) => {
    chrome.browserAction.disable(activeTab[0].id);
  });
};

const animateBadge = (catNumber) => {
  // Limit meows, we don't want 1000 sounds to be played
  let i = catNumber - maxMeows > 0 ? catNumber - maxMeows : 1;
  let j = 0;
  // Cats will meow at random times
  for (; i <= catNumber - 1; i++, j++) {
    updateBadge(i, j * Math.random() * 400);
  }
  // Last cat should come last, let's give it the highest delay
  updateBadge(catNumber, j * 500);
};

const updateBadge = (catIndex, delay) => {
  // After some specified delay display a number on the badge and play a meow sound
  setTimeout(() => {
    (
      new Audio(chrome.runtime.getURL(`audios/meow_${catIndex % 7}.mp3`))
    ).play();
    chrome.browserAction.setBadgeText({ text: catIndex.toString() });
  }, delay);
};
```

El content script básicamente recibe el mensaje `cat_count` y responde a él. Se ha incluido algo de lógica para contar los gatos con una expresión regex:

```
chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
  if (msg.text === "cat_count") {
    sendResponse(countCats());
  }
});

const countCats = () => {
  var content =
    document.body["innerText" in document.body ? "innerText" : "textContent"];
  content = removeScriptsFromContent(content);
  var regex = /(cat|cats|kitten|kittens|kitty|kitties)[\s.,]/gi;

  return content.match(regex)?.length || 0;
};

const removeScriptsFromContent = (strCode) => {
  return strCode.replace(/<script.*?>.*?<\/script>/gim, "");
};
```

El archivo html del popup simplemente muestra una imagen y declara el fichero javascript:

```
<html>
  <body>
    <img id="cat_image" />
    <script src="popup.js"></script>
  </body>
</html>
```

El archivo js ejecuta una función en la carga que a su vez envía un mensaje al content script para contar gatos de nuevo. Esto se debe a que los popups no "viven" hasta que se abren, así que si hay que hacer alguna actualización en el popup, es el popup el que debe iniciar la acción:

```
window.onload = () => {
  chrome.tabs.query({ active: true, currentWindow: true }, (activeTab) => {
    const tabId = activeTab[0].id;
    chrome.tabs.sendMessage(tabId, { text: "cat_count" }, onCatCount);
  });
};

const onCatCount = (catNumber) => {
  document.getElementById(
    "cat_image"
  ).src = `https://cataas.com/c/s/${catNumber}%20happy%20cats%20detected?t=sq&width=350`;
};
```

ChanChanChan, este es el resultado de la extensión del detector de gatos en acción:

![Cat extension](/img/blog/2020-05_creating-a-chrome-extension/cat_extension.png)

## Probando localmente nuestra extensión

Si quieres probar tu extensión en tu máquina local, sólo tienes que ir al menu item More Tools —> Extensions, luego hacer click en Load Unpacked, y seleccionar la carpeta donde está tu manifiesto y el resto de los archivos.

![Loading the extension for testing](/img/blog/2020-05_creating-a-chrome-extension/load_extension.png)

## Debugging

El proceso de debugging se vuelve particularmente compleja ya que cada extensión debe ser inspeccionada de manera diferente.

En cuanto a los background scripts, se inspeccionan en las extensiones. Para abrir las herramientas de desarrollo es necesario hacer clic en el enlace "página en segundo plano" en los detalles de la extensión.

![Opening the extension dev tools](/img/blog/2020-05_creating-a-chrome-extension/extension_info.png)

Los content scripts se inspeccionan en la página web que estás navegando, ya que se inyectan en la página. Se muestran en una pestaña de **Content Scripts**.

![Debugging content scripts](/img/blog/2020-05_creating-a-chrome-extension/debugging_content_scripts.png)

No pude encontrar la forma de inspeccionar los popup scripts, incluso los logs de la consola se perdían en algún lugar, así que mostrar una alerta fue la única forma de comprobar que el popup estaba "vivo" y activo.

## Publicando la extensión

Para publicar una extensión de Google Chrome es necesario registrarse como desarrollador de Chrome, pagar 5 dólares y rellenar algunos datos sobre el nombre de la extensión, la descripción y las imágenes o vídeos. El proceso es muy similar al que se sigue para publicar una aplicación en Google Play. Después de enviar tu extensión para la aprobación, tienes que esperar una respuesta. Las respuestas negativas son bastante rápidas -mi primera extensión fue rechazada sin razón alguna, y tuve que enviar un correo electrónico para pedir una revisión humana-, las positivas pueden tardar unas horas o días.

## Ir más allá...

El sitio de desarrollo de Chrome para extensiones proporciona un gran número de extensiones de muestra. Estas son extensiones simples que abordan características muy específicas que pueden ayudar a aprender a construir extensiones.

https://developer.chrome.com/extensions/samples

Hay muchos proyectos de boilerplate por ahí para ayudarte a desarrollar extensiones más complejas usando React, Angular o Vue. Toma los siguientes enlaces como punto de partida:

- https://github.com/lxieyang/chrome-extension-boilerplate-react
- https://github.com/larscom/ng-chrome-extension
- https://github.com/Kocal/vue-web-extension

## Recap

Crear extensiones de Chrome puede ser divertido, y también puedes encontrar muchos escenarios productivos para ellas. Desarrollar extensiones es fácil si conoces las tecnologías web básicas como HTML, CSS y JavaScript. Te mostramos los fundamentos de una extensión de Chrome y te guiamos en la creación de una simple extensión.

Si quiere comprobar el código de extensión completo, ¡échale un vistazo! [github repository](https://github.com/jguix/chrome-cat-detector).

¿Puedes imaginarte algo que pueda ser entregado como una extensión de Chrome? Compártenos tu idea...

## Crédits

Fotografía de Markus Winkler en [Unsplash](https://unsplash.com/).


En este post, te mostraré cómo crear una simple Chrome extension, usando solo JavaScript, HTML y CSS. También resumiré lo que una extensión de Chrome puede hacer, y también voy a explicar cómo crear extensiones más complejas basadas en JavaScript, React, Angular o Vue.

Creando una extensión de Chrome

En este post os cuento la experiencia de participar en un Design Sprint, y cómo Ecoembes utilizó la metodología Design Sprint para explorar nuevas ideas en el contexto de la economía circular y el reciclaje. Para ello, reclutó mediante becas a un ecléctico grupo de profesionales, incluyendo emprendedores, profesionales del marketing, diseño, y tecnología, entre los que me encuentro. Durante 5 días en Julio de 2018, trabajamos conjuntamente en The Circular Lab, un espacio de innovación de Ecoembes localizado en Logroño, particularmente preparado para el trabajo creativo y colaborativo.

Circular Design SPRINT


Esta publicación tiene como objetivo proporcionar instrucciones claras sobre cómo usar componentes creados y compilados con Stencil en una aplicación Ionic. Te guiaré en el proceso de hacer que un componente web esté disponible en tus templates Ionic, sin necesidad de registrarlos en el registro npm o agregar feos tags script a tu índice.

## Motivación

Creado por el [equipo de Ionic Framework](http://ionicframework.com/), uno esperaría que el uso de componentes web Stencil en proyectos Ionic sería, si no automático e integrado en el framework mediante algún comando CLI, al menos bien documentado.

Bueno, ese no es el caso, ya que los chicos de Ionic proporcionan [instrucciones de integración del framework](https://stenciljs.com/docs/framework-integration) para Angular, React, Vue y Ember, pero no los proporcionan para Ionic. Tal vez descuidé algo obvio, pero tuve que investigar un poco para que mis componentes Stencil funcionaran en un proyecto Ionic, y el esfuerzo fue lo suficientemente grande como para hacerme pensar en crear una publicación, esperando que pueda ayudar a alguien.

## Requisitos

Como requisito, debes crear un componente Stencil, una tarea para la que puedes encontrar la documentación adecuada en el sitio web de Stencil. El componente Stencil tampoco necesita estar registrado en el registro npm.

## Proceso de integración

Si integramos componentes web registrados en npm, el proceso es más sencillo. Afrontemos en esta sección el caso en el que desarrollamos un componente personalizado, pero no lo estamos publicando en el registro npm. Nuestro objetivo es una integración limpia sin etiquetas de script en el archivo `index.html`.

El proceso consta de tres pasos.

- Primero construimos el componente y copiamos los archivos de distribución a nuestro proyecto.
- Luego le decimos al lado Angular de las cosas cómo usar el componente.
- Por último, le decimos al lado Ionic de las cosas que incluya el componente cuando construya el paquete. La forma en que hablamos con Angular (realmente Ionic-Angular) depende de si estamos cargando páginas de forma _anticipada_ o de forma _diferida_.

### Paso 1. Generar y copiar componente

Construya el componente y copie el contenido de la carpeta dist a una carpeta en nuestro proyecto. En este ejemplo, elegimos la carpeta `@img/lib/components/my-google-maps`.

### Paso 2. Importar en el app.module.ts

Primero, necesitas importar el `CUSTOM_ELEMENTS_SCHEMA`, y agregarlo a la sección` schemas` del `@NgModule`. Si importas `CUSTOM_ELEMENTS_SCHEMA` en uno de los módulos de tu página, el compilador Angular aceptará elementos que no reconoce (de lo contrario, arrojará un error). Si realizas una carga diferida, debes importar este esquema en cada módulo de página en el que desees utilizar el componente web. Si estás cargando con anticipación, solo necesitas importar el esquema en `app.module.ts`.

Luego, agrega un import a la carpeta `dist/mycomponent`. Este import no carga todo el componente web. Solo carga una pequeña parte del código que permite a Ionic cargar el componente web completo más tarde, cuando una plantilla lo solicita.

Cuando hayas realizado ambos pasos, tu `app.module.ts` debería parecerse al siguiente si estás cargando con anticipación.

```typescript
import { CUSTOM_ELEMENTS_SCHEMA } from '@angular/core'; // add this import
import '@img/lib/components/my-google-maps/dist/mycomponent'; // add this import

@NgModule({
  declarations: [],
  imports: [],
  bootstrap: [],
  entryComponents: [],
  providers: [],
  schemas: [CUSTOM_ELEMENTS_SCHEMA], // add this line
})
export class AppModule {}
```

Si usas lazy loading, importa solo el componente web en `app.module.ts`, y solo el esquema en los módulos individuales cargados de forma diferida.

### Paso 3. Usar ionic-app-scripts para incluir el componente en el build

Crearemos un archivo `copy.config.js` que definirá algunas reglas para copiar el componente web a nuestra compilación final. Una buena práctica es crearlo en una carpeta de configuración, para separarlo de otros archivos estándar como `package.json` o `ionic.config.json`.

Este archivo puede indicarle a los scripts de aplicaciones Ionic que incluyan contenido adicional cuando compile una aplicación iónica. Si creas el archivo, ponlo en una carpeta llamada `config` que esté en el mismo nivel de directorio que la carpeta `src`. En primer lugar, declaremos el archivo en `package.json`. Esto le dirá a los scripts de la aplicación que usen este archivo. Agrega el siguiente campo a tu `package.json`:

```json
"config": {
    "ionic_copy": "./config/copy.config.js"
}
```

Luego, pon esto dentro de `config\copy.config.js`:

```javascript
module.exports = {
  copyTimeAgoWebComponent: {
    src: [
      '{{ROOT}}/src/img/lib/components/my-google-maps/dist/mycomponent**/*',
    ],
    dest: '{{BUILD}}',
  },
};
```

Una vez que hayas realizado esos cambios, los app-scripts sabrán cómo incluir el componente web en sus compilaciones.
Ahora puedes utilizar componentes web Stencil en tus plantillas Ionic como cualquier otro componente web.


Esta publicación tiene como objetivo proporcionar instrucciones claras sobre cómo usar componentes creados y compilados con Stencil en una aplicación Ionic. Te guiaré en el proceso de hacer que un componente web esté disponible en tus templates Ionic, sin necesidad de registrarlos en el registro npm o agregar feos tags script a tu índice.

Usando componentes web generados con Stencil en Ionic


Imagina un escenario en el que tu aplicación debe mostrar diferentes versiones de un componente o servicios a diferentes grupos de usuarios. Si suena un poco traído por los pelos, toma el siguiente escenario que se propuso a nuestro equipo de desarrollo en cierto proyecto real:

- La aplicación se descarga desde **Google Play/App Store** y se implementará en diferentes países, utilizando el mismo app ID.
- Los diferentes países tienen diferentes regulaciones sobre si la aplicación puede mostrar fotografías de usuarios, campos específicos, etc. Además, algunas funciones deberían estar totalmente deshabilitadas en algunos países.
- La aplicación seguirá creciendo en funcionalidad, pero no necesariamente al mismo tiempo para todos los países:
  algunos países pueden decidir no actualizar alguna función o actualizarla más tarde;
  algunos países pueden tomar más tiempo para revisar si alguna característica nueva en particular sigue sus regulaciones de privacidad ...

El enfoque ingenuo de tener directivas `ngIf` por todas partes puede funcionar para los casos más simples
pero sería difícil de mantener y también saturaría nuestras hermosas plantillas.
Además, los componentes que utilizan diferentes servicios al cambiar de una versión a otra serían muy difíciles de mantener.

Así que decidimos utilizar el siguiente enfoque para hacer frente a todas esas situaciones:

- Crear una directiva para mostrar/ocultar partes de una plantilla según el país y la versión.
  Eso sería como una extensión de `ngIf` con nuestros parámetros `country` y `version`,
  y daría una respuesta a problemas simples como ocultar una funcionalidad completa en algunos países,
  u ocultar un campo en particular para algunos países/versiones.
- Crear una directiva que devuelva un componente dinámico, según los parámetros `country` y `version`.
  Esta directiva se utilizaría para casos más generales,
  donde una versión de componente puede proporcionar una funcionalidad muy diferente a otra versión.

Para ilustrar este post, hemos creado una aplicación. Nuestra aplicación muestra con orgullo algunos datos de países,
como la bandera de un país, el área y la población.
Nos pusimos en contacto con gobiernos de todo el mundo y les pedimos amablemente que se unieran a nuestra revolucionaria aplicación sin fines de lucro. proporcionando algunos datos básicos:

- Nombre del país
- Área
- Población

Algunos de estos países tienen regulaciones muy severas y querían unirse a la aplicación,
pero sin revelar su área y población inicialmente,
hasta que sus abogados determinen si estos datos podrían mostrarse.
Por eso diseñamos la primera versión de la aplicación con una sola pantalla,
donde el usuario seleccionaría el país de un combo box,
y un componente con dos subcomponentes que muestran los datos del país:

- Un componente de encabezado para el nombre del país
- Un componente de contenido para los datos.

El componente de contenido debe ser opcional y se mostrará según las normativas del país.

![Diseño de la primera versión de los componentes](/img/blog/2018-04_versioning-features-in-an-angular-app/features_v1.png)

Estas son algunas capturas de pantalla de la aplicación en este punto:

![Capturas de pantalla de la primera versión de la aplicación.](/img/blog/2018-04_versioning-features-in-an-angular-app/features_v1_screenshots.png)

Después de la puesta en marcha, algunos usuarios estaban tan emocionados que empezaron a pedir algunas funcionalidades nuevas:

- Querían que se mostrara la bandera del país en el encabezado.
- Algunos datos más como capital del país y ¿qué más…? el himno nacional, claro.

El equipo de desarrollo estuvo de acuerdo en que, dado que algunos países aún no habían proporcionado su área y población,
Era razonable pensar que algunos de ellos no entregarían instantáneamente su bandera, capital e himno.
Así que decidimos versionar el encabezado y los componentes de contenido, de modo que pudiéramos darles un camino sencillo para actualizar sus datos sin dejar de verse bien en la aplicación, mostrando los componentes antiguos en lugar de los componentes nuevos con campos vacíos.

![Diseño de la versión final de los componentes](/img/blog/2018-04_versioning-features-in-an-angular-app/features_v2.png)

Estas son algunas capturas de pantalla de la versión final de la aplicación:

![Screenshots of the final version of the app](/img/blog/2018-04_versioning-features-in-an-angular-app/features_v2_screenshots.png)

Nuestra aplicación se basa en dos directivas, como dijimos.
La primera mostrará/ocultará un elemento dependiendo de la disponibilidad de funciones para un determinado país,
donde las características serán `COUNTRY_HEADER` y `COUNTRY_CONTENT`.
Esta directiva obtendrá la disponibilidad de funciones de un servicio, el llamado `CountryConfigService`.

```typescript
import {
  CountryConfigDictionary,
  DEFAULT_COUNTRY_CONFIG,
  FeatureVersionDictionary,
} from './country-config.model';

@Injectable()
export class CountryConfigService {
  private config: CountryConfigDictionary = DEFAULT_COUNTRY_CONFIG;
  getCountryFeatures(countryCode: string): FeatureVersionDictionary {
    return this.config[countryCode].features;
  }

  isFeatureEnabled(feature: string, countryCode: string): boolean {
    const countryFeatures = this.getCountryFeatures(countryCode);
    return countryFeatures.hasOwnProperty(feature);
  }

  getFeatureVersion(feature: string, countryCode: string): number {
    const countryFeatures = this.getCountryFeatures(countryCode);
    return countryFeatures[feature];
  }
}
```

La `config` es un objeto que sigue un modelo `CountryConfigDictionary`
que nos permite definir qué versión de los componentes `COUNTRY_HEADER` y `COUNTRY_CONTENT`,
si hay alguno, está usando cada país:

```typescript
export const DEFAULT_COUNTRY_CONFIG: CountryConfigDictionary = {
  es: {
    features: {
      COUNTRY_HEADER: 2,
      COUNTRY_CONTENT: 2,
    },
  },
  fr: {
    features: {
      COUNTRY_HEADER: 2,
      COUNTRY_CONTENT: 2,
    },
  },
  it: {
    features: {
      COUNTRY_HEADER: 2,
      COUNTRY_CONTENT: 1,
    },
  },
  pt: {
    features: {
      COUNTRY_HEADER: 1,
      COUNTRY_CONTENT: 1,
    },
  },
  uk: {
    features: {
      COUNTRY_HEADER: 1,
    },
  },
};
```

## La directiva FeatureIf

Con eso en mente, veamos la directiva `FeatureIf`.
Mostrará un elemento si la función está habilitada para el país.
Opcionalmente, podemos definir la versión mínima implementada por el país,
lo que significa que si el país usa una versión más baja, el elemento estará oculto.
Omitiré los imports estándar para ahorrar espacio en el listado:

```typescript
import { CountryConfigService } from '../../services/country-config/country-config.service';

@Directive({
  selector: '[appFeatureIf]',
})
export class FeatureIfDirective implements OnChanges {
  private _featureName: string;
  private _countryCode: string;
  private _minVersion = 0;
  private _else = false;
  private _hasView: boolean;

  @Input() set appFeatureIf(featureName: string) {
    this._featureName = featureName;
  }

  @Input() set appFeatureIfCountryCode(value: string) {
    this._countryCode = value;
  }

  @Input() set appFeatureIfVersion(value: number) {
    this._minVersion = value;
  }

  @Input() set appFeatureIfElse(value: boolean) {
    this._else = value;
  }

  constructor(
    private templateRef: TemplateRef<any>,
    private viewContainerRef: ViewContainerRef,
    private countryConfigService: CountryConfigService
  ) {}

  ngOnChanges(changes: SimpleChanges): void {
    if (changes) {
      this.applyChanges();
    }
  }

  private applyChanges(): void {
    const featureEnabled = this.countryConfigService.isFeatureEnabled(
      this._featureName,
      this._countryCode
    );
    const featureVersion =
      this.countryConfigService.getFeatureVersion(
        this._featureName,
        this._countryCode
      ) || 0;
    const enabled: boolean =
      featureEnabled && featureVersion >= this._minVersion;
    const displayed: boolean =
      (enabled && !this._else) || (!enabled && this._else);
    this.embedTemplate(displayed);
  }

  private embedTemplate(enabled): void {
    if (enabled && !this._hasView) {
      this.viewContainerRef.createEmbeddedView(this.templateRef);
      this._hasView = true;
    } else if (!enabled && this._hasView) {
      this.viewContainerRef.clear();
      this._hasView = false;
    }
  }
}
```

Esta directiva estructural hace uso de 4 parámetros: `featureName`, `countryCode`, `featureVersion` y `else`.
Presta atención a cómo definimos las propiedades de entrada en una directiva estructural:

- La primera entrada toma el nombre de la misma directiva: `appFeatureIf`.
  Usamos un setter para guardarlo internamente como `_featureName`.
- El resto de entradas toman el nombre de la directiva más el nombre del parámetro.
  Por ejemplo, la entrada `appFeatureIfCountryCode` hace referencia al parámetro de directiva `countryCode`.
  También usamos aquí un setter para mapear la entrada a la variable privada `_countryCode`.

Observa a continuación cómo se utiliza la directiva en una plantilla.
El primer parámetro no necesita una clave, mientras que el resto se pasa con tuplas `"key: value"`, separadas por un punto y coma (`;`).

```html
<div *appFeatureIf="'COUNTRY_HEADER';countryCode:code;version:2">
  Show only for countries implementing the COUNTRY_HEADER feature with version
  >= 2
</div>

<div *appFeatureIf="'COUNTRY_HEADER';countryCode:code;version:2; else:'true'">
  Show otherwise
</div>
```

Lo que básicamente hace la directiva es:

- Registra cambios en cualquiera de los inputs.
- Cuando se crea una instancia de la directiva o cualquiera de los inputs cambia, ejecuta `applyChanges()`.
- Calcula si la funcionalidad está habilitada de acuerdo con `featureName`,` countryCode` y `minVersion`.
- Calcula si el elemento debe mostrarse.
  Si el parámetro `else` está definido y es `true`, se mostrará si la función está deshabilitada.
- Ejecuta `embedTemplate()`, que crea la vista embebida en el contenedor de la vista si el elemento debe mostrarse,
  o borra el contenedor de vista de lo contrario.

Usamos esta directiva en dos casos en nuestra aplicación.
En el encabezado, lo usamos para ocultar la bandera de los países que implementan la versión 1 de `COUNTRY_HEADER`.

```html
<div
  *appFeatureIf="'COUNTRY_HEADER';countryCode:country.code;
  version:2"
  class="flag {{country.code}}"
></div>
```

En el componente padre, usamos la directiva con el parámetro `else` a `true`,
para mostrar un texto informativo cuando el componente de contenido no está disponible.

```html
<div
  class="no-feature"
  *appFeatureIf="'COUNTRY_CONTENT';
  countryCode:country.code;else:'true'"
>
  This feature is not yet available in {{country.name}}.
</div>
```

## La directiva FeatureVersion

Nuestra segunda directiva nos permitirá inyectar dinámicamente un componente u otro, dependiendo de algunos parámetros.

```typescript
import { CountryConfigService } from '../../services/country-config/country-config.service';
import { DynamicComponentService } from '../../services/dynamic-component/dynamic-component.service';
import { DynamicComponent } from '../../services/dynamic-component/dynamic-component.model';

@Directive({
  selector: '[appFeatureVersion]',
})
export class FeatureVersionDirective implements OnChanges {
  private _featureName: string;
  private _countryCode: string;
  private _data: any;
  private componentRef: ComponentRef<DynamicComponent>;

  @Input() set appFeatureVersion(featureName: string) {
    this._featureName = featureName;
  }

  @Input()
  set appFeatureVersionCountryCode(value: string) {
    this._countryCode = value;
  }

  @Input()
  set appFeatureVersionData(value: any) {
    this._data = value;
  }

  constructor(
    private viewContainerRef: ViewContainerRef,
    private countryConfigService: CountryConfigService,
    private dynamicComponentService: DynamicComponentService,
    private componentFactoryResolver: ComponentFactoryResolver
  ) {}

  ngOnChanges(changes: SimpleChanges): void {
    if (changes) {
      this.applyChanges();
    }
  }

  private applyChanges(): void {
    const featureEnabled = this.countryConfigService.isFeatureEnabled(
      this._featureName,
      this._countryCode
    );
    const featureVersion =
      this.countryConfigService.getFeatureVersion(
        this._featureName,
        this._countryCode
      ) || 0;
    const dynamicComponent = this.dynamicComponentService.getComponent(
      this._featureName,
      featureVersion
    );
    this.clearViewContainer();
    if (featureEnabled && dynamicComponent) {
      this.embedComponent(dynamicComponent);
      this.injectComponentData();
    }
  }

  private clearViewContainer(): void {
    this.viewContainerRef.clear();
  }

  private embedComponent(component: Type<DynamicComponent>): void {
    const componentFactory =
      this.componentFactoryResolver.resolveComponentFactory(component);
    this.componentRef = this.viewContainerRef.createComponent(componentFactory);
  }

  private injectComponentData(): void {
    this.componentRef.instance.data = this._data;
  }
}
```

Esta vez, la directiva toma tres parámetros: `featureName`, `countryCode` y `data`.
El parámetro `data` se utilizará para pasar datos a nuestro componente dinámico.
Dado que los diferentes componentes pueden tener diferentes entradas,
tomamos el enfoque de recibir cualquier dato externo a través de este objeto `data`.
Los componentes dinámicos también pueden recibir datos externos a través de servicios, como veremos más adelante.

Entonces, básicamente, lo que hace esta directiva es:

- Registra cambios en alguna de los inputs.
- Cuando se instancia la directiva o cualquiera de los inputs cambia, ejecuta `applyChanges()`.
- Calcula si la función está habilitada según el nombre de la funcionalidad y el código de país.
- Obtiene el tipo de componente dinámico para el nombre de la funcionalidad y la versión de `DynamicComponentService`.
- Borra el view container.
- Si se recuperó con éxito un tipo de componente dinámico, ejecuta `embedTemplate()`,
  que resuelve una factoría para este tipo de componente y crea la vista embebida en el view container.
- Finalmente, inyecta el objeto de datos en el componente instanciado dinámicamente.

Veamos el código para esas clases `DynamicComponent` y `DynamicComponentService`.

El `DynamicComponent` es solo una clase con una propiedad pública `data`.
También crearemos una interfaz de diccionario y una constante con las clases de componentes dinámicos actuales
(versiones de contenido del país 1 y 2) que será utilizado por el servicio.

```typescript
import { CountryContentV1Component } from '../../../country/components/country-content/v1/country-content.v1.component';
import { CountryContentV2Component } from '../../../country/components/country-content/v2/country-content.v2.component';

export class DynamicComponent {
  data: any;
}

export interface DynamicComponentDictionary {
  [key: string]: {
    [key: number]: Type<DynamicComponent>;
  };
}

export const DEFAULT_DYNAMIC_COMPONENT_DICTIONARY: DynamicComponentDictionary =
  {
    COUNTRY_CONTENT: {
      1: CountryContentV1Component,
      2: CountryContentV2Component,
    },
  };
```

`DynamicComponentService` simplemente devuelve la clase de componente adecuada,
dependiendo de los parámetros `featureName` y `version`.

```typescript
import {
  DEFAULT_DYNAMIC_COMPONENT_DICTIONARY,
  DynamicComponent,
  DynamicComponentDictionary,
} from './dynamic-component.model';

@Injectable()
export class DynamicComponentService {
  private componentDictionary: DynamicComponentDictionary =
    DEFAULT_DYNAMIC_COMPONENT_DICTIONARY;

  getComponent(featureName: string, version: number): Type<DynamicComponent> {
    const selectedComponent = this.componentDictionary[featureName]
      ? this.componentDictionary[featureName][version]
      : undefined;
    return selectedComponent;
  }
}
```

Veamos cómo se usa esta directiva en el componente principal.

```html
<ng-template
  *appFeatureVersion="'COUNTRY_CONTENT';
  countryCode:country.code;data:{country: country}"
>
</ng-template>
```

Este es el código de la clase `CountryContentV1Component`.

```typescript
import { DynamicComponent } from '../../../../shared/services/dynamic-component/dynamic-component.model';
import { Country } from '../../../services/country.model';

@Component({
  selector: 'app-country-content-v1',
  templateUrl: './country-content.v1.component.html',
  styleUrls: ['./country-content.v1.component.scss'],
})
export class CountryContentV1Component implements DynamicComponent {
  data: { country: Country };
}
```

Y así es como la plantilla usa la propiedad `data` para mostrar los datos del país.

```html
<div class="country-content">
  <div class="data-row">
    <span class="data-label"> Area: </span>
    <span class="data-value"> {{data.country.area | number}} </span>
  </div>
  <div class="data-row">
    <span class="data-label"> Population: </span>
    <span class="data-value"> {{data.country.population | number}} </span>
  </div>
</div>
```

Puedes ver una demo de la aplicación aquí:  
https://stackblitz.com/edit/component-version-demo

## Servicios versionados

La situación puede complicarse un poco más si los servicios también están versionados.
Imaginemos que la primera versión del servicio que proporciona datos del país solo incluye el nombre del país,
área y población, y que se debe crear una nueva versión para incluir los nuevos datos,
al mismo tiempo que proporciona la versión anterior para compatibilidad con versiones anteriores.

En este caso podemos inyectar la versión de servicio correspondiente en los componentes versionados.
No usaremos la propiedad `data` de `DynamicComponent`, sino que obtendremos los datos del servicio.
También podríamos usar _injection tokens_ para inyectar dinámicamente el servicio versionado dependiendo de ciertas condiciones.

La siguiente demo es un enfoque simple que utiliza servicios versionados:  
https://stackblitz.com/edit/component-version-demo-services

## Consideraciones finales

La aplicación de demo probablemente sea demasiado simple para ese tipo de solución.
Podríamos haber usado inteligentemente algunas combinación de `ngIf` y `ngTemplate` para llegar a la misma solución.
Pero piensa en un caso en el que el usuario no selecciona el país de un cuadro combinado,
sino que el país se detecta automáticamente desde la configuración de su dispositivo,
y piensa en una interfaz de usuario más complicada con un panel con varios widgets que deberían mostrarse u ocultarse,
o tener contenido diferente según el país, y entonces este enfoque tendrá mucho más sentido.

Este post es lo suficientemente largo para entrar en más detalles.
Si tienes sugerencias para mejorarlo, inclúyelas en tus comentarios :)


Versionar componentes e instanciar la versión adecuada de forma dinámica no solo es posible, sino que también tiene algunos casos de uso. Consulta esta publicación donde explico cómo lograr eso usando un ComponentFactoryResolver y directivas estructurales.

Versionar características en una aplicación angular


¿Estás ansioso por mostrarle al mundo tu prueba de concepto, proyecto paralelo, idea…?
Esta receta de bash de 5 líneas pondrá tu trabajo en el escaparate en cuestión de segundos.

Así que acabas de terminar de crear el proyecto más genial con [Angular CLI](https://cli.angular.io/) y quieres compartirlo con tus colegas, o quizás escribir una publicación al respecto, pero quieres evitarles a tus colegas el dolor de bajarse el código, instalar dependencias y ejecutar la aplicación (lo sé, casi no puede ser más fácil hoy en día) y no tienes un servidor web, o tal vez eres tan vago como tus colegas y no te apetece poner mucho esfuerzo en desplegar el código en algún sitio.

Bien, ¡[Github Pages](https://pages.github.com/) al rescate!

## GitHub Pages

Voy a asumir que ya creaste el proyecto con Angular CLI, por lo que tu proyecto ya está versionado con git.
Supongamos también que ya tienes una **cuenta de GitHub** con cierto `NICKNAME`.
Dirígete a GitHub y crea un nuevo proyecto, llamémoslo `MY_PROJECT`.
No coloques ningún archivo en él, puedes volver más tarde y agregar el `README` y la licencia deseada,
pero por ahora será más fácil si lo dejas en blanco.

Luego, conecta tu repositorio de git local con el nuevo repositorio remoto y haz push de los cambios:

```bash
git remote add origin https://github.com/NICKNAME/MY_PROJECT.git
git push origin master
```

Ahora, si ya conocíaa GitHub Pages, estarás tentado a activarlas manualmente en el archivo `index.html` de tu proyecto.
**¡NO HAGAS ESO! ¡¡No funcionará!!**

Tu proyecto aún debe ser generado para producción,
lo cual creará una carpeta `dist` desde la cual podrás servir tus páginas de GitHub, pero **¡NO LO HAGAS! ¡¡¡No funcionará!!!**

Parece que GitHub Pages no son adecuadas para SPA, ya que redirigen las rutas de su aplicación a una página 404.
Pero algunos tipos muy majos desarrollaron [angular-cli-ghpages](https://www.npmjs.com/package/angular-cli-ghpages).
Este paquete npm llenará los huecos y hará que tu aplicación funcione en GitHub Pages.

Instálalo con:

```bash
npm install -g angular-cli-ghpages
```

Luego ejecuta estos 2 comandos:

```bash
ng build --prod --base-href "https://NICKNAME.github.io/MY_PROJECT/"
angular-cli-ghpages
```

El segundo comando tiene un montón de opciones, pero todas son opcionales como dice la palabra `option`,
y no necesitas mucho más para poner en marcha tu aplicación en GitHub Pages. ¡A disfrutar!

Bueno, ciertamente necesitarás la URL de tu aplicación para compartirla con el mundo.
Esta URL es exactamente la que usamos en el comando `ng build`:  
[https://NICKNAME.github.io/MY_PROJECT/](#)

### Desplegando proyectos Ionic

Actualización: 2018-05-07

¿Qué pasa con los proyectos Ionic?
Se despliegan en `www` en lugar de la carpeta `dist`, y usan Ionic CLI en lugar de Angular CLI,
por lo que será necesario realizar un par de cambios.

```bash
ionic build --prod
```

El `--base-href` no está disponible en Ionic CLI (que yo sepa),
por lo que deberá abrir el archivo `index.html` y escribir la etiqueta base por tu cuenta, una vez finalizada la compilación.
Puedes ponerlo después de la etiqueta del título, por ejemplo:

```html
<title>Ionic App</title>
<base href="https://NICKNAME.github.io/MY_PROJECT/" />
<meta
  name="viewport"
  content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"
/>
```

Ahora, como dije, la salida de la compilación no es la predeterminada para Angular CLI, que sería la carpeta `dist`.
Usa el flag `--dir` para especificar la carpeta `www` como fuente para las páginas de GitHub.

```bash
angular-cli-ghpages --dir www
```

## Stackblitz

Ahora, para la parte de [Stackblitz](https://stackblitz.com/) del post… ¿no sería bueno permitir que nuestros colegas o seguidores interactúen realmente con nuestro código y vean el impacto de las modificaciones en casi-tiempo-real?

Los chicos de Stackblitz han creado este tipo de IDE en línea donde puedes crear proyectos y ver la generación al mismo tiempo.
¡Es como **JSfiddler** con esteroides!

![Stackblitz](/img/blog/2018-03_angular-cli-github-pages-stackblitz/stackblitz.png)

Aún más simple que registrarte en Stackblitz, crear un proyecto y cargar los archivos de tu proyecto,
este truco de una línea cargará tu proyecto de GitHub en el IDE de Stackblitz.

Simplemente comparte esta URL, usando nuevamente tu apodo de GitHub y el nombre del proyecto:  
[https://stackblitz.com/github/NICKNAME/MY_PROJECT](#)

Esto también es válido para ramas, etiquetas o commits específicos. Simplemente use el siguiente esquema para la URL:  
[https://stackblitz.com/github/NICKNAME/MY_PROJECT/tree/{TAG|BRANCH|COMMIT}](#)

Espero que esta publicación te haya ayudado a publicar tus proyectos en un lugar donde otros puedan verlos, disfrutarlos y editarlos.


Aprende a implementar fácilmente un proyecto angular CLI en Github Pages, así como a compartir una versión en live edit mode con Stackblitz

Blog