DEV Community: leobar37

¿Por qué React 18 llama dos veces a useEffect?🙄

leobar37 — Sat, 18 Jun 2022 20:53:53 +0000

React planea agregar una característica que permite agregar o remover secciones de la interfaz, preservando el estado.
En la documentación hay ejemplo de tabs, cuando usuario se mueve a una determinada tab y vuelve a la anterior. React debe mostrar inmediatamente el anterior Tab, para que esto sea posible React admite volver a montar el árbol del componente, reutilizando el mismo estado usado antes de que se desmonte de la interfaz

Con esta característica React tendrá un mejor rendimiento, todo esto sería manejado internamente por React, pero para hacer esto posible, necesita que los componentes sean resistentes a los efectos que se montan y se desmontan varias veces. Los desarrolladores tendrían que tener consideración esto al escribir código, asegurarnos de cualquier código que este dentro del efecto no cause fugas de memoria o comportamientos no deseados cuando el componente se vuelva montar reutilizando el estado, por ejemplo, tener una suscripción doble a una misma fuente o timers que no se han limpiado.

Esto puede ser un poco confuso para las personas que recién empiezan a utilizar React, porque normalmente se dice que el array de dependencias vacío, solo sucederá una vez, ahora esto no es del todo cierto, ya que en ciertos casos el componente se va a montar dos o más veces utilizando el mismo estado como el caso de los tabs por ejemplo.

Para ayudar a afrontar estos problemas, React Strict Mode ahora tiene una nueva validación que monta y
desmonta el componente automáticamente después de montarse por primera vez, restaurando el primer
estado en la segunda vez ayudando a detectar efectos secundarios inesperados.

Una pregunta que se me vino a la mente cuando me encontré con esto, fue, ¿las peticiones a la Red, se harán múltiples veces?. Y la la respuesta es que en desarrollo esto siempre sucederá (con el modo estricto) y en producción sucederá en casos como el mencionado anteriormente, de todas maneras deberíamos evitar de usar el patrón de hacer peticiones durante el ciclo de eventos de React (fetch-on-render) o similares y utilizar los nuevos métodos empleados en librerías como react-query que proveen una mejor manera de hacer peticiones a la red y además se integran con Suspense.

Si quieres saber más acerca de esto, puedes visitar los siguientes enlaces.

¿Ya soy full stack?

leobar37 — Sat, 04 Jun 2022 22:53:39 +0000

Hace un tiempo hice un proyecto llamado ROESBA, el yo de ese entonces solo dominaba Angular y el backend que montó estaba en Python (lenguaje aprendido unas 3 semanas antes) pero bueno ese proyecto termino en mi github como un repositorio más porque no me convenció como iba a escalar, pero quiero resumir como llegué hasta aquí.

Me explico, me cuesta mucho prestar atención en clase, en realidad me parece muy aburrido, no te confundas no soy vago, lleve los primeros puestos en mi colegio y nunca desaprobé ningún curso de la universidad, el punto, es que para lograr eso, tenía que anotar los títulos que se mencionaban en la clase para investigarlos después en casa, claro, 1 semana antes del examen :), pero llegó un punto donde me planteé que tan efectivo es esto para mi futuro. Fue entonces cuando en II ciclo de universidad empecé a comprender mi manera de aprender.

Si puedo aprender las cosas de la universidad en unas cuantas horas, si me concentro, ¿por qué no trato de tomar cursos yo mismo?, fue entonces cuando me tope con Programación ATS en YouTube y me pareció interesante, después de haber aprendido un poco de algoritmia en la universidad, me enteré de que el siguiente ciclo me van a enseñar JAVA, entonces tome el curso de programación ATS en UDEMY, que en paz descanse :(, efectivamente en apenas 4 semanas estaba escribiendo código en JAVA, fue hermoso y no tan aburrido porque al final me propuse a terminar un TIC TAC TOE con un algoritmo diferente al de ATS. Obviamente, todo el ciclo siguiente no fue más que ir por la asistencia y echarme una siesta en clase.

!Eureka!, decidí convertirme en autodidacta, poner atención a la universidad lo suficiente como para aprobarla.

¿Pero ahora que estudio?, si bien ahora tengo amigos de distintos países que programan, en ese entonces no los tenía y aprender sin llegar a sentirse inservible era inevitable para mí, siempre surgían pensamientos como; mejor espero a que lo enseñen en la universidad, igual y no vale la pena forzarse tanto,esto no es para mí.

Meses después me llamo la atención la idea crear un blog, así que me puse a averiguar que es lo que se necesita para construirlo, fue ahí donde me topé con JQuery, html, javascript y css después de unos cuantos garabatos, decidí ir por este camino, el curso de Desarrollo web de Falcon Master y los videos de Fazt fueron claves para comenzar, todo era aprendizaje, horas y horas de estudio, supe que tenía que aprender un framework, así que escogí Angular, el curso de Fernando Herrera fue de mucha ayuda en esta parte.

Después me di cuenta de que la mayoría de información está en documentaciones, anotaciones de otras personas, código abierto, blogs, etc. Mi estrategia era practicar lo básico de algún tutorial e ir a por la documentación para reforzarlo, ahí fue también cuando me di cuenta de que si profundizaba más en la teoría, podía solucionar problemas mucho más rápido, y mi código estaba propenso a menos errores.

Entonces ya no me quedaba dudas, soy bueno en algo, suena irónico para mí escribirlo porque la mayoría del tiempo siempre la pasaba descontento de lo lento que aprendía. Me la pasaba escribiendo código, pero llegó el punto donde ya no sabía que hacer, que si las notas, un TODO, una agenda o un chat todo eso lo hice, ahí es donde llegó la etapa más dura para mí, porque tenía muchas cosas que aprender, pero que no tenían sentido aprenderlas, necesitaba algo donde aplicar lo que aprendía, termine con muchos proyectos incompletos.

Fue en ese entonces cuando decidí, salirme de mi rol de programador por un momento, buscar una necesidad e intentar solucionarla, ROESBA tuvo como idea desarrollar una aplicación para que los negocios pequeños puedan realizar sus cuentas de manera más fácil(todavía no abandono esa idea).

Pero bueno, si bien esa aplicación no resulto, cumplió su propósito, me mantuvo motivado y aprendí mucho, entonces supe que quería hacerlo de nuevo, pero esta vez para aprender nuevas cosas, el reto fue simple. Construir una aplicación con las tecnologías que me proponga aprender y esta vez no me complicaría mucho, tome un negocio existente y tendría que construirle una aplicación con los procesos que tenga, fue entonces cuando me puse a hacer una aplicación para administrar los procesos del gimnasio WellnessPro. Esta vez no me acelere mucho, construí mi propio diseño e intente ser lo más detallado posible.

Claro que antes de eso tuve que practicar un poco, así que intente hacer un primer borrador, con el fin de aplicar las tecnologías que me planteé y encontrar otras que me ayudaría a acelerar el desarrollo. Esta pequeña práctica duró más o menos unos 5 o 6 meses, entre risas y llantos, como dicen en mi tierra.

Después de que me sentí un poco preparado, empecé la verdadera, ahora el reto era mejorar el código cada vez más, para mí es emocionante ver como mi código evoluciona poco a poco.

Pero en fin, solo quizá pararme en este momento de mi vida a reflexionar, lo que he avanzado y lo mucho que me falta por avanzar. Ya que hoy por fin logré terminar lo que me propuse de la Aplicación. Y quiero seguir la misma metodología de aprendizaje, esta vez ya no voy tan desarmado a mi próximo proyecto.

Este es mi forma de aprender, me siento a gusto y disfruto el proceso, voy midiendo mi avance de acuerdo a los proyectos que voy logrando.

Este proyecto es de libre acceso, puedes echarle un ojito aquí:

Repositorio Central
Borrador 1
Borrador 2

¿Que es un middleware en redux?

leobar37 — Fri, 08 Apr 2022 14:59:09 +0000

Middlewares

Los Middlewares son una parte fundamental en el entorno de Redux, quizás en la práctica
solo tengamos que aprender a utilizar ciertos middlewares como redux logger por motivos de logging o redux thunk para manejar peticiones asíncronas.
Pero sería correcto aprender un poco más de ellos para tener un mejor entendimiento de nuestro código, y tener en cuenta la creación de un middleware a la hora de plantear una solución.

¿Ques un middleware?

Un middleware no es más que forma de interceptar las acciones que se envían a los reducers, dando la potestad de poder alterar el flujo de ejecución.

Dentro del código, un middleware tiene la siguiente forma:

export const myMiddlware = (api) => (next) => (action) => {
  /* do something */
};

Cuando yo vi esto por primera vez, admito que no entendí mucho, así que decidí investigar un poquito más :).

¿De donde vienen los middlewares?

Bien, redux tiene muchos beneficios y uno de ellos es que el estado es inmutable. Cada acción que de como resultado un cambio en el estado, generará un nuevo estado y se guardará.

Entonces, teniendo cuenta esto, sería genial poder registrar todos esos cambios, o solo imprimirlos por consola.

Podemos plantear las siguientes soluciones:

Wrappear la función dispatch

const useDispathcAndLog = () => {
  const dispatch = useDispatch();
  const store = useStore();

  const dispatchAndLog = (action: Action) => {
    console.log("dispatching", action);
    dispatch(action);
    console.log("next state->" + store.getState());
  };
  return dispatchAndLog;
};

Esto solucionaría el problema, pero vamos a tener que importar esta función todo
el tiempo. Es una solución poco eficiente y no es la mejor.

Monkey patching

Monkey patching es una técnica utilizada para modificar el comportamiento por defecto
de una función en tiempo de ejecución. Es una buena opción para funcionar como Polyfil.

Entonces podemos aplicar esta técnica para llamar al mismo método del store, sin tener
que importarlo

const monkeyPathchingDispatch = () => {
  const next = store.dispatch;
  store.dispatch = (action) => {
    console.log("dispatching", action);
    let result = next(action);
    console.log("next state", store.getState());
    return result;
  };
};
monkeyPathchingDispatch();

Bien, analicemos lo que está pasando aquí:

Guardo el dispatch original en una variable llamada next
Sobreescribo la función original agregando la funcionalidad de logging y ejecuto la original, porque a la vista del usuario esto no tiene que tener cambio alguno.
Se ejecuta la función al inicio de la aplicación

Bien, hasta aquí esto funciona muy bien, pero nos enfrentamos a ciertos problemas con este enfoque.

Esta técnica es considerada peligrosa, porque, este no es un comportamiento por defecto
de la api de Redux.
Tener uno o más middlewares puede causar redundancia de código.

Para solucionar estos inconvenientes, se puede optar por hacer una manera genérica
de aplicar varios middleware

const loggerMiddleware = (store) => {
  const next = store.dispatch;
  return (action) => {
    console.log("dispatching", action);
    let result = next(action);
    console.log("next state", store.getState());
    return result;
  };
};

const createErrorAction = (message: string) => {
  return {
    type: "ERROR",
    message: message,
  };
};

const errorMiddleware = (store) => {
  const next = store.dispatch;
  return (action) => {
    try {
      return next(action);
    } catch (error: { message: string }) {
      return next(createErrorAction(error?.message));
    }
  };
};

const createErrorAction = (message: string) => {
  return {
    type: "ERROR",
    message: message,
  };
};

const errorMiddleware = (store) => {
  const next = store.dispatch;
  return (action) => {
    try {
      return next(action);
    } catch (error: { message: string }) {
      return next(createErrorAction(error?.message));
    }
  };
};

function applyMiddlewareByMonkeypatching(store, middlewares) {
  middlewares = middlewares.slice();
  middlewares.reverse();
  middlewares.forEach((middleware) => (store.dispatch = middleware(store)));
}
applyMiddlewareByMonkeypatching(store, [logger, errorMiddleware]);

Hasta este momento se ha reducido la necesidad de aplicar la técnica por cada middleware. a solo una, pero todavía se sigue implementando.

Removiendo Monkey Patching

Todo lo anterior funciona, pero no de una manera muy eficiente, el primer problema
es que al hacer una llamada a store.dispatch se llama a la función original.
Durante la ejecución del middleware, puede que este no sea el comportamiento que se desee.

En este caso el middleware errorMiddleware al no acceder a dispatch wrapeado por
loggerMiddleware, no podrá imprimir los detalles de la acción.

De ahí viene la idea de aceptar la función next como parámetro, la cual es la
función previamente wrapeada por el middleware anterior.

const loggerMiddleware = (store) => {
  return (next) => (action) => {
    console.log("dispatching", action);
    let result = next(action);
    console.log("next state", store.getState());
    return result;
  };
};
const errorMiddleware = (store) => {
  return (next) => (action) => {
    try {
      return next(action);
    } catch (error: { message: string }) {
      return next(createErrorAction(error?.message));
    }
  };
};

Ahora next no es obtenido del store ,en lugar de eso, se acepta como parámetro

Ahora solo quedaría la aplicación de estos middleware funcionaría así.

function applyMiddleware(store, middlewares) {
  middlewares = middlewares.slice();
  middlewares.reverse();
  let dispatch = store.dispatch;
  middlewares.forEach((middleware) => (dispatch = middleware(store)(dispatch)));
  return Object.assign({}, store, { dispatch });
}

Esta no es una implementación real de redux.
applyMiddleware. La función original hace ciertas mejoras.

El store solo expone dispatch y getState
Se asegura de que llama a Store.dispatch, su acción recorrerá toda la cadena de middlewares.
Se asegura de que solo llame a applyMiddleware una vez.

El procedimiento de este artículo fue de la documentación de Redux.

Conclusión

Los middleware, sirven poder hacer algo con la acción antes de que llegué
al reducto final. La primera función del middleware es una función reducida del store, la segunda función es la función dispatch previamente empaquetada y la última es la función
que será llamada por el usuario.

Happy Coding😁

Inmutabilidad

leobar37 — Thu, 31 Mar 2022 15:35:06 +0000

El concepto de inmutabilidad es muy importante dentro del entorno de React, ya que sin dominar
este concepto, podemos estar causando renderizados extra o efectos secundarios dentro de nuestra aplicación.

¿Qué es inmutabilidad?

Un objeto inmutable es aquel objeto que no puede ser modificado una vez creado, no puede cambiar su estructura ni los datos que contiene, este no es el caso de las constantes, porque cuando sea crea una constante, quizás no se puede reasignar el valor, pero si cambiar su estructura.

const case1 = {
  nem: "nem",
  nim: "nim",
};
case1.nim = "nom";
/*
{
   "nem": "nem",
   "nim": "nom"
}
*/
const case2 = {
  nem: "Hello",
};
// Cannot assign to 'case2' because it is a constant
case2 = case1;

Este ejemplo demuestra que las constantes puede ser modificadas, pero no pueden reasignarse.

Para entender que es inmutabilidad un poco más clara hay que echar un vistazo a como funcionan los objetos en JavaScript.

Valores inmutables

Los valores inmutables o primitivos son aquellos que se almacenan completos en memoria, estos son strings, numbers, booleans, null y undefined. Es decir, estos tiene un lugar propio en memoria.

let case1 = "wenas";
let case2 = "wenas";

Por ejemplo estos dos variables son almacenadas de la siguiente manera:

Entonces al ser objetos primitivos, su valor es el mismo

const areEqual = (a, b) => {
  return a === b;
};

const case1 = "wenas";
const case2 = "wenas";

console.log(areEqual(case1, case2));
//  true

Valores mutables:

En el caso de los objetos no pasa lo mismo que con los primitivos, estos son almacenados de manera distinta.

const case3 = { name: "pepe", lastName: "perez" };
const case4 = { name: "pepe", lastName: "perez" };

console.log(areEqual(case3, case4));
// false

Eso es porque una variable asignada a un objeto, no es almacenado en el objeto en sí, este solo almacena su dirección de memoria.

Se puede decir que un objeto es como una agenda con las direcciones
de memoria de otros objetos, entonces cuando hace algo con alguna de las propiedades como case.name el motor de JavaScript toma esa dirección de memoria y realiza la operación en el objeto real.

Copiar un objeto:

Cuando copiamos un objeto, copiamos la referencia, Por ejemplo:
Supongamos que tenemos un objeto usuario y queremos copiarlo, para a partir de él, crear un usuario 2.

const user1 = { name: "pepe", lastName: "perez" };
const user2 = user1;
console.log(areEqual(user1, user2));
// true

En este caso podríamos decir que user2 tiene la misma información a que user1 y, por lo tanto, son iguales.

const user1 = { name: "pepe", lastName: "perez" };
const user2 = user1;
user2.name = "pepe2";
console.log(areEqual(user1, user2));
// true

Pero si alteramos la propiedad de user2, siguen siendo iguales, ¿Por qué?, bueno, eso es porque al hacer const user2=user1 estamos creando una referencia a las mismas direcciones de memoria, y al afectar user2.name afecta a user1.name también.

const user1 = { name: "pepe", lastName: "perez" };
const user2 = user1;
user2.name = "pepe2";

console.log(areEqual(user1, user2));
// true
console.log({
  user1,
  user2,
});

/**
 *  {
 *   user1 : {
 *    name :"pepe2",
 *    lastName :"perez"
 *  },
 *   user2 : {
 *    name :"pepe2",
 *    lastName :"perez"
 *  }
 * }
 */

Esto se tiene que tener en cuenta a la hora de escribir código.
Porque podemos crear efectos secundarios sin querer. La manera efectiva de hacerlo sería la siguiente.

const user1 = { name: "pepe", lastName: "perez" };
const user2 = { ...user1 };
user2.name = "pepe2";
console.log(areEqual(user1, user2));
// false

En este caso, al utilizar spreed operator, para sacar toda la propiedad de user1 y pasársela a user2 el cual es un nuevo objeto(nueva direcciones de memoria). También podemos utilizar object.assign

Inmutabilidad en React

Provocar efectos secundarios en React puede ser peligroso. EnReact para hacer la diferencia del estado anterior y el nuevo devuelto, hace igualdad estricta, porque, sería un impacto de performance hacer una igualación a profundidad.

Por eso es que se prohíbe el uso de cualquier método que mute el estado, como en el caso de los array como Array.prototype.push porque mutan el array, a diferencia de [Array.prototype.filter] el cual devuelve uno nuevo.

Never mutate this.state directly, as calling setState() afterwards may replace the mutation you made. Treat this.state as if it were immutable.
docs

Por ejemplo, hacer esto es incorrecto.

export default function App() {
  const [array, setArray] = React.useState([1, 2]);
  return (
    <button
      onClick={() => {
        array.push(3);
        setArray(array);
      }}
    ></button>
  );
}

la forma correcta de hacerlo sería la siguiente:

export default function App() {
  const [array, setArray] = React.useState([1, 2]);
  return (
    <button
      onClick={() => {
        setArray([...array, 4]);
      }}
    ></button>
  );
}

Immer al rescate

Teniendo en cuenta la inmutabilidad y su importancia dentro de nuestras aplicaciones, en cierto punto puedes toparte con código así.

const state = {
  prop1: {
    prop11: "1",
    prop12: "2",
    prop13: {
      prop131: "1",
      prop132: {
        prop1321: "1",
      },
    },
  },
  prop2: {
    prop21: "2",
  },
};

// changue  prop1321 to "2"  :)

const nextState = {
  ...state,
  prop1: {
    ...state.prop1,
    prop13: {
      ...state.prop1.prop13,
      prop132: {
        ...state.prop1.prop13.prop132,
        prop1321: "2", // :(
      },
    },
  },
};

Immer que hace que la inmutabilidad sea facil de hacer.

import produce from "immer";

const state = {
  prop1: {
    prop11: "1",
    prop12: "2",
    prop13: {
      prop131: "1",
      prop132: {
        prop1321: "1",
      },
    },
  },
  prop2: {
    prop21: "2",
  },
};

const nextState = produce(state, (draftState) => {
  draftState.prop1.prop13.prop132.prop1321 = "2"; //:)
});

Lo que hace immer es aplicar temporalmente los cambios a drafStateel cual es un proxy. Una vez que la mutación es completada, immer se encarga de producir el siguiente estado, basado en las mutaciones a draftState.

De esta forma no tenemos que preocuparnos de afectar el estado, de hecho, ni de retornar el estado de borrador. Immer ofrce otras características, como utilities para facilitar su uso e integración con react con el paquete use-immer.

Conclusiones

Declarar una variable como constante, evita que se reasigne más no que sea mutada.
Entender inmutabilidad puede ser fundamental en React, porque eso evita que se produzcan efectos secundarios.
Immer facilita la inmutabilidad encargándose de todo el proceso y encargándose de que el resultado sea el correcto.

Happy coding :)

Introducción react-redux y redux toolkit

leobar37 — Wed, 23 Mar 2022 23:52:07 +0000

Después de haber entendido algunos conceptos de Redux, llegó el momento de utilizarlo como tal 😁.

Setup

Para hacer el setup de la app usaré vite. Vite es una alternativa a webpack, el cual mejora la experiencia de usuario y es mucho más rápido. Si quieres saber más acerca de los beneficios de vite, puedes visitar el siguiente artículo

Para crear una aplicación con vite y react, solo es necesario abrir tu consola y poner el siguiente comando.

yarn create vite redux-tutorial --template react-ts

La opción de --template le dice a vite con que template inicializar el proyecto, en este caso el de react-ts ahora ya se tendrá la siguiente estructura.

Ahora empecemos con las dependencias, como habíamos dicho utilizaremos redux con react, para eso tenemos que instalar el paquete react-redux, el cual trae lo necesario para hacer la conexión a redux, además a ellos vamos a instalar @reduxjs/toolkit el cual trae algunos superpoderes para redux

yarn add react-redux @reduxjs/toolkit

¿Que es redux toolkit?

Redux esta bien, pero era un poco complicado. Actualmente, contamos con Redux toolkit él ofrece las siguientes soluciones:

Simplifica la configuración de redux
Elimina la necesidad de agregar múltiples paquetes para tener una aplicación escalable.
Reduce el código repetitivo.

Actualmente no se recomienda usar react-redux sin @reduxjs/toolkit.

Preparando el Store

Para empezar a escribir lógica con redux, lo primero que se tiene que hacer es configurar el Store. Para eso Redux toolkit provee un método que nos ayuda con el procedimiendo, el cual se llama configureStore.

// store/index.ts

import { configureStore } from "@reduxjs/toolkit";

export const store = configureStore({
  reducer: {},
  devTools: process.env.NODE_ENV !== "production",
});

export default store;

configureStore

Ahora ya tenemos él store :) . Al hacer esto redux-toolkit ha puesto algunas configuracioens por defecto, las cuales iré comentando conforme avancemos en el ejemplo. En este instante podemos hablar de las devTools las cuales son indispensables para poder depurar la aplicación. En este caso la opción devtools se activa solo en producción, también puedes personalizar el funcionamiento, pasando un objeto de opciones.

Conexión con React

Ahora es momento de poner disponible el store hacia React, para eso react-redux provee un Provider para poner disponible el Store en todo el árbol de componentes.

import "./App.css";
import { Provider as ReduxProvider } from "react-redux";
import store from "./store";

function App() {
  return (
    <ReduxProvider store={store}>
      <div></div>
    </ReduxProvider>
  );
}

export default App;

Estructura de archivos en Redux

Ahora que ya se tiene la tienda en el nivel superior de la aplicación, es hora la lógica de nuestra aplicación, en este caso vamos a hacer una agenda de contactos, para poder realizar un CRUD. Antes de continuar necesitamos tener en cuenta algo muy importante, el cual es la estructura de los archivos. Si bien React es una librería muy flexible frente a la estructura de archivos, Redux poner a nuestra disposición una estructura base, para a partir de eso organizar nuestros archivos.

Pensando en Ducks

Ducks es una propuesta que básicamente propone que empaquetemos un conjunto de acciones, reductores, nombres de acciones a una funcionalidad en concreto, llamando a esta agrupación duck el cual, tranquilamente, puede empaquetarse y distribuirse como una librería.

Ahora, teniendo un poco en cuenta los patos 😅, vamos a dividir la aplicación en algo parecido, pero le llamaremos features. De esta manera.

Feature Structure:

Como se mencionaba en un inicio, el ecosistema de React es muy flexible a la hora de organizar los archivos. Teniendo en cuenta los elementos de redux, al momento de partir una feature debemos dividir actions, reducer, selectors esto mejora la organización.

En mi caso inspirado un poco en el siguiente artículo, mi estructura es la siguiente.

View: Carpeta donde van las vistas que el usuario va a ver en pantalla, generalmente todos los componentes que son utilizando junto con el router de la aplicación. Por ejemplo, si estamos creando una aplicación de inventarios, el listado de estos productos podrían ir en una pantalla producs/list.

Componentes: Normalmente, se querrá tener una carpeta components en general, donde estén ubicados todos aquellos componentes, que pueden ser usados en cualquier lugar, una feature puede tener componentes que sean propios de la característica, por ejemplo el listado, de productos.

actions: En esta carpeta irán todas las acciones ligadas a esta característica.

reducer: Cada feature tiene como regla que debe exportar un solo reductor, eso no quiere decir que solo tengamos que concentrar toda lógica en un solo reducer, podemos usar combineReducers para combinar múltiples reducer en unos solo si es que fuese necesario.

Puedes pensar en una feature como una mini aplicación dentro de una aplicación, este se encarga de un proceso en concreto, que al final aportará un valor agregado a la aplicación en general.

Accciones

Las acciones son objetos planos que expresan una intención de cambiar el estado, eso es lo que se mencionó en el artículo anterior. Puedes pensar en una acción como un evento ocurrido en la aplicación, por ejemplo; se agregó un producto, se eliminó un contacto, cargando contactos, todos ellos describen algo que está pasando en al app.

Dicho esto podemos empezar a escribir acciones, las acciones tiene un estándar que indican que deben ser así.

{
  type: 'ADD_TODO',
  payload: {
    text: 'Do something.'
  }
}

Creadores de acciones:

Normalmente, las acciones puede despacharse de la siguiente manera.

store.dispatch({ type: "ITEM_ADDED_TO_CART", payload: 47 });

Pero en cierto punto, poner el tipo, cada vez que queramos despachar esta acción, no es muy escalable porque si se quisiera cambiar el tipo de acción, tendría que hacerlo en diferentes archivos y además, se vuelve complicado repetir lo mismo.

Ahí es donde entran loas creadores de acciones, que no son nada más que funciones encargadas de crear este objeto, un creador de acción sería el siguiente.

function doAddToDoItem(text) {
  return { type: "TODO_ADDED", payload: text };
}

Entonces, cada vez que se requiera formar esta acción, solo es necesario ejecutar doAddToDoItem.

Redux toolkit Simplifica este procedimiento con un utility llamado createAction el cual es una HOF(higher order function) los cuales son funciones que retornan funciones.

// features/schedule/actions/schedule.actions.ts
import { createAction } from "@reduxjs/toolkit";

export const contactAdded = createAction("CONTACT_ADDED");

Ahora contactAdded es una función que al ser disparada creará una acción de tipo CONTACT_ADDED es importante saber que por recomendación de redux las acciones deben ser "Descripciones de eventos que ocurrieron" en lugar expresarlas en presente, como por ejemplo ADD_CONTACT.

Payload:

Hasta este paso se creó la acción contactAdded, pero esto no es suficiente para agregar un contacto, se necesitaría la información de ese contacto. En el caso de typescript redux toolkit tiene un genérico para poder describir el payload.

import { createAction } from "@reduxjs/toolkit";

export const contactAdded =
  createAction<{ name: string; phone: string }>("CONTACT_ADDED");

Listo ahora el primer parámetro(payload) de contactAdded estará tipado.

Reducer

Como se mencionó anteriormente, los reducers son funciones puras que toman el estado actual y la acción para retornar un nuevo estado.

Redux toolkit exporta una función llamada createReducer la cual facilita la creación de un reducer agregando ciertas características que facilitan el desarrollo.

import { createReducer } from "@reduxjs/toolkit";

const initalState = {
  contacts: [],
};

export type ScheduleState = typeof initalState;

const reducer = createReducer(initalState, (builder) => {});

Esta sería la forma de crear un reducer con Redux toolkit

Case:

Anteriormente vimos, que cuando creamos un reducer dentro de el planteamos un switch...case para manejar cada acción.

const reducer = (state, action) => {
  switch (action) {
    case "EAT": {
      return {
        ...state,
        eatCount: state.eatCount + 1,
      };
    }
  }
};

Redux toolkit propone una forma más amigable de hacerlo, mediante un objeto builder, el cual expone una serie de métodos como addCase con el cual le recibe como parámetros.

ActionCreator: La función generada por createActiono una acción como tal.

Reducer: El reducer encargado solo de manejar esta acción.

Incorporando la lógica de agregar contacto, tendríamos lo siguiente.

import { createReducer } from "@reduxjs/toolkit";
import * as scheduleActions from "../actions/schedule.actions";

export interface IContact {
  id: number;
  name: string;
  phone: string;
}
const initalState = {
  contacts: [] as IContact[],
};

export type ScheduleState = typeof initalState;

const reducer = createReducer(initalState, (builder) => {
  builder.addCase(scheduleActions.contactAdded, (state, action) => {
    state.contacts.push({
      id: state.contacts.length,
      name: action.payload.name,
      phone: action.payload.phone,
    });
  });
});

Si eres curioso. La manera en como builder encadena todos los casos sigue fluent Style😶 .

Hay algo notable aquí, y es que al parecer no estamos siguiendo el primer principio de Redux, que dice que el estado es de solo lectura, ose es inmutable. Bueno podemos ahorrarnos esa preocupación con Immer, el cual explicaré en el siguiente parte :).

Happy Coding😄

Introducción react-redux y redux toolkit

leobar37 — Wed, 23 Mar 2022 23:32:09 +0000

Después de haber entendido algunos conceptos de Redux, llegó el momento de utilizarlo como tal 😁.

Setup

Para crear una aplicación con vite y react, solo es necesario abrir tu consola y poner el siguiente comando.

yarn create vite redux-tutorial --template react-ts

La opción de --template le dice a vite con que template inicializar el proyecto, en este caso el de react-ts ahora ya se tendrá la siguiente estructura.

yarn add react-redux @reduxjs/toolkit

¿Que es redux toolkit?

Redux esta bien, pero era un poco complicado. Actualmente, contamos con Redux toolkit él ofrece las siguientes soluciones:

Simplifica la configuración de redux
Elimina la necesidad de agregar múltiples paquetes para tener una aplicación escalable.
Reduce el código repetitivo.

Actualmente no se recomienda usar react-redux sin @reduxjs/toolkit.

Preparando el Store

// store/index.ts

import { configureStore } from "@reduxjs/toolkit";

export const store = configureStore({
  reducer: {},
  devTools: process.env.NODE_ENV !== "production",
});

export default store;

configureStore

Conexión con React

Ahora es momento de poner disponible el store hacia React, para eso react-redux provee un Provider para poner disponible el Store en todo el árbol de componentes.

import "./App.css";
import { Provider as ReduxProvider } from "react-redux";
import store from "./store";

function App() {
  return (
    <ReduxProvider store={store}>
      <div></div>
    </ReduxProvider>
  );
}

export default App;

Estructura de archivos en Redux

Pensando en Ducks

Ahora, teniendo un poco en cuenta los patos 😅, vamos a dividir la aplicación en algo parecido, pero le llamaremos features. De esta manera.

Feature Structure:

En mi caso inspirado un poco en el siguiente artículo, mi estructura es la siguiente.

actions: En esta carpeta irán todas las acciones ligadas a esta característica.

Puedes pensar en una feature como una mini aplicación dentro de una aplicación, este se encarga de un proceso en concreto, que al final aportará un valor agregado a la aplicación en general.

Accciones

Dicho esto podemos empezar a escribir acciones, las acciones tiene un estándar que indican que deben ser así.

{
  type: 'ADD_TODO',
  payload: {
    text: 'Do something.'
  }
}

Creadores de acciones:

Normalmente, las acciones puede despacharse de la siguiente manera.

store.dispatch({ type: "ITEM_ADDED_TO_CART", payload: 47 });

Ahí es donde entran loas creadores de acciones, que no son nada más que funciones encargadas de crear este objeto, un creador de acción sería el siguiente.

function doAddToDoItem(text) {
  return { type: "TODO_ADDED", payload: text };
}

Entonces, cada vez que se requiera formar esta acción, solo es necesario ejecutar doAddToDoItem.

Redux toolkit Simplifica este procedimiento con un utility llamado createAction el cual es una HOF(higher order function) los cuales son funciones que retornan funciones.

// features/schedule/actions/schedule.actions.ts
import { createAction } from "@reduxjs/toolkit";

export const contactAdded = createAction("CONTACT_ADDED");

Payload:

import { createAction } from "@reduxjs/toolkit";

export const contactAdded =
  createAction<{ name: string; phone: string }>("CONTACT_ADDED");

Listo ahora el primer parámetro(payload) de contactAdded estará tipado.

Reducer

Como se mencionó anteriormente, los reducers son funciones puras que toman el estado actual y la acción para retornar un nuevo estado.

Redux toolkit exporta una función llamada createReducer la cual facilita la creación de un reducer agregando ciertas características que facilitan el desarrollo.

import { createReducer } from "@reduxjs/toolkit";

const initalState = {
  contacts: [],
};

export type ScheduleState = typeof initalState;

const reducer = createReducer(initalState, (builder) => {});

Esta sería la forma de crear un reducer con Redux toolkit

Case:

Anteriormente vimos, que cuando creamos un reducer dentro de el planteamos un switch...case para manejar cada acción.

const reducer = (state, action) => {
  switch (action) {
    case "EAT": {
      return {
        ...state,
        eatCount: state.eatCount + 1,
      };
    }
  }
};

Redux toolkit propone una forma más amigable de hacerlo, mediante un objeto builder, el cual expone una serie de métodos como addCase con el cual le recibe como parámetros.

ActionCreator: La función generada por createActiono una acción como tal.

Reducer: El reducer encargado solo de manejar esta acción.

Incorporando la lógica de agregar contacto, tendríamos lo siguiente.

import { createReducer } from "@reduxjs/toolkit";
import * as scheduleActions from "../actions/schedule.actions";

export interface IContact {
  id: number;
  name: string;
  phone: string;
}
const initalState = {
  contacts: [] as IContact[],
};

export type ScheduleState = typeof initalState;

const reducer = createReducer(initalState, (builder) => {
  builder.addCase(scheduleActions.contactAdded, (state, action) => {
    state.contacts.push({
      id: state.contacts.length,
      name: action.payload.name,
      phone: action.payload.phone,
    });
  });
});

Si eres curioso. La manera en como builder encadena todos los casos sigue fluent Style😶 .

Happy Coding😊

Introducción a Redux

leobar37 — Fri, 18 Mar 2022 21:26:02 +0000

Redux es una de las librerías más utilizadas al momento de pensar en el manejo de estado de nuestra aplicación.
Criticada y amada por muchos desarrolladores. Hace que haya diferentes opiniones acerca del uso de redux.

Dentro de esta serie de artículos quiero compartir desde mi perspectiva el uso de redux, aclaro que no profundizaré
en algunos conceptos, pero dejaré algunas referencias para que puedas leerlo.

¿Que es redux?

Redux es una librería que nos permite manejar el estado de nuestra aplicación web.

La idea detrás de redux es que este puede contener la información predecible del estado de nuestras aplicaciones web.

La construcción de redux fue influenciada por flux la cual es una arquitectura
que facebook utilizaba para construir sus aplicaciones web, pero tratando de reducir su complejidad tomando cosas de Elm el cual es un lenguaje funcional que se compila a javascript.

¿Que es el estado?

Cuando no referimos al estado de nuestra aplicación nos podemos referir a como los datos que tenemos son reflejados en nuesta apliación web.
Esto asegura que el usuario siempre está sincronizado con el estado interno de nuestra aplicación.

Una de la gran ventaja de los frameworks es que facilitan el control de estos datos a travéz de algoritmos que facilitan la detección de cambios.

Estado local:

En react el estado local de un componente puede ser manejar con useState en el caso de utilizar funciones.

import { useState } from "react";
const LocalState = () => {
  const [hi, sayHi] = useState("");

  return (
    <div>
      <button onClick={() => sayHi("Hello")}>Say Hi</button>
      <h1>{hi}</h1>
    </div>
  );
};

De esta función entendemos que hi es el estado actual, y la forma de como actualizarlo este estado es con la función sayHi.

Podemos imaginar a redux de igual manera, pero en este caso el estado no solo será un componente, será de toda la aplicación y esto implica que podemos suscribirnos a los cambios del estado desde cualquier componente sin importar su jerarquía y de igual manera afectarlo.

¿Por que usar redux?

Utilizar redux en nuestras aplicaciones se ha vuelto cuestionable por las alternativas más livianas y fáciles de usar que existen, tales como; zuztand, recoil e incluso la api de Context que ofrece el propio react. Me ahorraré este debate 😅 y lo sintetizaré en lo siguiente.

Si tenemos un estado complejo, la capacidad de redux para describir que es lo que hace nuestra aplicación es increíble.
Puede ver todo el estado de la aplicación y las acciones que afectan este estado, de esta manera, abre la facilidad de poder agregar nuevas características.
Redux incluye otros beneficios como el debugging, con herramientas de desarrollo que nos permite rastrear las acciones para poder encontrar mucho más rápido el origen de un error.
Redux es estricto con la estructura del código, eso quiere decir que cualquiera que sepa redux puede entender nuestra aplicación.

Posiblemente esta explicación quedo un poco corta, si ese es el caso, puedes leer el siguiente artículo de Christian Nwamba

Principios de redux

Junto con redux vienen ciertos principios que hay que tener en cuenta a la hora de utilizarlo. Los cuales son tres.

Única fuente de verdad

Toda la información estará guardada en único Store el cual expone una API para acceder a los datos. Esto facilita la depuración de la aplicación, tener un estado persistente, poder serializar el estado del servidor y guardarlo en el cliente.

El estado es de solo lectura

Este principio evita que tanto las vistas o las llamadas al server afecten el estado. Para hacerlo ello expresan un intento de transformar el estado por medio de acciones, las acciones son objetos planos que pueden ser serializados y
almacenados y depurarlos, gracias a este enfoque existen las Redux Dev Tools, donde tenemos todas las acciones que han sido despachadas.

Pero, ¿esto igual no es escriben en el estado?, La respuesta es no y se complementa con el siguiente principio.

Los cambios son hechos con funciones puras

Primero que nada, ¿Qué es una función pura?. Una función pura es una función que no tiene efectos secundarios, esto quiere decir que siempre que se tengan los mismos parámetros el resultado será siempre el mismo.

En redux estas funciones son llamadas reductores el cual recibe como primer parámetro el estado actual y como segundo parámetro
la acción. Podemos usar estos parámetros para retornar el siguiente estado de nuestra aplicación.

Dando respuesta a la anterior pregunta, no escribimos en el estado, si queremos cambiar algo, lo cambiamos por completo. A esto se conoce como inmutabilidad.

Conceptos

Para ir paso a paso y teniendolo como guia tomaré este diagrama:

Pasito a pasito, lo que se ven en el diagrama es como se comporta redux y como interactúan los elementos que lo componen.

Store: Previamente, ya se había adelanto lo que llegaría ser un store. El cual es un objeto que contiene el estado y métodos que nos ayudan a interactuar con este, como por ejemplo suscribirnos a los cambios o disparar una acción.

Acción: Las acciones son objetos planos que tienen la siguiente estructura

interface Action {
  type: string;
  payload: any;
}

Como sabemos hasta ahora, redux está inspirado en flux y de hecho heredó el estándar de acción.

La propiedad type es de tipo string y es el nombre de la acción que se está disparando, esta propiedad prácticamente describe de que trata el payload. Tener en cuenta que la propiedad es una constante, por ende debe ir en mayúscula, no es opcional, el payload sí.

De echo vamos a analizar este método, si no has usado Array.prototype.reduce puedes echarle un vistazo a la documentación pero básicamente es una función al cual se le pasa dos parámetros, una función reductora y un estado inicial.

Por ejemplo, podemos utilizar reduce para sumar todos los número de un array:

const nums = [1, 2, 3, 4, 5, 6, 7, 8];
const result = nums.reduce((prev, curr) => prev + curr, 0);

Una función reductura es una función pura que recibe el resultado que se obtiene de la ejecución de la función reductura anterior y el valor actual que la iteración.

Podemos hacer que esto nos ayude a comprender un poco redux. Atención al siguiente ejemplo.

Estado inicial:

const initalState = {
  eatCount: 0,
  sleepCount: 0,
  readCount: 0,
};

Tenemos un objeto que almacena las veces que hemos realizado una determinada acción.

Acciones:

const ACTIONS = ["EAT", "SLEEP", "READ", "SLEEP", "EAT"];

Digamos que estas son las acciones que hemos realizado hasta el momento, ahora necesitamos un mecanismo que nos ayude a sumar estas acciones en el objeto.

Función reductora:

const reducer = (state, action) => {
  switch (action) {
    case "EAT": {
      return {
        ...state,
        eatCount: state.eatCount + 1,
      };
    }
    case "SLEEP": {
      return {
        ...state,
        sleepCount: state.sleepCount + 1,
      };
    }

    case "READ": {
      return {
        ...state,
        readCount: state.readCount + 1,
      };
    }
  }
};

Notese que hemos cambiado los nombres de los parámetros de la función reductora prev -> state y curr -> action. Entonces tenemos mapeado cada acción a un proceso determinado. y retornamos un estado diferente.

Ahora ya tenemos lo suficiente para utilizar reduce.

const result = ACTIONS.reduce(reducer, initalState);
/*
 Output:
 {
     "eatCount": 2,
    "sleepCount": 2,
    "readCount": 1
}
*/

Ahora, ¿Cómo esto se asemeja a redux?, bueno, en redux en lugar de que estas acciones ocurran de manera síncrona, estas acciones ocurren de manera secuencial.
Las acciones se van disparando el Store las escuchas y ejecuta el reducer correspondiente.

Middleware:

Si bien middleware es un concepto un poco amplio, podemos tener una pequeña introducción con el ejemplo que se acaba de ver.

Los middleware son funciones que puede tomar el control entre el viaje de
la acción hacia el reducer. o del resultado del reducer hacia el store.
Podemos usar el middleware para distintos casos, como hacer peticiones asincronas, como es el caso de reux-thunk, pero uno de los más comunes es hacer un logging de las acciones.

Logger:

const logger = (reducer) => {
  return (state, action) => {
    const nextState = reducer(state, action);
    console.log(action, "->", nextState);
    return nextState;
  };
};

Esta función lo que hace es tomar el reducer y retornar un nuevo reducer el cual ejecuta esta función para obtener el nuevo estado e imprimirlo en pantalla.

const result = ACTIONS.reduce(logger(reducer), initalState);

Salida:

Hasta aquí la introducción a redux :). Happy Coding

link del ejemplo: https://stackblitz.com/edit/react-ts-ur6qfs?file=index.tsx

Decoradores en typescript (parte 2)

leobar37 — Sat, 30 Oct 2021 04:10:51 +0000

Decoradores en typescript

Hola, en este post veremos un poco sobre decoradores, específicamente en TypeScript, en el post anterior vimos sobre el patrón en decorador en sí y cuál es su beneficio.

En Frameworks como Angular o (Nestjs)[https://nestjs.com/] se ve a cada momento los decoradores, para definir componentes, servicios, controladores etc. y todo esto hace que sea como mágico, pero la gran verdad es que detrás de una simple anotación puede estar escondida mucha lógica de por medio. Es un poco curioso porque esto es una característica experimental en TypeScript y esta como propuesta en javascript.

En TypeScript un decorador es un tipo especial de declaración que puede ser aplicado a clases, métodos, propiedades y parámetros y es llamada en tiempo de ejecución con información acerca de la declaración decorada.

En este post se va hablar de 3 tipos de decorador:

Class
Property
Method

Decorador de clase

Con este decorador es posible interceptar la clase y hacer algo con ella.

Por ejemplo; podemos agregar propiedades y metodos a la clase.

function print(target: any) {
  return class extends target {
    printVersion = 1;

    print() {
      const toString = Object.entries(this).reduce(
        (prev, curr) => prev + `${curr[0]} : ${curr[1]}\n`,
        ''
      );
      console.log(toString);
    }
  } as any;
}

La función print es un decorador el cual debe ser llamando con la siguiente anotación @decorator.

Todos los decoradores de clase van a recibir como parámetro la clase sobre el cual se está aplicando el decorador para poder hacer algo con ella en este caso, estamos extendiendo esta clase, agregando el método print.

interface Person {
  print(): void;
}

@print
class Person {
  name = 'leo';
  age = 10;
  constructor() {}
}

const person = new Person();

person.print();
/**
name : leo
age : 10
printVersion : 1
 */

La razón por la cual hay existe la interfaz Person es porque los decoradores pueden agregar funcionalidades, pero no pueden comunicar el tipado de estas funcionalidades. Pero en TypeScript existe combinación de declaraciones, lo cual permite combinar dos o más declaraciones con el mismo nombre.

Para entenderlo un poco mejor vamos a alterar el constructor de la clase a través de un decorador.

function noise(target: any) {
  return class extends target {
    constructor(...args: any[]) {
      console.log('Hello friend I am instantiating');
      super(args);
      console.log('i am already instantiated');
    }
  } as any;
}

El decorador noise modifica el constructor de la clase objetivo agregando un mensaje antes y después.

@noise
@print
class Person {
  name = 'leo';
  age = 10;
  constructor() {
    console.log(':o');
  }
}

const person = new Person();

person.print();

/*
Hello friend I am instantiating
:o
i am already instantiated
name : leo
age : 10
printVersion : 1
*/

Decorador de propiedades

Así como podemos interceptar las clases, también podemos interceptar las propiedades, para que una función pueda ser utilizado como decorador de propiedad, tiene que recibir dos argumentos la clase y el nombre de la propiedad.

function propertyDecorator(target: any, key: string | Symbol) {

}

Veamos un ejemplo sencillo:

function uppercase(target: Object, key: string | symbol) {
  let value: string | null = (target as any)[key];

  const setter = (val: string) => {
    value = val.toLocaleUpperCase();
  };
  const getter = () => {
    return value;
  };
  Object.defineProperty(target, key, {
    enumerable: true,
    configurable: true,
    set: setter,
    get: getter
  });
}

Este decorador tiene como función , convertir en mayúscula el valor de la propiedad a la cual es aplicado, pero se puede notar algo nuevo defineProperty, el cual es una función que nos permite definir la descripción de una propiedad, puedes leer más de esto aquí.

Veamos una pequeña explicación de las propiedades que utilice.

ennumerable: Permite que esta propiedad sea visible en la enumeración de las propiedades, Es decir si es false no aparecerá cuando se utilice con Object.keys o For .. in por ejemplo.

configurable:
Si es true , el descriptor de esta propiedad puede ser modificado.

get:
Esta función es llamada cuando se pida la propiedad.

set:

Es invocado al agregar el valor a la propiedad.

Ahora ya podemos utilizar el decorador.

@noise
@print
class Person {
  @uppercase
  name = 'leo';

  age = 10;
  constructor() {
    console.log(':o');
  }
}

const person = new Person();

// person.print();

console.log(person.name);

/*
output:
Hello friend I am instantiating
:o
i am already instantiated
LEO
*/

Ahora, ¿qué pasaría si quiero utilizar ese mismo decorador para poner en mayúscula solo la primera letra?, tendría que pasarle una opción que indique que quiero todo en mayúscula o solo la primera letra, para eso vamos a crear una función que nos retorne el decorador lo que sería un Decorator factory.

function uppercase({ first }: UppercaseOptions) : PropertyDecorator {
  return function (target: Object, key: string | symbol) {
    let value: string | null = (target as any)[key];

    const setter = (val: string) => {
      if (!!first) {
        const firstLetter = val[0].toLocaleUpperCase();
        value = firstLetter + val.substr(1, val.length);
      } else {
        value = val.toLocaleUpperCase();
      }
    };
    const getter = () => {
      return value;
    };
    Object.defineProperty(target, key, {
      enumerable: true,
      configurable: false,
      set: setter,
      get: getter
    });
  };
}

Ahora tenemos una función que retorna un decorador, incluso se ha tipado el retorno con PropertyDecorator, esto no es un tipo creado por mí, existe el tipado para cada unos de los decoradores dentro de TypeScript.

declare type ClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void;
declare type PropertyDecorator = (target: Object, propertyKey: string | symbol) => void;
declare type MethodDecorator = <T>(target: Object, propertyKey: string | symbol, descriptor: TypedPropertyDescriptor<T>) => TypedPropertyDescriptor<T> | void;
declare type ParameterDecorator = (target: Object, propertyKey: string | symbol, parameterIndex: number) => void;

Decorador de métodos

Del mismo manera que podemos interceptar clases y propiedades, también se puede interceptar los métodos, para que una función se convierta en un decorador de métodos, es casi lo mismo que el decorador de propiedades a diferencia que este recibe un parámetro más, descriptor, del cual ya sé menciono previamente.

Para ver un ejemplo vamos a agregar un método llamado food.

@noise
@print
class Person {
  @uppercase({ first: true })
  name = 'leo';

  age = 10;
  constructor() {
    console.log(':o');
  }

  eat(food: string) {
    console.log('I am eating ', food);
  }
}

Este recibe un parámetro el cual es el alimento, pero queremos validar que el usuario no pase como parámetro una bebida, vamos a crear un decorador para validar eso.

function foodGuard(): MethodDecorator {
  return function (target, key, descriptor) {
    const originalFn = descriptor.value as any;
    (descriptor.value as any) = function (this: any, ...args: any[]) {
      const value = args[0];
      if (value == 'water') {
        throw new Error('Water is a drink');
      }
      originalFn.apply(this, args);
    };
  };
}

El decorador foodGuard tiene como funcionalidad verificar que el parámetro no sea agua, si esto sucede arroja un error. En este caso no se ha utilizado get y set se ha establecido la propiedad value el cual es el valor de la propiedad en este caso, una función.

@noise
@print
class Person {
  @uppercase({ first: true })
  name = 'leo';

  age = 10;
  constructor() {
    console.log(':o');
  }

  @foodGuard()
  eat(food: string) {
    console.log('I am eating ', food);
  }
}

const person = new Person();


person.eat('water'); // lauch a error

console.log(person.name);

Hasta aquí una pequeña introducción a decoradores, para poder disfrutar más de ellos te invito a leer los siguientes artículos.

Patrón decorador (parte 1)

leobar37 — Sun, 24 Oct 2021 04:58:43 +0000

El patrón decorador es un patrón estructural que nos ayuda a poder agregar funcionalidades a una clase de manera dinámica.

Si quisiéramos compararlo con la vida real podría ser con una hamburguesería. Primero tendríamos el proceso general, el cual es tomar el pedido y entregarlo al cliente, el cliente pide una hamburguesa, una gaseosa y que de todas las cremas solo quiere mayonesa.

Como el proceso general sigue siendo el mismo, que es entregar el pedido todos estos procesos reciben el pedido como si fueran el "cliente", pero en realidad no lo son, solo van a agregar algo al pedido, por ejemplo, salió la hamburguesa, la de las gaseosas tomo el pedido y le puso una gaseosa ahora lo delega para que le pongan cremas, cada proceso que afecte al pedio la agregue cosas a este serán decoradores.

Sé que es un poco tonto el ejemplo. Pero fue lo único que se me ocurrió, llevemos esto a código.

type Order = string[];
interface Detail {
  creams: {
    mayonnaise: boolean;
    ketchup: boolean;
  };
  soda: boolean;
}

interface ICustomerService {
  receiveOrder(detail: Detail): void;
  deliverOder(): Order;
}

Este sería mi planteamiento inicial, Ahora implementemos esto en una clase.

class DeliverHamburguer implements ICustomerService {
  receiveOrder(detail: Detail): void {
    console.log('details');
    console.log(detail);
  }
  deliverOder(): Order {
    return ['A hamburguer'];
  }
}

Aquí es donde entra en juego el patrón decorador. ¿Por qué?. Bueno quizás en un ejemplo real, planteaste desde un inicio poder entregar gaseosas y cremas, pero aquí vamos a manejar las gaseosas y las cremas como funcionalidades por aparte suponiendo que recibir y entregar la hamburguesa es un montón de código y agregar la venta de gaseosas sería a aún más código.

Entonces ahora quieres poder agregar mayonesas a tu hamburguesa. Como solución aquí se podría plantear la herencia extendiendo la clase y agregar otra funcionalidad, pero después de un tiempo quieres vender gaseosas, esta sería otra funcionalidad, emplear herencia traería consigo ciertos problemas:

La herencia es estática: No podemos alterar las clases en tiempo de ejecución, si quitar o agregar una funcionalidad se tendría que hacer algún cambio en el código.
Solo se puede extender de una sola clase: En el caso de JavaScript solo podemos extender desde una sola clase. Si quisiéramos agregar funcionalidad se tendría que heredar clase tras clase.

Ahora volvamos código. El patrón decorador propone crear una clase a la cual llamaremos wrapper. Lo que hace es tomar el objeto y delega sus solicitudes, el sentido de esto es que en vez utilizar herencia, se haga otra clase con la funcionalidad y poder llegar utilizarla empleando agregaciòn o composiciòn por eso tenemos una referencia a dicho objeto la cual se pasa por parámetro.

Ahora para delegar las solicitudes y que este siga teniendo la misma estructura, implementamos la misma interfaz que en este caso sería ICustomerService.

class CustomerServiceBaseDecorator implements ICustomerService {
  wrappee: ICustomerService;
  constructor(obj: ICustomerService) {
    this.wrappee = obj;
  }
  receiveOrder(detail: Detail): void {
    this.wrappee.receiveOrder(detail);
  }
  deliverOder(): Order {
    return this.wrappee.deliverOder();
  }
}

Como se puede observar wrappe es cualquier objeto que implemente la interfaz ICustomerService.

class CreamsDecorator extends CustomerServiceBaseDecorator {
  detail: Detail;
  deliverOder() {
    const order = super.deliverOder();
    if (this.detail.creams.ketchup) {
      order.push('Add ketchup');
    }
    if (this.detail.creams.mayonnaise) {
      order.push('Add mayonnaise');
    }
    return order;
  }
  receiveOrder(details: Detail) {
    this.detail = details;
    super.receiveOrder(details);
  }
}

Todos los objetos que extiendan al wrapper son decoradores, en este caso este es un decorador encargado de manejar las cremas, veamos un poco a detalle esto.

EL método deliverOrder ejecuta primero el método del objeto objetivo, manipula la orden y la retorna.
En el método receiveOrder primero guarda el detalle de la orden, después ejecuta el método del objeto objetivo. Recuerda que estás llamando el método de la clase padre puedes probar
poniendo this y ocasionar una recursión infinita.

Esta es la razón de existir de decorador, puedes manipular las solicitudes antes y después y con base en esto agregar más funcionalidades. Ahora implementemos las sodas.

class SodasDecorator extends CustomerServiceBaseDecorator {
  detail: Detail;
  deliverOder() {
    const order = super.deliverOder();
    if (this.detail.soda) {
      order.push('Add Soda');
    }
    return order;
  }
  receiveOrder(details: Detail) {
    this.detail = details;
    super.receiveOrder(details);
  }
}

Listo ahora veamos como funcionaria esto

let detail: Detail = {
  creams: {
    ketchup: true,
    mayonnaise: true
  },
  soda: true
};

const services = {
  sodas: true,
  creams: true
};

let obj = new DeliverHamburguer();

if (services.creams) {
  const creamsDecorator = new CreamsDecorator(obj);
  obj = creamsDecorator;
}

if (services.sodas) {
  const sodasDecorator = new SodasDecorator(obj);
  obj = sodasDecorator;
}

obj.receiveOrder(detail);

console.log(obj.deliverOder());
// OUTPUT: [ 'A hamburguer', 'Add ketchup', 'Add mayonnaise', 'Add Soda' ]

Bien, ahora supongamos que por A/B razón ya no se puede ofrecer gaseosas, ya te puedes imaginar lo fácil que es quitar esa funcionalidad.

Segundo ejemplo

Ahora veamos un segundo ejemplo. Supongamos que estamos haciendo una aplicación de mensajería y te toca programar la parte del envío.

interface Sender {
  send(data: string, receiver: number): void;
}

class SenderMessage implements Sender {
  send(data: string, receiver: number) {
    console.log('data send');
    console.log(data);
  }
}

Ahora apliquemos decorador para poder extender las funcionalidades de una clase a futuro.

class SenderMessageDecorator implements Sender {
  private wrapper: Sender;
  constructor(sender: Sender) {
    this.wrapper = sender;
  }
  send(data: string, receiver: number): void {
    this.wrapper.send(data, receiver);
  }
}

Listo, ahora se te pide realizar un backup de los mensajes.

class BackupMessages extends SenderMessageDecorator {
  backup = new Map<number, string>();
  getBackup() {
    return Array.from(this.backup.values()).join('\n');
  }
  send(data: string, receiver: number) {
    this.backup.set(receiver, data);
    super.send(data, receiver);
  }
}

Listo, ahora se nos ocurre que sería bueno implementar filtros de palabras, por si alguien se le ocurre decir groserías.

type Filter = (data: string) => boolean;
class DecoratorFilters extends SenderMessageDecorator {
  filters: Filter[] = [];
  setFilters(...filters: Filter[]) {
    this.filters = filters;
  }
  send(data: string, receiver: number) {
    const canbe = this.filters.every(filter => filter(data));
    if (!canbe) {
      console.error(
        data + ' is not permitted by the filters and will not be sent'
      );
      return;
    }
    super.send(data, receiver);
  }
}

Ahora no contentos con eso se nos ocurre agregar una estructura al mensaje de manera que sea receiver:message.

class NormalizeText extends SenderMessageDecorator {
  send(data: string, receiver: number) {
    const normalized = `${receiver}:${data}`;
    super.send(normalized, receiver);
  }
}

Aún no contentos con eso, se nos ocurre agregar eventos para notificar él antes y después del envío del mensaje.

class EventsDecorator extends SenderMessageDecorator {
  beforeSendObserver = new Subject<void>();
  afterSendObserver = new Subject<void>();
  onBeforeSend(callback: () => void) {
    this.beforeSendObserver.suscribe(callback);
  }
  onAfterSend(callback: () => void) {
    this.afterSendObserver.suscribe(callback);
  }
  send(data: string, receiver: number) {
    this.beforeSendObserver.next();
    super.send(data, receiver);
    setTimeout(() => {
      this.afterSendObserver.next();
    }, 1000);
  }
}

Por cierto la clase Subject viene del patrón observer del anterior post, código aquí y listo suficiente :).

Ahora probemos lo que hemos hecho.

let options = {
  backup: true,
  events: true,
  normalize: true,
  filters: true
};
let sender = new SenderMessage();

if (options.backup) {
  const backup = new BackupMessages(sender);
  sender = backup;
  setTimeout(() => {
    console.log('backup');
    console.log((backup as BackupMessages).getBackup());
  }, 1500);
}

if (options.events) {
  const events = new EventsDecorator(sender);
  sender = events;
  events.onBeforeSend(() => {
    console.log('after send');
  });
  events.onBeforeSend(() => {
    console.log('before send');
  });
}

if (options.normalize) {
  sender = new NormalizeText(sender);
}

if (options.filters) {
  const filters = new DecoratorFilters(sender);
  sender = filters;
  const barWords = (data: string) => {
    return data !== 'shit';
  };
  filters.setFilters(barWords);
}

sender.send('Hello', 1);
sender.send('Hello', 2);
sender.send('Hello', 3);
sender.send('Hello', 4);
sender.send('shit', 5);

La data ha sido normalizada, los eventos están funcionando, el backup se realiza y un aviso de que la alerta de que la última palabra no se envió por el filtro que se puso, si ahora se quisiera deshabilitar alguna funcionalidad, no hay ningún problema solo manipula options y listo.

Happy code :)
Codigo completo aquí

Patrón decorator

Patrón Observer (parte 2)

leobar37 — Wed, 20 Oct 2021 04:00:28 +0000

En la primera parte implementé el patrón Observer, pero ligado a una lógica especifica. En este artículo quiero plantearlo de dos maneras más pero sin ligarlos a una lógica de negocio e incluyendo un poco de programación funcional.

Ejemplo 1:

Primero vamos a implementar el patrón de Observer de una manera que nos permita hacer una emisión de cualquier dato y poder suscribirnos a él.

type Unsuscribe = () => void;

type Listener<T> = (value: T) => void;

export interface ISubject<T> {
  suscribe(listener: Listener<T>): Unsuscribe;
}

Este sería el planteamiento, vamos tenemos un Unsuscribe el cual va a ser una función que me permite dejar de escuchar los cambios del sujeto y el Listener el cual es la función que vamos a llamar para notificar los cambios y finalmente ISubject .

export class Subject<T> implements ISubject<T> {

 listeners = new Set<Listener<T>>();

     next(value: T): void {
    this.listeners.forEach(listener => listener(value));
  }
  suscribe(listener: Listener<T>): Unsuscribe {
    this.listeners.add(listener);
    return () => this.listeners.delete(listener);
  }
}

Esta sería la implementación del patrón completa, esta clase tiene como finalidad emitir a todos los oyentes los valores que se vayan emitiendo, como un flujo de datos. Veámoslo en acción.

const obs = new Subject<string>();

obs.next('hello');

obs.suscribe(d => {
  console.log('suscriber 1');
  console.log(d);
});

obs.next('World');

obs.suscribe(d => {
  console.log('suscriber 2');
  console.log(d);
});

obs.next('bye');

Output:

Para explicarlo un poco mejor lo voy a poner gráficamente:

La palabra hello no fue mostrada porque al momento que se emitió ese dato no había ningún listener escuchando, cuando se emitió world solo había uno y cuando apareció bye habían dos.

Ejemplo 2:

Cuando tratamos con el dom a menudo vemos codigo así:

document.addEventListener('click', () => {
  console.log('Hi, you click me :)');
});

Lo que indica que cuando el evento click ocurra esa función va a ser accionada. Y eso puede ocurrir en distintos lugares(puedes escuchar el evento click muchas veces). Ahora vamos a emplear el patrón observer de una manera diferente, ahora ya no tendremos un solo conjunto de Listeners. En ****lugar de eso vamos a tener un conjunto por cada evento.

type Listener<T> = (value: T) => void;
type Listeners<T> = Array<Listener<T>>;
interface IEventEmmiter<T> {
  on(event: string, listener: Listener<T>): void;
  once(event: string, listener: Listener<T>): void;
  removeEventListeners(): void;
  emit(event: string, payload: T): void;
}

Está seria la estructura, los métodos dentro de IEventEmmiter tienen que cumplir con lo siguiente.

on:

Me permite suscribirme a un evento específico.

once:

Me permite suscribirme a un evento específico pero solo una vez.

removeEventListeners:

Remueve todos los oyentes,

emit:

Emite datos según el evento.

Veamos como implementamos esto 😌.

lo primero que voy hacer plantear el almacenamiento de los Oyentes, para eso voy a usar Map.

class EventEmmiter<T> implements IEventEmmiter<T> {
  private listenersManager = new Map<string, Listeners<T>>();

  constructor() {}

  emit(event: string, payload: T): void {}
  on(event: string, listener: Listener<T>): void {}
  once(event: string, listener: Listener<T>): void {}
  removeEventListeners(): void {}
}

Una vez planteado esto podemos empezar a agregar código a los métodos.

Empecemos con on:

class EventEmmiter<T> implements IEventEmmiter<T> {
  private listenersManager = new Map<string, Listeners<T>>();

  constructor() {}
  emit(event: string, payload: T): void {}
  private getListeners(event: string) {
    return this.listenersManager.get(event) || [];
  }
  on(event: string, listener: Listener<T>): void {
    const listeners = this.getListeners(event);
    listeners.push(listener);
    this.listenersManager.set(event, listeners);
  }
  once(event: string, listener: Listener<T>): void {}
  removeEventListeners(): void {}
}

Lo único que vamos a hacer en on es agregar es agregar el listener al evento que le corresponda.

Ahora veamos once:

class EventEmmiter<T> implements IEventEmmiter<T> {
  private listenersManager = new Map<string, Listeners<T>>();
  private onlyOnce = new Set<Listener<T>>();
  constructor() {}
  emit(event: string, payload: T): void {}
  private getListeners(event: string) {
    return this.listenersManager.get(event) || [];
  }
  on(event: string, listener: Listener<T>): void {
    const listeners = this.getListeners(event);
    listeners.push(listener);
    this.listenersManager.set(event, listeners);
  }
  once(event: string, listener: Listener<T>): void {
    this.onlyOnce.add(listener);
    this.on(event, listener);
  }

  removeEventListeners(): void {}
}

Para once he creado un segundo almacenamiento donde guardaré este tipo de listeners. Quizá una forma mucho mejor de hacerlo sea envolver a al listener dentro de un objeto para no tener dos listas, pero para no complicar las cosas lo voy a dejar así.

class EventEmmiter<T> implements IEventEmmiter<T> {
  private listenersManager = new Map<string, Listeners<T>>();
  private onlyOnce = new Set<Listener<T>>();
  constructor() {}
  emit(event: string, payload: T): void {
    this.getListeners(event).forEach(listener => {
      if (this.onlyOnce.has(listener)) {
        this.onlyOnce.delete(listener);
        this.removeListener(event, listener);
      }
      listener(payload);
    });
  }
  private removeListener(event: string, listener: Listener<T>) {
    const newListeners = this.getListeners(event).filter(d => d !== listener);
    this.listenersManager.set(event, newListeners);
  }
  private getListeners(event: string) {
    return this.listenersManager.get(event) || [];
  }
  // rest of code ..

  removeEventListeners(): void {}
}

Bien a la hora de emitir el evento es donde es útil la segunda lista , si el listener se encuentra dentro dentro de onlyOnce este se tiene que eliminar.

Ahora solo faltaría el ultimo método removeListeners.

class EventEmmiter<T> implements IEventEmmiter<T> {
  private listenersManager = new Map<string, Listeners<T>>();
  private onlyOnce = new Set<Listener<T>>();
  constructor() {}
  private getListeners(event: string) {
    return this.listenersManager.get(event) || [];
  }
  private removeListener(event: string, listener: Listener<T>) {
    const newListeners = this.getListeners(event).filter(d => d !== listener);
    this.listenersManager.set(event, newListeners);
  }
  emit(event: string, payload: T): void {
    this.getListeners(event).forEach(listener => {
      if (this.onlyOnce.has(listener)) {
        this.onlyOnce.delete(listener);
        this.removeListener(event, listener);
      }
      listener(payload);
    });
  }
  on(event: string, listener: Listener<T>): void {
    const listeners = this.getListeners(event);
    listeners.push(listener);
    this.listenersManager.set(event, listeners);
  }
  once(event: string, listener: Listener<T>): void {
    this.onlyOnce.add(listener);
    this.on(event, listener);
  }
  removeEventListeners(): void {
    this.onlyOnce = new Set();
    this.listenersManager = new Map();
  }
}

Listo una clase hermosa para manejar eventos, ahora en acción.

const emmiter = new EventEmmiter<string>();

emmiter.on('hello', name => {
  console.log('sub 1');
  console.log('Hello ' + name);
});

emmiter.once('hello', name => {
  console.log('sub  4 (once)');
  console.log('Hello ' + name);
});
let cont = 0;
setInterval(() => {
  emmiter.emit('hello', 'Leobar' + cont);
  if (cont == 5) {
    emmiter.removeEventListeners();
  }
  cont++;
}, 1000);

output :

Bueno ha pasado la prueba 😌.

Bien puedo decir que fue suficiente como para entender la utilidad de este patrón por cierto los dos ejemplos estan inspirado la libreria rxjs y EventEmiter de node js respectivamente.

codigo completo

Patrón Observer (parte 1)

leobar37 — Mon, 18 Oct 2021 04:05:32 +0000

Patrón observer uno de los patrones que hace que parezcas un mago con el código, seria como:

Mira voy a ingresar un dato aquí y va a aparecer algo allá 😌

pero bueno, si haz escuchado sobre rxjs y programación reactiva Pero bueno, si has escuchado sobre rxjs y programación reactiva supongo que ya sabes un poco sobre esto, pero si has utilizado la librería sin conocer el patrón, ven y peleamos, vale no 😁, de hecho yo también lo hice y pues tan mal no me fue. Aun así creo que aprender el patrón he implementarlo por ti mismo hace que todo sea un poco más fácil y abre más posibilidades.

Por cierto todo lo siguiente, implementación y explicación es mi manera de aprenderlo es más te aconsejo leer primero este maravilloso artículo.

¿Que es el patrón observer?

Es un patrón de comportamiento que define un mecanismo de suscripción para notificar a una serie de objetos sobre cualquier cambio que le suceda al objeto que están observando.

Lo primero que se nos puede venir a la mente aquí, puede ser YouTube y las subscripciones, las notificaciones de tu red social favorita, etc. Con estos ejemplos podemos analizar el hecho de que el patrón observer le da la posibilidad de elegir que tipo de notificaciones recibir al sujeto, por ejemplo en YouTube cada vez que me suscribo a un canal voy a estar recibiendo notificaciones de cuando subió un vídeo este canal en particular.

Implementación:

Bien juguemos un poco con la lógica de suscripcion en YouTube.

EL patrón Observer consta de un notificador que a la vez es el sujeto el cual contiene el estado que es notificado a las respectivas suscripciones. En este caso nuestro sujeto será YouTube.

class Youtube {
  constructor() {}

   // notifies you when a video has been uploaded
    notify(notify: any): void {}

  // register a suscription 
  suscribe(sub: any): void {} 
  unsuscribe(sub: any): void {}
}

Aquí tenemos a nuestro Sujeto con los métodos necesarios para manejar las suscripciones, pero estos reciben parámetros tipo any. Arreglemos eso:

interface Subscriber<T> {
  update(event: T): void;
}

export type Notification = {
  nameVideo: string;
  channel: string;
  date?: Date;
};
// suscription parameters
type SubscriptionInfo = {
  id: string;
  channel: string;
};

La parte interesante aquí es Subscriber que es la interfaz que nos va a ayudar a definir el método que se llama cuando ocurre un evento en este caso cuando se sube un video al canal.

Ahora implementemos esa suscripción.

class YoutubeSubscription implements Subscriber<Notification> {
  private sub: SubscriptionInfo;

  constructor(sub: SubscriptionInfo) {
    this.sub = sub;
  }
  getSub() {
    return this.sub;
  }
    // this method is called when the subject wants to notify and event
  update(event: Notification): void {
    console.log(
      ` (${event.date.toISOString()}) ${event.channel} uploaded a new video : ${
        event.nameVideo
      }`
    );
  }
}

Ahora ya tenemos la suscripción y el cuerpo del evento en este caso es Notification y la implementación del método update.

Ahora veamos el cambio en la clase Youtube

class Youtube {
  constructor() {}

  notify(notify: Notification): void {}

  suscribe(sub: YoutubeSubscription): void {}
  unsuscribe(sub: YoutubeSubscription): void {

  }
}

Listo ahora ya no tenemos any y tenemos implementado nuestro sujeto el cual ahora llamaremos Observable.

Anteriormente creamos un método createDatabase que fabricaba un objeto Database con algunos métodos útiles para manejar nuestros datos puedes ver el código aquí. Entonces, vamos a usar este método para los canales.

interface Chanel extends BaseRecord {
  name: string;
}

class Youtube {
  channels = createDatabase<Chanel>({
    typeId: 'incremental'
  });

  constructor() {
    this.channels.insert({
      name: 'leobar'
    });
    this.channels.insert({
      name: 'nose'
    });
  }

  notify(notify: Notification): void {}

  suscribe(sub: YoutubeSubscription): void {}
  unsuscribe(sub: YoutubeSubscription): void {}
}

Ahora tenemos los canales los cuales deberían de tener un conjunto de suscripciones, voy a manejar esa lógica por aparte manteniendo en memoria las suscripciones activas con un identificador, en este caso el nombre del canal.

class Youtube {
  suscriptions: Map<string, YoutubeSubscription[]> = new Map();

  channels = createDatabase<Chanel>({
    typeId: 'incremental'
  });

  constructor() {
    this.channels.insert({
      name: 'leobar'
    });
    this.channels.insert({
      name: 'nose'
    });
  }

  notify(notify: Notification): void {}

  suscribe(sub: YoutubeSubscription): void {}
  unsuscribe(sub: YoutubeSubscription): void {}
}

En este caso estoy manejando las suscripciones con la estructura Map . Ahora agreguemos lógica a los métodos.

class Youtube {
  // .. code
  notify(notify: Notification): void {
    this.suscriptions.get(notify.channel).forEach(d => d.update(notify));
  }
  get getChannels() {
    return this.channels.findAll({});
  }
  suscribe(sub: YoutubeSubscription): void {
    // if channel does not exist throw an exception
    if (this.channels.findAll({ name: sub.getSub().channel }).length == 0) {
      throw new Error('This channel does not exist');
    }
    let subs: YoutubeSubscription[] = [];
    if (this.suscriptions.has(sub.getSub().channel)) {
      subs = this.suscriptions.get(sub.getSub().channel);
    }
    subs.push(sub);
    this.suscriptions.set(sub.getSub().channel, subs);
  }
  unsuscribe(sub: YoutubeSubscription): void {
    let channelSubs = this.suscriptions.get(sub.getSub().channel);
    if (channelSubs) {
      channelSubs = channelSubs.filter(sub => sub !== sub);
      this.suscriptions.set(sub.getSub().channel, channelSubs);
      console.log(`${sub.getSub().id} Unsuscribed`);
      console.log('Suscribers :' + channelSubs.length);
      console.log(channelSubs);
    }
  }
}

Listo. Ahora tenemos implementando el patrón. Youtube es nuestro Observable y YoutubeSubscription lo vamos a llamar observer.Ahora nos damos cuenta que estamos tratando con una relación de uno a muchos

Ahora vamos a probar lo que hemos hecho:

const youtube = new Youtube();

const leobarSub = new YoutubeSubscription({
  channel: 'leobar',
  id: '1'
});

const noseSubscription = new YoutubeSubscription({
  channel: 'nose',
  id: '2'
});

youtube.suscribe(leobarSub);

youtube.suscribe(noseSubscription);

let cont = 0;

const channels = youtube.getChannels.map(d => d.name);

setInterval(() => {
  const ramdom = Math.floor(Math.random() * channels.length);
  youtube.notify({
    channel: channels[ramdom],
    nameVideo: 'video nro:' + cont,
    date: new Date()
  });
  if (cont === 5) {
    youtube.unsuscribe(leobarSub);
  }
  if (cont == 8) {
    youtube.unsuscribe(noseSubscription);
  }
  cont++;
}, 2000);

Lo que hecho es instancia nuestro Observable, agregarle dos suscripciones y cada cierto tiempo notificar aleatoriamente la que se subió un video.

Hasta aquí hemos logrado implementar el patrón Observable de una manera que veamos cuál es su sentido de existir y su utilidad. Dejaré esta parte hasta aquí, En segunda parte quiero hacer una implementación más generalizada y ver como este patrón nos abre las puertas hacia la programación reactiva 😌.

Código completo aquí:

Links

Si todavía tienes dudas sobre como funciona este patrón puedes consultar los siguientes links:

Patrón factory en typescript

leobar37 — Sat, 16 Oct 2021 03:59:03 +0000

Continuando con esta serie de stories sobre patrones de diseño, el siguiente es Factory. Este es un patrón creacional y ofrece una de las mejores formas de crear un objeto.

Como su nombre lo dice es una fábrica y su función es fabricar algo en este caso un objeto, pero va más allá de eso. Según mi análisis, el patrón factory serviría cuando tenemos que crear algo y tenemos diferentes maneras de crear ese algo. Y además hay una lógica de por medio para su creación, Veamos un ejemplo;

Imagina que estás creando un bot para Facebook lo más básico seria tener lo siguiente.

class Message {
  send() {
    // send message logic
  }
}

Hasta ahí todo fácil, su aplicación funciona, todo va de maravilla, pero después de un tiempo se da cuenta de que no solo se puede enviar texto, sino también botones, galerías y más.

Poner más y más lógica a la clase sería complicado. Así que decide crear una clase para cada tipo de mensaje

class TextMessage {}

class ImageMessage {}

class ButtonMessage {}

class GaleryMessage {}

Ahora detecta que todos estos tipos tienen algo en común. Estos se tienen que enviar el mensaje y de la misma manera quizás, así que decide abstraer toda esa lógica de los mensajes y heredarla.

abstract class Message {
  id: string;
  send(): void {}
}

class TextMessage extends Message {
  id = 'Text';
}

class ImageMessage extends Message {
  id = 'Image';
}

class ButtonMessage extends Message {
  id = 'Button';
}

class GaleryMessage extends Message {
  id = 'Galery';
}

A mi parecer luce bien, pero ahora el problema es que complicamos un poco el código.

Bien seamos un poco amables con él, así que le vamos a brindar una manera fácil de crear su mensaje.

function createMessage(type: TypeMessage) {
  switch (type) {
    case TypeMessage.TEXT:
      return new TextMessage();
    case TypeMessage.BUTTON:
      return new ButtonMessage();
    case TypeMessage.IMAGE:
      return new ImageMessage();
    case TypeMessage.GALERY:
      return new GaleryMessage();
  }
}

const btnMessage = createMessage(TypeMessage.BUTTON);
btnMessage.send();
const textMessage = createMessage(TypeMessage.TEXT);
textMessage.send();

El método createMessage sería nuestra fábrica y el producto que nos entrega es un Message esto es muy importante porque la fabrica no distingue si estamos trabajando con ButtonMessage o TextMessage porque los trata por su clase abstracta en este caso Message.
Ahora regresemos al ejercicio del primer patrón y agreguemos factory que por cierto era este:

import { assertProps, PartialAssert } from './utils';
interface BaseRecord {
  id: string;
}
interface IDatabase<T extends BaseRecord> {
  find(id: string): T;
  findAll(properties: PartialAssert<T>): T[];
  insert(node: T): void;
  delete(id: string): T;
}

interface Todo extends BaseRecord {
  title: string;
  done: boolean;
  priority: number;
}

class TodosDatabase implements IDatabase<Todo> {
  nodes: Record<string, Todo> = {};
  // aqui podemos guardar la instancia
  private static _instance: TodosDatabase = null;

  // este método se encarga de exponer la instancia hacía el exterior
  public static get instance(): TodosDatabase {
    // si la instancia no existe es por que todavìa no ha sido creado
    if (TodosDatabase._instance == null) {
      TodosDatabase._instance = new TodosDatabase();
    }
    return TodosDatabase._instance;
  }
  private constructor() {}
  find(id: string): Todo {
    return this.nodes[id];
  }
  findAll(properties: PartialAssert<Todo>): Todo[] {
    const find = assertProps(Object.values(this.nodes));
    return find(properties);
  }
  insert(node: Todo): void {
    this.nodes[node.id] = node;
  }
  delete(id: string): Todo {
    const deleted = this.nodes[id];
    delete this.nodes[id];
    return deleted;
  }
}

const todoDatabase = TodosDatabase.instance;

TodosDatabase.instance.insert({
  done: false,
  id: '1',
  priority: 2,
  title: 'Sleep early'
});

TodosDatabase.instance.insert({
  done: true,
  id: '2',
  priority: 2,
  title: 'do the laudry'
});

const todosCheked = TodosDatabase.instance.findAll({
  title: (title: string) => {
    return title.indexOf('do') != -1;
  },
  done: true
});

Bien esto funciona perfecto, pero ahora viene un gran hombre y nos dice que desea un CRUD de productos 😒.

La solución más rápida de pensar, pero difícil y aburridamente de implementar sería volver a hacer el mismo procedimiento con producto, pero ya que hemos visto factory es hora de usarlo,

Lo primero que voy hacer es crear un función que me cree una clase Database.

function createDatabase<T extends BaseRecord>() {
  class Database implements IDatabase<T> {
    nodes: Record<string, T> = {};
    private static _instance: Database = null;
    public static get instance(): Database {
      if (Database._instance == null) {
        Database._instance = new Database();
      }
      return Database._instance;
    }
    private constructor() {}

    find(id: string): T {
      return this.nodes[id];
    }
    findAll(properties: PartialAssert<T>): T[] {
      const find = assertProps(Object.values(this.nodes));
      return find(properties);
    }

    insert(node: T): void {
      this.nodes[node.id] = node;

    }
    delete(id: string): T {
      const deleted = this.nodes[id];
      delete this.nodes[id];
      return deleted;
    }
  }
  return Database;
}

Esto es casi igual solo que ahora el genérico parte desde la función hacia la clase y por consecuencia podemos hacer lo siguiente.

const TodosDatabase = createDatabase<Todo>();
const ProductDatabase = createDatabase<Product>();

Bellísimo, ahora ya tenemos dos Database una para productos y otra para las tareas por hacer.

TodosDatabase.instance.insert({
  done: false,
  priority: 2,
  title: 'Sleep early'
});

TodosDatabase.instance.insert({
  done: true,
  priority: 2,
  title: 'do the laudry'
});

ProductDatabase.instance.insert({
  name: 'Product 1',
  price: 5
});

TodosDatabase.instance.findAll({
  done: false
});

Y con todo el poder de typescript incluido, después de un tiempo otra vez vuelve nuestro amigo y nos dice que funciona perfecto, pero no siempre puede ingresar el id y que requiere que este sea automático, si hubieras aplicado factory tendrías que tocar dos clases, pero como no lo hiciste 😌.

interface IConfig {
  typeId: 'uuid' | 'manual' | 'incremental';
}
function createDatabase<T extends BaseRecord>({ typeId }: IConfig) {
  class Database implements IDatabase<T> {
    nodes: Record<string, T> = {};

    private static _instance: Database = null;
    private _lastInserted: T;
   // ...extra logic
    private generateId() {
      switch (typeId) {
        case 'incremental': {
          if (!this._lastInserted) {
            return 0;
          } else {
            const id = this._lastInserted.id as number;
            return id + 1;
          }
        }
        case 'uuid': {
          return nanoid();
        }
        case 'manual': {
          return null;
        }
      }
    }

    insert(node: T): void {
      const id = this.generateId();
      if (id !== null) {
        node = {
          ...node,
          id
        };
      }

      this.nodes[node.id] = node;
      this._lastInserted = node;
    }
    // ...extra logic
  }
  return Database;
}

Agregamos un parámetro para las configuraciones, por si a nuestro amigo se le ocurre pedir más cosas. Ahora hacemos magia, tenemos tres forma de producir un id:

Manual : EL usuario ingresa el id.
Incremental : Un número que aumenta de uno en uno.
Uuid : Una identificador único generado por el paquete nanoid.

Toda esa lógica lo maneja el método generateId por cierto hubo un cambio en la siguiente interfaz.

interface BaseRecord {
  id?: string | number;
}

Ahora es opcional y nuestro, id puede ser número o una cadena. La propiedad _lastInserted cumple el rol de ir guardando el último elemento insertado porque me parece mucho más barato que recorrer todos los datos buscando el mayor o el último insertado.

Puedes ver el código completo aquí