Solución enfocada al uso de Vuex 3 la cual trabaja con Vue.js 2.

Al menos yo sí lo hago porque trabajo mucho con mapeadores de contenido de la API al modelo de la vista.

En ellos solía hacer esto:

    test("should return an empty array when passes a null value", () => {
      expect(mapFormatsApiToVm(null)).toEqual([])
    })

    test("should return an empty array when passes an undefined value", () => {
      expect(mapFormatsApiToVm(undefined)).toEqual([])
    })

    test("should return an empty array when passes an empty array", () => {
      expect(mapFormatsApiToVm([])).toEqual([])
    })

A lo mejor probar estos casos uno a uno no te parecen complicados ni te molesta repetirlos una y otra vez, pero... ¿qué tal si probamos con un validador de URLs? Entonces ya sí empieza a ser un tostón porque son muchos casos a comprobar.

Jest tiene una característica que puede ayudarte a realizar tests mucho más rápido y se llama each

En este tuit te mostré cómo usarla rápidamente 👇 https://mobile.twitter.com/lissetteibnz/status/1362053307590672386

Pero lo que te quiero mostrar hoy creo que te ayudará mucho más.

Continuando con nuestro test de URL válida, vamos a probar una serie de casos:

null
undefined
""
"https://www.example.com"
"http://www.example.com"
"www.example.com"
"example.com"
"http://blog.example.com"
"http://www.example.com/product"
"http://www.example.com/products?id=1&page=2"
"http://www.example.com#up"
"http://255.255.255.255"
"255.255.255.255"
"http://www.site.com:8008"
"http://invalid.com/perl.cgi?key= | http://web-site.com/cgi-bin/perl.cgi?key1=value1&key2"

Pues bien, en vez de escribir los test agrupando por su resultado y utilizar each con ellos, vamos a utilizar each pero pasando como argumento nuestra tabla de casos.

const casesTable = [
      [false, null],
      [false, undefined],
      [false, ""],
      [false, "http://invalid.com/perl.cgi?key= | http://web-site.com/cgi-bin/perl.cgi?key1=value1&key2"],
      [true, "https://www.example.com"],
      [true, "http://www.example.com"],
      [true, "www.example.com"],
      [true, "example.com"],
      [true, "http://blog.example.com"],
      [true, "http://www.example.com/product"],
      [true, "http://www.example.com/products?id=1&page=2"],
      [true, "http://www.example.com#up"],
      [true, "http://255.255.255.255"],
      [true, "255.255.255.255"],
      [true, "http://www.site.com:8008"],
    ]

Lo que hemos hecho es crear un array donde cada item es otro array en el que el primer valor es el resultado esperado y el segundo valor el caso a testar.

Esta tabla será la que alimente el método each de nuestro test.

Seguidamente, vamos a escribir el texto del test y aprovechando la funcionalidad de template literals vamos a escapar el primer y segundo argumento en formato pretty (con este formato veremos cómo valores como el string vacío nos lo muestra así "" en vez de aparecer un hueco en el texto).

    const casesTable = [
      [false, null],
      [false, undefined],
      [false, ""],
      [
        false,
        "http://invalid.com/perl.cgi?key= | http://web-site.com/cgi-bin/perl.cgi?key1=value1&key2",
      ],
      [true, "https://www.example.com"],
      [true, "http://www.example.com"],
      [true, "www.example.com"],
      [true, "example.com"],
      [true, "http://blog.example.com"],
      [true, "http://www.example.com/product"],
      [true, "http://www.example.com/products?id=1&page=2"],
      [true, "http://www.example.com#up"],
      [true, "http://255.255.255.255"],
      [true, "255.255.255.255"],
      [true, "http://www.site.com:8008"],
    ];
    test.each(casesTable)("should return %p when passes %p value", () => {

    });

Y por último, recibiremos los parámetros para usarlos en nuestro test en el mismo orden definido en la tabla:

 const casesTable = [
      [false, null],
      [false, undefined],
      [false, ""],
      [
        false,
        "http://invalid.com/perl.cgi?key= | http://web-site.com/cgi-bin/perl.cgi?key1=value1&key2",
      ],
      [true, "https://www.example.com"],
      [true, "http://www.example.com"],
      [true, "www.example.com"],
      [true, "example.com"],
      [true, "http://blog.example.com"],
      [true, "http://www.example.com/product"],
      [true, "http://www.example.com/products?id=1&page=2"],
      [true, "http://www.example.com#up"],
      [true, "http://255.255.255.255"],
      [true, "255.255.255.255"],
      [true, "http://www.site.com:8008"],
    ];
    test.each(casesTable)("should return %p when passes %p value", (testResult, testValue) => {
      expect(isValidURL(testValue)).toBe(testResult);
    });

Y lo mejor de todo el resultado de nuestros test en la consola 😊

¿Qué te ha parecido? Espero que te resulte útil 😁

Te animo a revisar la documentación completa porque al igual que usar los template literals y las tablas en la descripción de los tests, lo puedes hacer en los describe, así que a volar tu imaginación.

Hoy te explicaré la diferencia principal entre la aserción de tipos, la inferencia de tipos y la anotación literal de tipos en TypeScript, a través de un ejemplo real con el framework Vue.

TL,DR

Vamos a trabajar con una función que nos devolverá un objeto que contendrá las propiedades de un producto.

Lo primero que haremos será definir una interface que será quien nos describa nuestro modelo de objeto:

type Price = string;
type ProductId = number;

export interface Product {
  id: ProductId;
  author: string;
  title: string;
  price: Price;
}

Ahora vamos a definir nuestra función getProduct que como hemos dicho, sólo deberá crearnos un producto.

Inferencia de tipos

Si asignamos la devolución de esta función a un objeto, TypeScript nos inferirá las propiedades que tiene. Si te fijas, no estamos haciendo uso de ningún tipado por lo que el modelo lo está infiriendo.

const getProduct = () => ({
  id: 1,
  author: 'irrelevant author',
  title: 'irrelevant title',
  price: '45.00'
})

¿Pero qué pasa con la inferencia de tipos? Pues que si no devolvemos alguna de las propiedades de la interface o las cambiamos, no se quejaría porque no está enlazada a ella y no es capaz de saber que realmente queremos retornar un objeto con un modelo concreto. En este momento, está trabajando la inferencia de tipos y no tenemos forma de cumplir una interface.

¿Cómo le decimos a TypeScript que queremos retornar, específicamente, un objeto con nuestro modelo? Por ejemplo, mediante la aserción de tipos.

Aserción de tipos

La aserción de tipos es cuando utilizamos la palabra clave as para decirle que ese valor es de X tipo.

Fíjate cómo añandiendo ahora en el retorno de la función as Product, cuando vamos a utilizar el objeto product nos dice que no está anotherProp disponible.

const getProduct = () => ({
  id: 1,
  author: 'irrelevant author',
  title: 'irrelevant title',
  price: '45.00',
  anotherProp: 'irrelevant prop',
- })
+ }) as Product

Es más, ahora si quitamos una propiedad que cumpla la interface, se quejará nuestro código (comentamos la línea del precio del producto):

const getProduct = () => ({
  id: 1,
  author: 'irrelevant author',
  title: 'irrelevant title',
  // price: '45.00',  <- ERROR: Property 'price' is missing in type '{ id: number; author: string; title: string; anotherProp: string; }' but required in type 'Product'.
  anotherProp: 'irrelevant prop'
}) as Product

Pero... ¿por qué no nos arroja un error sobre anotherProp si esa propiedad no es parte de nuestro modelo? Porque con la aserción de tipos las propiedades de más no influyen en nuestro modelo a nivel de tipos, porque si lo piensas, una vez vayas a usar el objeto, TypeScript no te mostrará esa propiedad disponible y sería como si no fuera a afectar a nuestro código.

Pero si realmente queremos que nos diga que esa propiedad no es parte de nuestro modelo y nos queremos poner estrictos, usaremos la anotación literal de tipos.

Anotación literal de tipos

- const getProduct = () => ({
+ const getProduct = (): Product => ({
  id: 1,
  author: 'irrelevant author',
  title: 'irrelevant title',
  price: '45.00',
  anotherProp: 'irrelevant prop',
})

ERROR: Type '{ id: number; author: string; title: string; price: string; anotherProp: string; }' is not assignable to type 'Product'.

Además, recuerda que esta es la forma aconsejada de tipar tus funciones por razones obvias.

Ejemplo en la vida real

¿Y saber estas diferencias para qué nos podrían servir? Pues voy a poner un ejemplo.

Últimamente estoy trabajando en un proyecto personal con Vue 3 y TypeScript, y buscando documentación y ejemplos sobre cómo tipar estructuras como el data de Vue, me encuentro con que siempre utilizan la aserción de tipos de TypeScript.

Veamos en un ejemplo qué problemas tiene usar este modelo de tipos.

Para ello, continuaremos con la definición de las interfaces anteriores para Product. Para quitar ruido, las tendremos en un fichero de tipos dentro de nuestra aplicación.

// src/types/index.ts

type Price = string;
type ProductId = number;

export interface Product {
  id: ProductId;
  author: string;
  title: string;
  price: Price;
}

Y ahora definiremos un componente que usará nuestro modelo.

Este componente tendrá una propiedad data que será donde tendremos nuestro listado de productos y el id del producto seleccionado.

<script lang="ts">
import { defineComponent } from "vue";
import { Product } from "@/types";

export default defineComponent({
  data() {
    return {
      list: [],
      selectedProductId: 0,
    }
  }
});
</script>

Lo ideal sería definir una interface para declarar este Data. Mi intención sería la siguiente:

interface Data {
  list: Product[];
  selectedProductId: Product["id"];
}

Primero, veremos cómo suelen declarar este data en los ejemplos que he visto:

// Forma común
export default {
  data() {
    return {
      list: [] as Product[],
      selectedProductId: 0
    }
  }
}

// Otra forma
export default {
  data() {
    return {
      list: [],
      selectedProductId: 0,
    } as unknown as Data;
  }
}

El problema que tiene la aserción de tipos es que tú puedes decirle que un valor será del tipo Product, pero en la inicialización pasarle un aguacate, que no se quejará de nada, porque le estás forzando el tipado. Le estás diciendo a TypeScript que confíe en ti 😅

Otro problema que tiene es que no tienes forma de unir la definición de tu interface Data de forma real. Si cambias algo, debes acordarte de cambiarlo en el data porque no te avisará de los errores.

Entonces, ¿qué podemos hacer? En este caso, el data de nuestro componente no es más que una función que retornará un objeto reactivo. Olvidemos lo de reactivo y centrémonos en una función que retorna un objeto.

Si queremos que nuestro data trabaje como anotación de tipos literales y no como aserción o inferencia, ¿por qué simplemente no le decimos el retorno que debe llevar esa función?

export default {
 data(): Data {
    return {
      list: [],
      selectedProductId: 0,
    }
  }
}

Y de esta forma, si agregamos alguna propiedad o modificamos algo en nuestra interface Data, nos arrojará un error en la definición del data del componente

interface Data {
  list: Product[];
  selectedProductId: Product["id"];
+  anotherProp: string;
}

En resumen:

¡Deja de usar as tal cosa! De hecho... creo que sólo en los reduce de creación es cuando único puede tener sentido una aserción de tipos. De resto, puede resultar un mal olor de tus tipos.

Solución con JSDoc y JavaScript

Partimos de la misma función pero esta vez en JavaScript:

export const extractObjectPath = (obj) => {
  const result = {};

  const recursivePathCalculation = (source, rootPath = [], target = result) => {
    for (const key in source) {
      if (source.hasOwnProperty(key)) {
        const path = rootPath.slice();
        path.push(key);

        const value = source[key];
        if (value !== null && typeof value === "object") {
          recursivePathCalculation(value, path, (target[key] = {}));
        } else {
          target[key] = path.join(".");
        }
      }
    }
  };
  recursivePathCalculation(obj);

  return result;
};

Recuerda que esta función nos retorna una estructura de objeto donde cada propiedad es un nivel de nuestro objeto traductor.

Para poder usarla, vamos a exportar un objeto donde llamaremos a la función anterior pasando como parámetro un objeto de traducciones.

export const tkeys = extractObjectPath({ ...es });

Y ahora llega la magia...✨ para poder inferir el tipado vamos a añadir mediante JSDoc el siguiente tipo:

/** @type typeof es */
export const tkeys = extractObjectPath({ ...es });

Fíjate que cuando decimos typeof es nos referimos a que el tipo será "el valor" que tenga el objeto que le digamos, en este caso al objeto es que se corresponde con la importación de mi fichero de traducciones al castellano.

De este modo, conseguiremos que al usar este objeto tkeys que previamente hemos importado, apoyarnos en el autocompletado que nos facilita el IDE:

🔥 Aquí puedes probarla y ver el código completo:

¿Qué te ha parecido? Espero que te sirva de ayuda.

👉 En un siguiente artículo le daremos un giro de tuerca más 🔩 y te mostraré otra forma también muy interesante de conseguir tus traducciones 👩‍💻

En JavaScript contamos con una serie de librerías que nos ayudan a dar soporte a esta funcionalidad y sin ir más lejos, existe una muy conocida llamada i18n-next, que además tiene soporte en los frameworks más conocidos y está altamente extendida.

Cuando la instalamos en nuestros proyectos la solemos usar con literales de traducción como cadenas de texto, y si bien, es una forma rápida de obtener la traducción, esta alternativa es deficiente de cara a su manipulación y refactorización, además de convertirla en un coladero de errores:

// has a mistake 👻
t("comon.cancel")

Probablemente he llamado a la traducción como "common.cancel" y sin embargo al usarla he puesto "comon.cancel"

Solución con TypeScript

Hoy te propongo crear una función que te permitirá usar la librería de una forma distinta, la cual te ayudará a refactorizar esas traducciones sin problemas y que no te equivoques al escribirla. Por fin di adiós al típico error de contineu cuando querías poner continue .

Vamos a escribir una función recursiva que será la encargada de devolvernos la cadena que espera i18n como un string, pero que nos permitirá usarla como un objeto:

export const extractObjectPath = <ObjectPath extends object>(
  obj: ObjectPath
): ObjectPath => {
  const result = {} as ObjectPath;

  const recursivePathCalculation = (
    source: object,
    rootPath: string[] = [],
    target = result
  ) => {
    for (const key in source) {
      if (source.hasOwnProperty(key)) {
        const path = rootPath.slice();
        path.push(key);

        const value = source[key];
        if (value !== null && typeof value === "object") {
          recursivePathCalculation(value, path, (target[key] = {}));
        } else {
          target[key] = path.join(".");
        }
      }
    }
  };
  recursivePathCalculation(obj);

  return result;
};

Ahora debemos exportar el objeto que usaremos en nuestra app usando esta función:

// 👉 Nuestro objeto mágico 🪄
export const tkeys = extractObjectPath({ ...es });

De este modo, conseguiremos apoyarnos en el autocompletado que nos facilita el IDE:

🔥 Aquí puedes probarla y ver el código completo:

👉 ¿No tienes TypeScript en tu proyecto? No pasa nada, aquí tienes la versión de JavaScript con JSDoc 💁‍♀️

Recursos:

• i18n API
• Wiki i18n
• i18n-next

En este artículo voy a explicar cómo podemos aplicar una medida de seguridad sencilla pero eficaz (al menos en el 99% de los casos porque evitarlo completamente es casi imposible) de cara a que el usuario no pueda tomar una captura de pantalla de nuestra aplicación cuando la abre en segundo plano.

Comenzamos desde un proyecto de React Native orientado a Android e iOS, así que primero explicaré cómo lo he hecho en Android y luego en iOS.

Configuración para Android

Por comodidad aconsejo abrir los ficheros Java desde Android Studio u otro IDE con soporte a Java para manejar sin mayor problema el código.

Vamos a abrir el fichero MainActivity.java de nuestro proyecto Android. En mi caso está dentro de la carpeta android>app>src>main>java>com>name_project

Una vez abierto, importamos el siguiente módulo:

import android.view.WindowManager;

Y seguidamente, haremos uso del mismo dentro del método onCreate (que crearemos si no está previamente creado), agregando las siguientes sentencias:

 getWindow().setFlags(
     WindowManager.LayoutParams.FLAG_SECURE,
     WindowManager.LayoutParams.FLAG_SECURE
 );

El resultado de nuestro fichero debe ser algo parecido a esto:

package com.name_project;

import android.app.Activity;
import android.os.Bundle;

import com.facebook.react.ReactActivity;

import android.view.WindowManager;

public class MainActivity extends ReactActivity {

    @Override
    protected String getMainComponentName() {
        return "name_project";
    }

    private static Activity mCurrentActivity;

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        getWindow().setFlags(
                WindowManager.LayoutParams.FLAG_SECURE,
                WindowManager.LayoutParams.FLAG_SECURE
        );

        mCurrentActivity = this;
    }

    public static Activity getActivity() {
        return mCurrentActivity;
    }
}

Configuración para iOS

Por comodidad aconsejo abrir los ficheros swift desde XCode para manejar sin mayor problema el código.

Vamos a abrir el fichero AppDelegate.swift de nuestro proyecto iOS. En mi caso está en el raíz de la carpeta ios

Dentro de este fichero y dentro de la clase AppDelegate vamos a crear dos funciones que directamente, no evitarán que el usuario pueda hacer capturas de pantalla pero lo que haremos será que cuando la aplicación detecte que está en segundo plano, cambiará la pantalla por una vista no visible con fondo negro.

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, RCTBridgeDelegate {
···

  func applicationWillResignActive(_ application: UIApplication) {
    self.window?.isHidden = true;
  }

  func applicationDidBecomeActive(_ application: UIApplication) {
    self.window?.isHidden = false;
  }
}

Conclusiones

En Android con este método nos aseguramos que directamente, usando las aplicaciones del sistema, el usuario no puede tomar una captura de pantalla ni grabar la misma por lo que tenemos una solución de seguridad rápida y eficaz. Sin embargo, en iOS no tenemos los mismos mecanismos y tenemos que ingeniárnoslas para poder hacer algo parecido. Detectamos el cambio de estado de la aplicación y ocultamos la pantalla.

Esto nos da pie a que, con un poco más de código, podamos tener pantallas customizadas para advertir al usuario de que lo que intenta realizar no está permitido. Es todo cuestión de imaginación y ponerlo en práctica.

Espero que te haya gustado. No vemos por las redes 🤪