Forem: Khriztian Moreno

Tech Stack 2025

Khriztian Moreno — Fri, 03 Jan 2025 21:57:30 +0000

El ecosistema React es un paisaje dinámico de tecnologías en constante evolución. Este artículo profundiza en un potente stack tecnológico para construir aplicaciones full-stack en 2025, permitiéndote dar vida a tu propio producto (como un SaaS) o a su Producto Mínimo Viable (MVP).

Como desarrollador web Fullstack experimentado, he pasado años perfeccionando mi enfoque. Las reevaluaciones anuales de los stack tecnológicos son cruciales para equilibrar las tendencias de vanguardia con la estabilidad y la mantenibilidad de los proyectos a largo plazo.

Mi última experiencia laboral, que culminó en noviembre de 2024, me ha proporcionado valiosos comentarios. Aunque estoy satisfecho con el stack tecnológico inicial, la retrospectiva ofrece valiosas lecciones para futuros proyectos.

Embarquémonos en este viaje de descubrimiento y exploremos las apasionantes posibilidades que aguardan en esta concisa pero potente selección.

React como framework full-stack

Remix.js

Remix.js es un framework web full-stack que prioriza la experiencia del desarrollador y aprovecha los fundamentos web para crear aplicaciones web rápidas, resilientes y amigables para el usuario.

Características Clave:

Carga y Obtención de Datos: Remix simplifica la obtención de datos con cargadores y acciones integradas. Los loaders obtienen datos antes de renderizar una ruta, mientras que las acciones manejan envíos de formularios y otros efectos secundarios.
Enrutamiento Basado en el Sistema de Archivos: Las rutas se definen como archivos dentro del sistema de archivos de tu proyecto, haciendo que la estructura de enrutamiento sea intuitiva y fácil de entender.
Renderizado del Lado del Servidor (SSR): Remix sobresale en SSR, proporcionando un excelente SEO y tiempos de carga iniciales más rápidos.
Transmisión de Datos: Remix puede transmitir datos al cliente, mejorando el rendimiento percibido y la experiencia del usuario.
Manejo de Formularios: El manejo de formularios integrado simplifica tareas comunes como la validación, el envío y el manejo de errores.
Pruebas: Remix fomenta las pruebas a varios niveles, incluyendo pruebas unitarias, de integración y de extremo a extremo.
Flexibilidad: Remix se puede desplegar en varios entornos, incluyendo servidores Node.js y plataformas de computación en el borde como Cloudflare Workers.

Beneficios de Usar Remix:

Mejor Rendimiento: SSR y la transmisión de datos contribuyen a tiempos de carga más rápidos y una experiencia de usuario más fluida.
Mejor Experiencia del Desarrollador: El enfoque de Remix en la experiencia del desarrollador lo hace agradable de usar, gracias a su enrutamiento intuitivo, mecanismos de obtención de datos y características integradas.
Flexibilidad y Escalabilidad: Remix se puede desplegar en varios entornos, haciéndolo adaptable a diferentes necesidades de proyectos.
Comunidad y Ecosistema Sólidos: Remix tiene una comunidad en crecimiento y un ecosistema de apoyo con varios recursos y herramientas disponibles.

En esencia, Remix.js ofrece un enfoque moderno y eficiente para el desarrollo web, empoderando a los desarrolladores para construir aplicaciones de alta calidad, de alto rendimiento y centradas en el usuario.

Astro

¿Considerando una landing page dedicada? ¡Astro brilla para esta tarea!

Mientras que Remix.js sobresale en aplicaciones monolíticas que sirven tanto contenido estático como dinámico, Astro ofrece una alternativa convincente específicamente para crear landing pages excepcionales. Aquí está el porqué Astro podría ser la elección perfecta:

Características Clave:

Rendimiento Ultra-Rápido: Astro prioriza la velocidad, entregando landing pages rapidísimas que mantienen a los visitantes comprometidos.
Enrutamiento Intuitivo Basado en Archivos: Similar a Remix, Astro aprovecha un sistema de enrutamiento basado en archivos, haciendo que sea fácil estructurar y gestionar el contenido de tu landing page.
Desarrollo Basado en Componentes: Construye componentes reutilizables para un proceso de desarrollo optimizado y un diseño consistente en toda tu landing page.
Integración con Múltiples Frameworks: Astro se integra sin problemas con frameworks populares como React, Vue y Svelte, permitiéndote aprovechar tus habilidades y preferencias existentes.
Soporte para Sistemas de Gestión de Contenidos (CMS) Headless: Astro se lleva bien con varias soluciones CMS headless, permitiendo una gestión flexible del contenido de tu landing page.

Beneficios de Usar Astro para Páginas de Aterrizaje

Enfoque en la Experiencia del Desarrollador: La sintaxis limpia de Astro y su estructura basada en archivos simplifican el desarrollo, permitiéndote concentrarte en crear una landing page impactante.
Prototipado Rápido: La velocidad de Astro lo hace ideal para el prototipado rápido y la iteración en el diseño de tu landing page.
Optimización SEO: Astro genera HTML limpio y bien estructurado, contribuyendo a una fuerte Optimización para Motores de Búsqueda (SEO) para tu landing page.
Tiempos de Construcción Reducidos: Las construcciones incrementales de Astro minimizan los tiempos de construcción, permitiendo ciclos de desarrollo más rápidos.

Al aprovechar las fortalezas de Astro, puedes crear una landing page de alto rendimiento y amigable para el desarrollador que capture leads y alimente el crecimiento de tu SaaS, todo mientras ahorras tiempo valioso para enfocarte en el desarrollo del producto principal dentro de tu aplicación Remix/Next.

Server Components

Imagina que estás construyendo una casa. Los Componentes del Servidor son como los trabajadores de construcción que manejan las tareas pesadas y especializadas. En lugar de hacer todo dentro de tu casa (el navegador), estos componentes trabajan afuera, en el servidor.

¿Qué hacen?

Obtener materiales: Recuperan datos de una base de datos o API, como ir a buscar ladrillos para construir una pared.
Hacer cálculos complejos: Realizan operaciones matemáticas o lógicas complicadas, como calcular el área de una habitación.
Proteger tu casa: Manejan tareas de seguridad, como verificar si alguien tiene permiso para entrar.

¿Por qué son útiles?

Tu casa se construye más rápido: Al hacer parte del trabajo en el servidor, tu sitio web carga más rápido para los visitantes.
T*u casa es más segura:* Los datos sensibles se manejan en un lugar más seguro, fuera del alcance de los intrusos.
Puedes enfocarte en la decoración: Los componentes del servidor manejan el trabajo pesado, para que puedas enfocarte en hacer que tu sitio web se vea bien y funcione bien.

Server Functions

Piensa en tu casa teniendo un sistema de intercomunicación. Las Funciones del Servidor son como usar ese intercomunicador para pedirle a un trabajador afuera de la casa que haga algo.

¿Cómo funcionan?

Tú (tu componente React) le dices al trabajador (la función del servidor) qué hacer, como "por favor trae más ladrillos".
El trabajador hace la tarea y te da el resultado.

¿Por qué son útiles?

Es muy fácil comunicarse: No tienes que preocuparte por los detalles técnicos de enviar y recibir mensajes.
Puedes hacer muchas cosas: Puedes pedirle a la función del servidor que haga casi cualquier cosa que un componente del servidor pueda hacer.

Server Actions

Imagina que tienes una lista de comandos predefinidos para tu intercomunicador. Las Acciones del Servidor son como esos comandos.

¿Qué son?

Son funciones del servidor diseñadas para realizar tareas específicas, como enviar un formulario o actualizar una base de datos.

¿Por qué son útiles?

Son fáciles de usar: Ya están configuradas para hacer algo específico, por lo que no tienes que escribir mucho código.
Hay muchas bibliotecas que te ayudan: Hay bibliotecas como next-safe-actions y zsa que te proporcionan acciones del servidor predefinidas para tareas comunes.

Gestión de Estado en React

Zustand

Zustand es una biblioteca de gestión de estado ligera y flexible para aplicaciones React. Ofrece una API simple e intuitiva para gestionar el estado global y local, lo que la convierte en una excelente opción para proyectos de todos los tamaños.

Características Clave:

API Minimalista: Zustand cuenta con una API concisa y fácil de aprender con un código boilerplate mínimo.
Orientado al Rendimiento: Zustand está diseñado para un rendimiento óptimo, con actualizaciones de estado eficientes y una sobrecarga mínima.
Flexible: Ofrece un enfoque flexible y modular para la gestión de estado, permitiéndote crear y gestionar múltiples stores según sea necesario.
Fácil de Aprender: La API simple y la documentación clara hacen que Zustand sea fácil de aprender e integrar en tus proyectos React.

import create from "zustand";

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

function Counter() {
  const count = useStore((state) => state.count);
  const increment = useStore((state) => state.increment);

  return <button onClick={increment}>Count: {count}</button>;
}

Recoil

Recoil.js es una biblioteca de gestión de estado para aplicaciones React que proporciona un enfoque más granular y flexible para gestionar el estado compartido en comparación con métodos tradicionales como Context API. Ofrece un gráfico de flujo de datos único que te permite crear estructuras de estado complejas y derivar nuevo estado a partir de los existentes.

Conceptos Clave:

Átomos: Son las unidades fundamentales de estado en Recoil. Los átomos son independientes y pueden ser suscritos por múltiples componentes. Proporcionan una forma de almacenar y compartir valores simples.
Selectores: Los selectores son funciones puras que derivan nuevo estado a partir de átomos existentes u otros selectores. Permiten crear estructuras de estado complejas y realizar cálculos sobre la marcha.
RecoilRoot: Este componente es la raíz de tu aplicación Recoil. Proporciona el contexto para todos los átomos y selectores de Recoil.
Suscripciones: Los componentes se suscriben a átomos o selectores para recibir actualizaciones cuando el estado cambia. Recoil utiliza mecanismos eficientes para asegurar que los componentes solo se vuelvan a renderizar cuando los datos de los que dependen realmente han cambiado.

Características Avanzadas:

Valores Asíncronos: Recoil soporta valores asíncronos, permitiéndote obtener datos de APIs y gestionar estados de carga.
Persistencia: Puedes persistir el estado de Recoil en el almacenamiento local u otros mecanismos de almacenamiento para restaurarlo en cargas de página posteriores.
Depuración con Viaje en el Tiempo: Recoil proporciona herramientas para la depuración con viaje en el tiempo, permitiéndote inspeccionar y retroceder cambios de estado.
Hooks Personalizados: Puedes crear hooks personalizados para encapsular lógica compleja de gestión de estado.

import { atom, selector, useRecoilState, useRecoilValue } from "recoil";

// Atom for user data (fetched asynchronously)
const userDataAtom = atom({
  key: "userData",
  default: null,
  effects_UNSTABLE: [
    ({ setSelf }) => {
      // Fetch user data from API and set it
    },
  ],
});

// Selector to extract the user's name
const userNameSelector = selector({
  key: "userName",
  get: ({ get }) => {
    const userData = get(userDataAtom);
    return userData?.name || "Guest";
  },
});

function UserProfile() {
  const userName = useRecoilValue(userNameSelector);

  return <div>Hello, {userName}!</div>;
}

Estilos CSS en React

Tailwind CSS

Revolucionario para el Desarrollo Rápido

Aunque las opiniones sobre Tailwind CSS varían dentro de la comunidad de desarrolladores, creo firmemente que actualmente es la solución más efectiva para el desarrollo rápido de productos y el mantenimiento a largo plazo de CSS.

Basado en mi propia experiencia y en los comentarios de muchos compañeros de trabajo, Tailwind ofrece varias ventajas clave:

Prototipado Rápido: El enfoque de utilidades primero de Tailwind permite a los desarrolladores construir y estilizar rápidamente elementos de la UI sin escribir clases CSS personalizadas. Esto acelera significativamente el proceso de prototipado e iteración.
Estilo Consistente: Tailwind proporciona un conjunto predefinido de clases de utilidad, asegurando un estilo consistente en todo tu proyecto. Esto elimina la necesidad de reinventar constantemente la rueda y ayuda a mantener un sistema de diseño cohesivo.
Mejor Experiencia del Desarrollador: La sintaxis intuitiva de Tailwind y las características de autocompletado en los editores de código modernos mejoran la experiencia del desarrollador, haciendo que escribir y mantener CSS sea más rápido y agradable.
Reducción del Tamaño del Archivo CSS: Al aprovechar las clases de utilidad predefinidas, a menudo puedes reducir significativamente el tamaño total de tus archivos CSS, lo que lleva a tiempos de carga de página más rápidos y un mejor rendimiento.
Comunidad y Ecosistema Sólidos: Tailwind cuenta con una comunidad grande y activa, proporcionando acceso a documentación extensa, recursos útiles y una gran cantidad de plugins y extensiones construidos por la comunidad.

En mi experiencia, la curva de aprendizaje inicial de Tailwind es relativamente menor. La mayoría de los desarrolladores se vuelven competentes en una semana, y los beneficios a largo plazo en términos de velocidad de desarrollo y mantenibilidad superan con creces la inversión inicial.

Te animo a probar Tailwind. Podrías sorprenderte de cuánto puede simplificar tu flujo de trabajo de CSS y aumentar tu productividad.

Obtención de datos en React

React/Tanstack Query

Para la mayoría de las necesidades de obtención de datos, priorizo los Componentes del Servidor debido a sus ventajas inherentes de rendimiento y mejora en la seguridad de los datos. Al manejar la carga de datos en el servidor, puedo minimizar la cantidad de JavaScript ejecutado en el navegador, lo que resulta en cargas iniciales de página más rápidas y una mejor experiencia de usuario.

Sin embargo, para escenarios más complejos como el scroll infinito, la paginación o las actualizaciones de datos en tiempo real, aprovecho el poder de React Query. React Query proporciona una solución robusta y flexible para gestionar la obtención de datos, el almacenamiento en caché y las actualizaciones en el lado del cliente.

Ejemplo:

Componentes del Servidor: Ideal para obtener datos iniciales para una página de producto, perfil de usuario o publicación de blog.
React Query: Excelente para implementar scroll infinito en un feed, gestionar datos paginados en una tabla o manejar actualizaciones en tiempo real para una aplicación de chat.

Al combinar estratégicamente Componentes del Servidor y React Query, puedo lograr un equilibrio óptimo entre rendimiento, mantenibilidad y experiencia del desarrollador en mis aplicaciones React.

Base de Datos & ORM

Prisma

Mi Elección Preferida para Interacciones con la Base de Datos

Prisma ORM sigue siendo mi elección preferida para interactuar con bases de datos en mis proyectos React. Aunque ORMs más nuevos como Drizzle están ganando tracción, Prisma ha demostrado ser una solución estable y confiable con una comunidad fuerte y documentación extensa.

Características Clave de Prisma:

Seguridad de Tipos: Prisma genera tipos de TypeScript a partir de tu esquema de base de datos, asegurando la seguridad de tipos en toda tu aplicación y reduciendo el riesgo de errores en tiempo de ejecución.

Ejemplo:

const user = await prisma.user.findUnique({
  where: { id: 1 },
  include: { posts: true },
});

Los tipos generados para user y posts proporcionan una guía clara y previenen estructuras de datos inesperadas.

Definición Declarativa del Esquema: Define tu esquema de base de datos usando Prisma Schema Language, una sintaxis declarativa e intuitiva.

Ejemplo:

model User {
  id Int @id @default(autoincrement())
  name String
  email String @unique
  posts Post[]
}

model Post {
  id Int @id @default(autoincrement())
  title String
  content String
  author User @relation(fields: [authorId], references: [id])
  authorId Int
}

Consulta Simplificada: Prisma proporciona una API de creación de consultas fluida e intuitiva, lo que facilita la escritura de consultas complejas a la base de datos con un esfuerzo mínimo.
Migraciones: Prisma Migrate simplifica los cambios en el esquema de la base de datos con un sistema de migración fácil de usar, permitiéndote evolucionar tu base de datos de manera segura con el tiempo.

Beneficios de Usar Prisma

Aumento de la Productividad: Prisma mejora significativamente la productividad del desarrollador al automatizar tareas repetitivas, como la generación de consultas SQL y la gestión de cambios en el esquema de la base de datos.
Mejora de la Calidad del Código: La seguridad de tipos, los tipos generados y el enfoque en las mejores prácticas contribuyen a una mayor calidad del código y a menos errores.
Mantenibilidad Mejorada: El enfoque declarativo de Prisma y las definiciones claras del esquema facilitan la comprensión y el mantenimiento de las interacciones con la base de datos a lo largo del tiempo.
Comunidad y Ecosistema Sólidos: Prisma cuenta con una comunidad grande y activa, proporcionando acceso a documentación extensa, tutoriales y recursos de soporte.

Aunque ORMs más nuevos como Drizzle ofrecen características prometedoras, la estabilidad de Prisma, su ecosistema maduro y su fuerte enfoque en la experiencia del desarrollador lo convierten en mi elección preferida para la mayoría de los proyectos.

Supabase

Supabase es una alternativa de código abierto a Firebase que ofrece una suite completa de servicios backend, incluyendo una base de datos PostgreSQL en tiempo real, autenticación, almacenamiento y edge-functions. Proporciona a los desarrolladores una forma rápida y eficiente de construir aplicaciones web full-stack sin la molestia de gestionar la infraestructura.

Características Clave de Supabase:

PostgreSQL en Tiempo Real: Supabase aprovecha PostgreSQL por sus capacidades robustas de base de datos, permitiéndote crear modelos de datos complejos y realizar consultas poderosas. Las características en tiempo real te permiten construir aplicaciones con actualizaciones en vivo, como aplicaciones de chat y paneles de control.
Autenticación: Supabase proporciona un sistema de autenticación flexible que soporta varios métodos como email/contraseña, inicios de sesión sociales y proveedores de autenticación personalizados. También ofrece características como autenticación sin contraseña y autenticación multifactor.
Almacenamiento: Supabase incluye un servicio de almacenamiento de archivos que te permite subir y gestionar archivos directamente desde tu aplicación. Puedes generar URLs públicas para los archivos y establecer permisos para controlar el acceso.
Funciones en el Borde: Estas funciones serverless te permiten ejecutar código personalizado en el borde, más cerca de tus usuarios. Esto es útil para tareas como transformación de datos, renderizado del lado del servidor y lógica de autenticación personalizada.
API GraphQL: Además de la API REST, Supabase también ofrece una API GraphQL, proporcionando una forma más flexible y expresiva de consultar tus datos.

¿Por Qué Elegir Supabase?

Desarrollo Rápido: Supabase acelera el desarrollo proporcionando servicios backend preconstruidos, permitiéndote enfocarte en construir el frontend de tu aplicación.
Escalabilidad: Supabase está construido sobre una infraestructura escalable, haciéndolo adecuado para aplicaciones de todos los tamaños.
Código Abierto: Al ser de código abierto, Supabase ofrece transparencia, flexibilidad y una comunidad fuerte.
Rentable: Supabase ofrece un generoso nivel gratuito y planes de precios flexibles, haciéndolo asequible para proyectos pequeños y grandes.

Cuándo Usar Supabase

Aplicaciones en Tiempo Real: Supabase es ideal para aplicaciones que requieren actualizaciones en tiempo real, como aplicaciones de chat, herramientas colaborativas y paneles de control.
Prototipado Rápido: La facilidad de uso de Supabase lo convierte en una excelente opción para construir rápidamente prototipos y MVPs.
Aplicaciones Web Full-Stack: Supabase puede ser utilizado como el backend para aplicaciones web tanto simples como complejas.

Manejo y Validación de Datos

TypeScript

TypeScript es innegablemente el estándar de la industria para proyectos JavaScript. Su sistema de tipos estático, combinado con características modernas como interfaces y módulos, ofrece una serie de ventajas, como una mayor seguridad de tipos, una mejor detección de errores, una mayor productividad y una experiencia de desarrollo más agradable. La adopción de TypeScript por parte de la industria es un testimonio de su valor y eficacia.

Zod

Una poderosa herramienta para la validación Type-Safe

Zod ha emergido como una opción líder para la validación en proyectos React, particularmente cuando se combina con TypeScript. Al aprovechar el enfoque de tipo seguro de Zod, puede mejorar significativamente la robustez y la capacidad de mantenimiento de sus aplicaciones.

Características Clave de Zod

Validación Segura por Tipos: Zod aprovecha el sistema de tipos de TypeScript para definir y hacer cumplir esquemas de datos. Esto asegura que los datos recibidos por tu aplicación se ajusten a la estructura esperada, previniendo errores inesperados y mejorando la integridad de los datos.
Esquemas Declarativos: Zod te permite definir esquemas de datos de manera declarativa usando una sintaxis concisa y expresiva. Esto facilita la creación de reglas de validación complejas para tus datos.
Manejo de Errores: Zod proporciona mensajes de error detallados e informativos, lo que facilita la identificación y corrección de problemas de validación. Estos mensajes de error pueden integrarse fácilmente en tu interfaz de usuario para proporcionar retroalimentación útil a los usuarios.
Extensibilidad: Zod ofrece una API flexible y extensible, permitiéndote crear reglas de validación personalizadas e integrarlas con otras partes de tu aplicación.

Beneficios de Usar Zod

Mejora de la Calidad del Código: Al hacer cumplir tipos de datos y reglas de validación, Zod te ayuda a escribir código más robusto y confiable con menos errores inesperados.
Mejora de la Experiencia del Desarrollador: El enfoque seguro por tipos de Zod y sus mensajes de error informativos mejoran significativamente la experiencia del desarrollador al facilitar la escritura, depuración y mantenimiento de tu código.
Mejora de la Experiencia del Usuario: Al proporcionar mensajes de error claros y útiles a los usuarios, Zod ayuda a mejorar la experiencia general del usuario de tu aplicación.
Reducción de Costos de Mantenimiento: Al detectar problemas de validación de datos desde el principio, Zod puede ayudar a reducir los costos de mantenimiento a largo plazo asociados con tu aplicación.

Mi Enfoque

Aunque Zod ofrece potentes capacidades de validación del lado del cliente, prefiero usarlo principalmente para la validación del lado del servidor, particularmente dentro de las Acciones del Servidor. Este enfoque mantiene los formularios del lado del cliente ligeros y evita la complejidad introducida por muchas bibliotecas de formularios de terceros. Al confiar en la validación nativa de HTML para verificaciones básicas, puedo mantener una arquitectura de componentes de formularios ágil y eficiente.

Pruebas y herramientas

Mock Service Worker (MSW)

Una herramienta que ha mejorado drásticamente mi flujo de trabajo es Mock Service Worker (MSW). Si aún no la usas, déjame mostrarte por qué merece tu atención.

Mock Service Worker es una potente librería JavaScript para API mocking. Intercepta peticiones a nivel de red usando Service Workers, permitiéndote simular APIs directamente en el navegador o en tiempo de ejecución Node.js. Esto lo hace perfecto para pruebas, depuración e incluso desarrollo sin depender de un backend.

Por qué me encanta usar MSW

Para mí, MSW resuelve muchos problemas que otras librerías de mocking no pueden:

Mocking Realista: MSW intercepta solicitudes a nivel de red, por lo que el comportamiento simulado es casi indistinguible de un servidor real. Es como tener un emulador de backend en tu bolsillo.
Pruebas de Cliente y Servidor: Ya sea que estés probando una aplicación React o un servicio Node.js, MSW funciona perfectamente en ambos entornos.
Reducción de Dependencias: No necesitas servidores de prueba adicionales ni configuraciones de mocking complejas. MSW lo mantiene limpio y simple.
Flexibilidad: Puedes simular APIs REST, GraphQL e incluso WebSocket. Si tu aplicación puede hacer la solicitud, MSW puede simularla.
Mejor Depuración: Con registros claros y herramientas de depuración, sabes exactamente qué solicitudes están siendo simuladas y cómo.

MSW vs. Herramientas Mocking Tradicionales

En mi experiencia, MSW destaca sobre herramientas como los interceptores Axios o los mocks personalizados:

Escalabilidad: Con MSW, tus mocks viven fuera de la lógica de tu aplicación, haciéndolos reutilizables y mantenibles.
Aislamiento: A diferencia de los interceptores, MSW no interfiere con el código de tu aplicación. Esto significa que no hay código desordenado de desmontaje después de las pruebas.
Comportamiento Similar al Navegador: Al usar Service Workers, MSW imita el comportamiento a nivel del navegador, asegurando que tus pruebas sean lo más cercanas posible a las condiciones del mundo real.

Por Qué Deberías Probar MSW

Las APIs son la columna vertebral de las aplicaciones modernas, y probarlas no tiene por qué ser doloroso. MSW proporciona una forma realista, flexible y amigable para el desarrollador de simular APIs sin complejidad innecesaria.

Ya sea que estés desarrollando, depurando o probando, MSW es un cambio de juego. Es la herramienta que no sabía que necesitaba, pero de la que ahora no puedo prescindir.

Si estás buscando elevar tu proceso de desarrollo en 2025, prueba MSW. Tu equipo te lo agradecerá y tu código brillará.

Playwright

Cuando se trata de pruebas web modernas en 2025, Playwright se ha convertido en una de mis herramientas de referencia. No es sólo una biblioteca de pruebas; se siente como una herramienta de poder para los desarrolladores front-end que quieren precisión, velocidad y versatilidad.

Playwright es una biblioteca Node.js para la automatización del navegador. Creada por Microsoft, permite escribir pruebas de extremo a extremo para aplicaciones web en los principales navegadores (Chromium, Firefox, WebKit) con una API coherente. Es como tener una navaja suiza para las pruebas de navegador que es elegante, potente y fácil de usar para los desarrolladores.

Por qué destaca Playwright

Desde mi experiencia, Playwright destaca en:

Soporte Multi-Navegador: A diferencia de Cypress, que solo soporta navegadores basados en Chromium de forma predeterminada, Playwright te permite probar en Chromium, Firefox y WebKit. Esto lo hace indispensable para asegurar que tu aplicación funcione en diferentes entornos.
Pruebas en Paralelo: La paralelización integrada de Playwright es un cambio de juego. Las pruebas se ejecutan más rápido, lo que mantiene la tubería de CI fluida y a los desarrolladores productivos.
Modos Headless y Headed: Ya sea que estés depurando o ejecutando pruebas en CI, Playwright se adapta sin problemas.
Aislamiento de Contextos: Con Playwright, puedes crear contextos de navegador aislados que imitan diferentes usuarios. Esto es una salvación para aplicaciones con flujos de autenticación complejos o escenarios multi-tenant.
Pruebas de API: Playwright no se detiene en la UI. Puedes hacer llamadas API directamente dentro de tus scripts de prueba, asegurando que tu front-end y back-end funcionen armoniosamente.

Veamos algo de código

He aquí un ejemplo rápido de cómo escribir una prueba Playwright en TypeScript. Esta prueba comprueba una página de inicio de sesión:

import { test, expect } from "@playwright/test";

test.describe("Login Page Tests", () => {
  test("should log in successfully with valid credentials", async ({
    page,
  }) => {
    await page.goto("https://example.com/login");

    // Fill out the login form
    await page.fill("#username", "testuser");
    await page.fill("#password", "securepassword");
    await page.click('button[type="submit"]');

    // Assert redirection to the dashboard
    await expect(page).toHaveURL("https://example.com/dashboard");
    await expect(page.locator("h1")).toHaveText("Welcome, testuser!");
  });

  test("should show an error for invalid credentials", async ({ page }) => {
    await page.goto("https://example.com/login");

    // Fill out the form with invalid data
    await page.fill("#username", "wronguser");
    await page.fill("#password", "wrongpassword");
    await page.click('button[type="submit"]');

    // Assert error message is displayed
    await expect(page.locator(".error-message")).toHaveText(
      "Invalid credentials"
    );
  });
});

Las pruebas ya no son opcionales en 2025. Los usuarios esperan experiencias impecables, y la automatización es la forma de ofrecerlas. Playwright combina potencia con funciones fáciles de usar para los desarrolladores, lo que la convierte en una herramienta imprescindible.

Si aún no la ha explorado, ahora es el momento. Su yo del futuro se lo agradecerá cuando sus pruebas se ejecuten más rápido, sus errores disminuyan y sus usuarios estén contentos.

Despliegue y alojamiento

Cloudflare (Dominio & CDN)

Cloudflare sigue siendo una piedra angular del desarrollo web moderno. Para mí, no es sólo un servicio, es una parte integral de la creación de aplicaciones rápidas, seguras y escalables. Tanto si eres un desarrollador independiente como si formas parte de un gran equipo, Cloudflare tiene herramientas que elevarán tu pila.

¿Qué es Cloudflare?

Cloudflare es un conjunto completo de herramientas de rendimiento y seguridad web. Comenzó como una red de distribución de contenidos (CDN), pero hoy en día es mucho más. Con Cloudflare, puedes optimizar el rendimiento de tu sitio web, protegerlo de ataques maliciosos e incluso crear aplicaciones sin servidor utilizando su potente plataforma de computación edge.

Por qué confío en Cloudflare

Estas son las razones más destacadas por las que Cloudflare es una parte esencial de mi stack:

Velocidad en Todas Partes: Con su CDN global, Cloudflare asegura que los activos estáticos de tu aplicación se entreguen a la velocidad del rayo, sin importar dónde estén tus usuarios. Su caché es una salvación para aplicaciones con activos pesados o audiencias globales.
Seguridad Inigualable: El Firewall de Aplicaciones Web (WAF) y la protección contra DDoS de Cloudflare me han ahorrado innumerables dolores de cabeza. Es como tener un equipo de seguridad en piloto automático.
Computación Serverless en el Borde: Usar Cloudflare Workers ha sido un cambio de juego. Me permite ejecutar funciones ligeras en el borde, reduciendo la latencia y descargando trabajo de los servidores tradicionales.
Facilidad de Uso: Configurar Cloudflare toma minutos, pero los beneficios son inmensos. Su panel intuitivo y herramientas amigables para desarrolladores hacen que sea fácil integrarlo con cualquier stack.
Rentable: Por el valor que proporciona, el precio de Cloudflare es inmejorable. Incluso su nivel gratuito está lleno de características que pueden ayudarte a empezar sin preocuparte por los costos.

Crear aplicaciones modernas significa ofrecer experiencias rápidas, seguras y fiables. Cloudflare te permite conseguir todo esto sin complicar en exceso tu stack. Desde su imbatible CDN hasta su innovadora plataforma Edge Computing, es una herramienta que recomendaría a cualquier desarrollador que quiera preparar sus aplicaciones para el futuro en 2025.

Si aún no ha explorado Cloudflare, ahora es el momento perfecto. Sus usuarios notarán la diferencia, y usted también.

Otras Utilidades:

React Email & Resend

Una potente combinación para la entrega de correo electrónico

React Email y Resend ofrecen una solución convincente para crear y entregar correos electrónicos de alta calidad dentro de sus aplicaciones React.

React Email: Esta biblioteca te permite crear plantillas de correo electrónico visualmente atractivas y responsivas directamente dentro de tus componentes React. Aprovechando conceptos familiares de React como componentes, estado y props, puedes crear diseños de correo electrónico dinámicos y fáciles de mantener.
Resend: Esta robusta API de correo electrónico proporciona una forma confiable y eficiente de enviar correos electrónicos transaccionales, como correos de bienvenida, restablecimientos de contraseña y confirmaciones de pedidos. Resend ofrece características como alta entregabilidad, análisis robustos e integración fácil con tu infraestructura existente.

Beneficios Clave

Mejor Experiencia del Desarrollador: React Email mejora la experiencia del desarrollador al permitirte crear plantillas de correo electrónico utilizando patrones familiares de React, lo que lleva a una mayor productividad y mantenibilidad.
Branding Consistente: Al usar componentes React para tus plantillas de correo electrónico, puedes asegurar un branding y estilo consistentes en toda tu aplicación, incluidos los correos electrónicos.
Mejor Entregabilidad: La infraestructura robusta de Resend y su enfoque en la entregabilidad ayudan a asegurar que tus correos electrónicos lleguen a los destinatarios previstos de manera confiable.
Integración Fácil: Resend ofrece una API sencilla y SDKs para una fácil integración con tu aplicación React.

Ejemplo:

// src/components/EmailTemplates/WelcomeEmail.jsx
import * as React from "react";
import { Html, Head, Title, Body, P, H1 } from "@react-email/components";

export const WelcomeEmail = ({ name }) => (
  <Html>
    <Head>
      <Title>Welcome to Our App!</Title>
    </Head>
    <Body>
      <H1>Hello, {name}!</H1>
      <P>Welcome to our app! We're excited to have you join us.</P>
      {/* ... more email content ... */}
    </Body>
  </Html>
);

// src/pages/api/sendWelcomeEmail.js
import { Resend } from "resend";

const resend = new Resend(process.env.RESEND_API_KEY);

export default async function handler(req, res) {
  try {
    await resend.emails.send({
      from: "no-reply@yourdomain.com",
      to: "recipient@example.com",
      subject: "Welcome to Our App!",
      html: await renderToString(<WelcomeEmail name="John Doe" />),
    });

    res.status(200).json({ success: true });
  } catch (error) {
    console.error(error);
    res.status(500).json({ error: "Failed to send email" });
  }
}

Este ejemplo muestra cómo utilizar React Email para crear una plantilla de correo electrónico de bienvenida sencilla y, a continuación, utilizar la API Resend para enviarla.

Al combinar la potencia de React Email y Resend, puede agilizar sus flujos de trabajo de correo electrónico, mejorar la calidad de sus comunicaciones por correo electrónico y mejorar la experiencia general del usuario.

Stripe

Stripe es una pasarela de pago robusta y ampliamente utilizada que ofrece un conjunto completo de funciones para aceptar pagos en línea.

Retos potenciales

Complejidad: Aunque es potente, el amplio conjunto de características de Stripe puede resultar abrumador, especialmente para proyectos más pequeños o aquellos con requisitos de pago más simples.
API en Evolución: Stripe introduce continuamente nuevas características y actualiza su API, lo que ocasionalmente puede requerir ajustes en tu integración.

import React, { useState } from "react";
import { loadStripe } from "@stripe/stripe-js";

const stripePromise = loadStripe("YOUR_STRIPE_PUBLIC_KEY");

function CheckoutForm() {
  const [loading, setLoading] = useState(false);

  const handleSubmit = async (event) => {
    event.preventDefault();
    setLoading(true);

    try {
      const stripe = await stripePromise;
      const { error } = await stripe.redirectToCheckout({
        lineItems: [
          {
            price: "price_1234567890abc123",
            quantity: 1,
          },
        ],
      });

      if (error) {
        console.error(error);
        // Handle error (e.g., display an error message to the user)
      }
    } catch (error) {
      console.error(error);
    } finally {
      setLoading(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      {/* ... form fields ... */}
      <button type="submit" disabled={loading}>
        {loading ? "Processing..." : "Pay Now"}
      </button>
    </form>
  );
}

export default CheckoutForm;

Esencialmente, esta es la pila tecnológica que yo elegiría hoy para un nuevo proyecto React full-stack. Esta es solo una combinación posible, y la mejor pila tecnológica para tu proyecto dependerá en última instancia de tus requisitos y prioridades específicos. Te animo a explorar estas tecnologías y experimentar con diferentes combinaciones para encontrar lo que mejor funciona para ti.

¡Espero que esto haya sido útil y/o te haya enseñado algo nuevo!

@khriztianmoreno 🚀

Un senior destaca por su forma de pensar, no de codear

Khriztian Moreno — Tue, 10 Dec 2024 20:23:42 +0000

El análisis de edge cases: una clave para evaluar a desarrolladores senior

El mundo de la programación está en constante cambio, pero muchas empresas siguen usando métodos de evaluación obsoletos para medir las habilidades de los desarrolladores senior. Si bien las pruebas teóricas son útiles para medir conocimientos básicos, no reflejan con precisión la capacidad de un senior para resolver problemas complejos del mundo real.

¿Por qué las pruebas técnicas tradicionales no son suficientes?

Las pruebas basadas solo en conceptos teóricos no logran capturar el verdadero valor de un desarrollador senior. La experiencia de un senior se mide en su capacidad para anticipar problemas, diseñar soluciones escalables y optimizar sistemas. Un buen desarrollador senior no solo domina el código, sino que también sabe cómo manejar excepciones, gestionar la complejidad y pensar de manera crítica ante escenarios inciertos.

El enfoque práctico: análisis de edge cases

Un ejercicio clave para evaluar a un desarrollador senior es presentarle un escenario realista y pedirle que identifique y resuelva los edge cases. Tomemos como ejemplo el desarrollo de una página con búsqueda y paginación. En una entrevista técnica, un senior experimentado debería ser capaz de pensar en escenarios extremos que podrían romper la funcionalidad, tales como:

CONTINUA LEYENDO EL POST EN MI BLOG

Desbloquea tu creatividad con Google Gemini y JavaScript: Guía práctica

Khriztian Moreno — Fri, 15 Mar 2024 16:50:56 +0000

Hola! Hoy les traigo una nueva herramienta que potenciará tu creatividad a otro nivel: Google Gemini. Esta API de inteligencia artificial te permite generar texto de alta calidad en español, desde simples frases hasta historias completas, con solo unas pocas líneas de código.

¿Qué es Google Gemini?

Google Gemini es un modelo de lenguaje de última generación desarrollado por Google AI. Se ha entrenado con un conjunto de datos masivo de texto y código, lo que le permite comprender y generar lenguaje natural con una precisión impresionante.

¿Qué podemos hacer con Google Gemini y JavaScript?

Las posibilidades son infinitas. Aquí te presento algunos ejemplos:

Generar contenido creativo: Escribe poemas, historias, guiones, artículos de blog, o cualquier tipo de contenido textual que puedas imaginar.
Traducir idiomas: Traduce textos de un idioma a otro de forma rápida y precisa. Responder preguntas: Obtén respuestas a tus preguntas de forma informativa y completa.
Crear chatbots: Desarrolla chatbots conversacionales que interactúen con los usuarios de forma natural.
Automatizar tareas: Automatiza la generación de informes, correos electrónicos, y otras tareas que requieren procesamiento de lenguaje natural.

¿Cómo empezar?

Para empezar a usar Google Gemini con JavaScript, solo necesitas:

Una cuenta de Google Cloud Platform: https://cloud.google.com/
Habilitar la API de Google Gemini: https://ai.google.dev/

Ejemplo práctico:

En este ejemplo, vamos a generar un poema usando Google Gemini y JavaScript.

const { GoogleGenerativeAI } = require("@google/generative-ai");

// Access your API key as an environment variable (see "Set up your API key" above)
const genAI = new GoogleGenerativeAI(process.env.API_KEY);

async function run() {
  // For embeddings, use the embedding-001 model
  const model = genAI.getGenerativeModel({ model: "embedding-001"});

  const text = "Escribe un poema sobre la naturaleza"

  const result = await model.embedContent(text);
  const embedding = result.embedding;
  console.log(embedding.values);
}

run();

Para la generación de texto usamos el método getGenerativeModel del objeto genAI.

Ejemplo de poema generado:

La tierra verde, el cielo azul,
el sol brilla con luz de cristal.
Las flores florecen en el jardín,
los pájaros cantan con dulce trino.

El viento susurra entre las hojas,
las abejas zumban entre las flores.
La naturaleza es un regalo divino,
un lugar de paz y armonía.

Conclusión:

Google Gemini y JavaScript son una combinación poderosa que te permite desbloquear tu creatividad y desarrollar aplicaciones increíbles. Con esta guía práctica, ya estás listo para empezar a explorar las posibilidades infinitas de esta tecnología.

Recursos adicionales:

Documentación de Google Gemini: https://ai.google.dev/docs
Tutoriales de Google Gemini: https://m.youtube.com/watch?v=TXvbT8ORI50
Ejemplos de código de Google Gemini: https://m.youtube.com/watch?v=jTdouaDuUOA

¡Anímate a experimentar con Google Gemini y JavaScript! Comparte tus creaciones en los comentarios y déjame saber qué te parece esta herramienta.

Cómo mockear una solicitud HTTP con Jest 💻

Khriztian Moreno — Fri, 23 Feb 2024 13:20:52 +0000

Hoy quería mostrarles cómo escribir correctamente una prueba.

Pero cualquiera puede encontrar cómo ejecutar una prueba sencilla. Y aquí, buscamos ayudarle a encontrar respuestas que no encontrará en ningún otro lugar.

Entonces pensé que llevaríamos las cosas un paso más allá.

Ejecutemos una prueba más compleja, en la que tendrás que simular 1 o 2 partes de la función que estás probando.

[En caso de que seas nuevo aquí: mock es como usar un doble en una película. Es una forma de reemplazar una parte complicada de tu código (como llamar a una API) con algo más simple que pretende ser real, para que pueda probar el resto de tu código fácilmente].

MI testing framework elegido es Jest, porque hace que todo sea mucho más fácil:

Configuración cero: una de las principales ventajas de Jest es su configuración sin configuración. Está diseñado para funcionar desde el primer momento con una configuración mínima, lo que lo hace muy atractivo para proyectos que desean implementar pruebas de manera rápida y eficiente.
Prueba de instantáneas: Jest introdujo el concepto de Snapshot Testing, que es particularmente útil para probar componentes de la interfaz de usuario. Toma una instantánea de la salida renderizada de un componente y garantiza que no cambie inesperadamente en pruebas futuras.
Mocking y Spies Integrados: Jest viene con soporte integrado para funciones, módulos y temporizadores simulados, lo que facilita la prueba de componentes o funciones de forma aislada sin preocuparse por sus dependencias.
Compatibilidad con pruebas asincrónicas: Jest admite pruebas asincrónicas listas para usar, lo cual es esencial para las pruebas en aplicaciones JavaScript modernas que a menudo dependen de operaciones asincrónicas como llamadas API o consultas de bases de datos.

De todos modos, entremos en las pruebas:

Paso 1: configurar tu proyecto

Cree un nuevo directorio de proyecto y navegue hasta él
Inicialice un nuevo proyecto npm: npm init -y
Instale Jest: npm install --save-dev jest
Instale axios para realizar solicitudes HTTP: npm install axios

Estos son los requisitos básicos. Nada nuevo o sofisticado aquí. Vamonos.

Paso 2: escribir una función con una llamada API

Ahora, digamos que inicia sesión en algún tipo de aplicación. StackOverflow, por ejemplo. Lo más probable es que en la parte superior derecha veas información sobre tu perfil. Tal vez su nombre completo y nombre de usuario, por ejemplo.

Para obtenerlos, normalmente tenemos que realizar una llamada a la API para obtenerlos. Entonces, veamos cómo haríamos eso.

Cree un archivo llamado user.js
Dentro de user.js, escriba una función que realice una llamada API. Por ejemplo, usar axios para recuperar datos del usuario:



// user.js
import axios from 'axios';

export const getUser = async (userId) => {
  const response = await axios.get(`https://api.example.com/users/${userId}`);
  return response.data;
};

Paso 3: crear el archivo de prueba

Bien, ahora que tenemos una función que nos trae el usuario según la identificación que solicitamos, veamos cómo podemos probarla.

Recuerde, queremos algo que funcione siempre y para todos los desarrolladores.

Lo que significa que no queremos depender de si el servidor se está ejecutando o no (ya que esto no es lo que estamos probando).

Y no queremos depender de los usuarios que tenemos en la base de datos.

Porque en mi base de datos, el ID1 podría pertenecer a mi usuario administrador, mientras que en su base de datos, el ID1 podría pertenecer a SU usuario administrador.

Esto significa que la misma función nos daría resultados diferentes. Lo que haría que la prueba fallara, aunque la función funcione correctamente.

Siga leyendo para ver cómo abordamos este problema mediante los mocks.

Cree un archivo llamado user.test.js en el mismo directorio.
Dentro de este archivo, importe la función que desea probar: ```js

import axios from 'axios';
jest.mock('axios');

import { getUser } from './user';

3. Escriba su caso de prueba, simule la llamada y recupere datos simulados. 
```js


test('should fetch user data', async () => {
  // Mock data to be returned by the Axios request
  const mockUserData = { id: '1', name: 'John Doe' };
  axios.get.mockResolvedValue({ data: mockUserData });

  // Call the function
  const result = await getUser('1');

  // Assert that the Axios get method was called correctly
  expect(axios.get).toHaveBeenCalledWith('https://api.example.com/users/1');

  // Assert that the function returned the correct data
  expect(result).toEqual(mockUserData);
});

Paso 4: ejecutar la prueba

Agregue un script de prueba a su package.json:



"scripts": {
  "test": "jest"
}

Ejecute sus pruebas con npm test.

Paso 5: revise los resultados

Jest mostrará el resultado de su prueba en la terminal. La prueba debería pasar, lo que indica que getUser está devolviendo los datos simulados como se esperaba.

Felicitaciones, ahora tienes una prueba funcional con Jest y Mocking.

¡Espero que esto haya sido útil y/o te haya hecho aprender algo nuevo!

@khriztianmoreno

¿Estás cometiendo ESTOS errores de pruebas y mocking unitarios?

Khriztian Moreno — Fri, 16 Feb 2024 18:26:04 +0000

Las pruebas son difíciles.

Y no importa si eres un tester experimentado o principiante...

Si ha realizado un esfuerzo significativo para probar una aplicación...

Es probable que hayas cometido algunos de estos errores de prueba y mocking en el pasado.

Desde casos de prueba repletos de código duplicado y enormes hooks de ciclo de vida, hasta casos de mocking convenientemente incorrectos y casos extremos que faltan y furtivos, hay muchos culpables comunes.

He seguido algunos de los casos más populares y los enumero a continuación. Continúe y cuente cuántos de ellos ha hecho en el pasado.

Con suerte, será una buena ronda.

¿Por qué la gente comete errores en las pruebas en primer lugar?

Si bien las pruebas automatizadas son una de las partes más importantes del proceso de desarrollo...

Y las pruebas unitarias nos ahorran innumerables horas de pruebas manuales e innumerables errores que quedan atrapados en los conjuntos de pruebas...

Muchas empresas no utilizan pruebas unitarias o no ejecutan suficientes pruebas.

¿Sabía que la cobertura de prueba promedio de un proyecto es de ~40%, mientras que la recomendada es del 80%?

Esto significa que mucha gente no está acostumbrada a ejecutar pruebas (especialmente casos de prueba complejos) y cuando no estás acostumbrado a hacer algo, eres más propenso a cometer un error.

Entonces, sin más preámbulos, veamos algunos de los errores de prueba más comunes que veo

Código duplicado

Las tres reglas más importantes del desarrollo de software son también las tres reglas más importantes de las pruebas.

¿Cuáles son estas reglas?
Reutilizar. Reutilizar. Reutilizar.

Un problema común que veo es repetir la misma serie de comandos en cada prueba en lugar de moverlos a un enlace de ciclo de vida como beforeEach o afterEach

Esto podría deberse a que el desarrollador estaba creando un prototipo o a que el proyecto era pequeño y el cambio insignificante. Estos casos son buenos y aceptables.

Pero unos cuantos casos de prueba más tarde, el problema de la duplicación de código se vuelve cada vez más evidente.

Y aunque esto es más bien un error de un desarrollador junior, el siguiente es similar pero mucho más astuto.

Sobrecargar los hooks del ciclo de vida

En la otra cara de la misma moneda, a veces estamos demasiado ansiosos por refactorizar nuestros casos de prueba y ponemos tantas cosas en los hooks del ciclo de vida sin pensarlo dos veces que no vemos el problema que nos estamos creando.

A veces, los hooks del ciclo de vida crecen demasiado.

Y cuando esto sucede...

...y necesitas desplazarte hacia arriba y hacia abajo para ir desde el hook al caso de prueba y viceversa...

Esto es un problema y a menudo se lo denomina "fatiga de desplazamiento".

Recuerdo haber sido culpable de esto en el pasado.

Un patrón/práctica común para mantener el archivo legible cuando tenemos hooks de ciclo de vida inflados es extraer el código de configuración común en pequeñas funciones de fábrica.

Entonces, imaginemos que tenemos algunas (docenas de) casos de prueba que se ven así:



describe('authController', () => {
  describe('signup', () => {
    test('given user object, returns response with 201 status', async () => {
      // Arrange
      const userObject = {
        // several lines of user setup code
      }
      const dbUser = {
        // several lines of user setup code
      }
      mockingoose(User).toReturn(undefined, 'findOne');
      mockingoose(User).toReturn(dbUser, 'save');
      const mockRequest = { 
                // several lines of constructing the request
            }
      const mockResponse = {
        // several lines of constructing the response
      }

      // Act
      await signup(mockRequest, mockResponse)
      // Assert
      expect(mockResponse.status).toHaveBeenCalled()
      expect(mockResponse.status).toHaveBeenCalledWith(201)
    })

    test('given user object with email of an existing user, returns 400 status - 1', async () => {
      // Arrange
      const userObject = {
        // several lines of user setup code
      }
      const dbUser = {
        // several lines of user setup code
      }
      const mockRequest = { 
                // several lines of constructing the request
            }
      const mockJson = jest.fn()
      const mockResponse = {
        // several lines of constructing the response
      }
      mockingoose(User).toReturn(dbUser, 'findOne');

      // Act
      await signup(mockRequest, mockResponse)

      // Assert
      expect(mockResponse.status).toHaveBeenCalled()
      expect(mockResponse.status).toHaveBeenCalledWith(400)

      expect(mockJson).toHaveBeenCalled()
      expect(mockJson).toHaveBeenCalledWith({
        status: 'fail',
        message: 'Email taken.'
      })
    })
  })
})

Podemos extraer la información de configuración repetida en sus propias funciones llamadas createUserObject, createDbUserObject y createMocks

Y luego las pruebas quedarían así:



test('given user object, returns response with 201 status', async () => {
  const userObject = createUserObject()
  const dbUser = createDbUserObject()
  const [mockRequest, mockResponse] = createMocks(userObject)
  mockingoose(User).toReturn(undefined, 'findOne');
  mockingoose(User).toReturn(dbUser, 'save');
  await signup(mockRequest, mockResponse)
  expect(mockResponse.status).toHaveBeenCalled()
  expect(mockResponse.status).toHaveBeenCalledWith(201)
})

Al extraer esos fragmentos de código en sus propias funciones de fábrica separadas, podemos evitar la fatiga del desplazamiento, mantener los enlaces del ciclo de vida ágiles y facilitar la navegación por el archivo y encontrar lo que estamos buscando.

No priorizar los tipos de pruebas que ejecutas

Esto tiene más que ver con bases de código grandes o enormes donde hay literalmente cientos o incluso miles de casos de prueba ejecutándose cada vez que una nueva serie de commits quiere fusionarse en la base de código.

En tales casos, ejecutar todos los conjuntos de pruebas puede llevar literalmente horas y es posible que no siempre tenga el tiempo o los recursos para hacerlo.

Cuando el tiempo o los recursos están limitados, es importante elegir estratégicamente el tipo de prueba a priorizar. Generalmente, las pruebas de integración brindan mejores garantías de confiabilidad debido a su alcance más amplio. Por lo tanto, cuando se tiene que elegir entre los dos, suele ser una buena idea elegir las pruebas de integración en lugar de las pruebas unitarias.

Usar lógica en tus casos de prueba

Queremos evitar la lógica en nuestros casos de prueba siempre que sea posible.

Los casos de prueba solo deben tener una validación simple y evitar cosas como bloques try-catch o condicionales if-else.

Esto mantiene tus pruebas limpias y enfocadas solo en el flujo esperado porque hace que las pruebas sean más fáciles de entender de un vistazo.

La única excepción es cuando estás escribiendo funciones auxiliares o de fábrica que configuran escenarios para pruebas.

Utilizar validaciones vagas en lugar de afirmaciones estrictas

Esto suele ser una señal de que es posible que necesites refactorizar el fragmento de código que estás probando o que necesites hacer un ajuste menor en tus mocks.

Por ejemplo, en lugar de comprobar si el valor es mayor que 1, deberías ser más específico y afirmar que el valor es 2.

O, si está verificando los datos de un objeto Usuario, debe afirmar que cada dato es exactamente como lo espera, en lugar de simplemente verificar una coincidencia de ID.

Los controles sueltos pueden enmascarar casos extremos que podrían fallar en el futuro.

Implementación incorrecta del Mock Behavior

Este es difícil de encontrar y es por eso que puedes encontrar un ejemplo en cada código base.

Es uno de los problemas de prueba más astutos pero comunes y es difícil notarlo a primera vista.

Puede suceder cuando el comportamiento del mock está demasiado simplificado o cuando no refleja con precisión los casos extremos y las condiciones de error.

Como resultado, las pruebas pueden pasar, pero no proporcionarán una indicación confiable de cómo funcionará el sistema bajo diversas condiciones, lo que resulta en errores futuros y problemas inesperados, y casos de prueba con comportamiento simulado que terminan haciendo más daño que bien.

Espero este post te ayude a indetificar esas practicas que deberiamos evitar al momento de hacer pruebas.

@khriztianmoreno

Hasta la próxima.

Por qué es tan difícil pasar el estado entre los componentes del cliente y del servidor

Khriztian Moreno — Tue, 09 Jan 2024 13:58:25 +0000

La forma en que representamos los componentes del servidor es diferente.

Nada parecido a lo que estamos acostumbrados hasta ahora.

Y debido a que es tan diferente, también cambia dónde manejamos el estado, cómo lo manejamos y cómo logramos dormir por la noche sabiendo que todas estas son cosas importantes que deberíamos saber desde el año pasado, pero la mayoría de nosotros somos completamente inconscientes.

De hecho, los componentes del servidor impactan 3 de las partes más importantes del desarrollo web:

Performance
Experiencia del usuario
La forma en que nosotros, los desarrolladores, escribimos código y diseñamos nuestras aplicaciones.

No es algo que podamos ignorar o tomar a la ligera.

Como puedes ver, he estado pensando mucho en ello y probablemente tú también lo hayas estado pensando. Todo desarrollador que valore su teclado está pensando en ello.

Y está esta pregunta específica... Es como una pregunta del tipo “la gallina y el huevo”, principalmente porque ambas son preguntas que se hacen mucho.

¿Cómo diablos manejo el estado en los componentes del servidor si no tengo acceso al estado en primer lugar?

Antes de darte la respuesta, déjame explicarte el problema que nos ocupa. Considere lo que sucede cuando un componente del servidor solicita una nueva renderización.

A diferencia de los componentes del cliente donde el estado se conserva entre renderizaciones, los componentes del servidor no pueden darse ese lujo. Como un juego pícaro, siempre empiezan desde cero.

No existe ningún código o mecanismo inherente que pueda hacer que un componente del servidor recuerde el estado. El backend tiene todas esas bases de datos y patrones de diseño y todas esas funciones complejas y ¿para qué? Ni siquiera puede manejar el estado.

¿Asi que que hacemos? ¿Utilizamos simplemente componentes de servidor en componentes completamente estáticos que no necesitan ningún estado? Si bien esta es una posible respuesta, también es un enfoque que limita la efectividad y el ajuste de los componentes del servidor en las aplicaciones web modernas. Entonces, lo estamos descartando.

Porque todo lo que dije anteriormente tiene un inconveniente.

Si bien es posible que el backend no maneje el estado del cliente como lo hace el cliente, sí maneja el estado de la aplicación. Entonces, en cierto modo, podemos manejar el estado en el servidor. Simplemente no de la forma en que lo piensas. Y, en realidad, no es una única manera.

Y, en realidad, no es una única manera.

Hay TRES formas de manejar el estado en el servidor.

Cuál elegimos depende de lo que mejor se adapte a nuestras necesidades y situación actual. Y estas 3 formas son:

Prop drilling desde el servidor a los componentes
cookies
state hydration

Ahora, otra pregunta del millón. ¿Por qué no podemos simplemente manejar todos los estados en el cliente?

Esto se debe a que los componentes del servidor abogan por una separación de preocupaciones. Lo que en términos más simples significa que cada parte de la aplicación debe ocuparse de sus propios asuntos. Al desacoplar el estado del renderizado, no solo mejoramos el rendimiento, sino que también obtenemos más control sobre la experiencia del usuario.

@khriztianmoreno

Hasta la próxima.

¿Seguirás utilizando componentes del lado del cliente en 2024?

Khriztian Moreno — Fri, 05 Jan 2024 12:15:03 +0000

Me encantan los componentes del servidor. Pero no son para todas las ocasiones. De hecho, usarlos en todas y cada una de las oportunidades que tengas es más como ablandar un bistec con el mismo martillo que usaste para clavar un alfiler.

Dicho esto, también hay algunos casos en los que los componentes del servidor encajan como Cenicienta y su zapato.

Dashboards & Reports

En el caso de los paneles y los informes, se maximiza el rendimiento al procesar y representar todos los datos en el servidor y, al mismo tiempo, permitir que el cliente haga lo que se suponía que debía hacer en primer lugar.

Si solo usamos componentes del cliente, le estamos descargando más tareas y haciendo que desempeñe más tareas de las que potencialmente puede manejar.

Si procesó y representó los datos en el cliente, pasaría mucho tiempo esperando con un feo spinner burlándose de usted debido a todos los pasos adicionales que el cliente tiene que seguir para lograr el mismo resultado.

Primero, necesitaría obtener los datos de su endpoint, que a su vez tendría que obtener datos de la base de datos, que a su vez tendría que obtener datos de sus registros.

No sólo eso, sino que también hay que esperar pacientemente a que los datos lleguen al cliente, aunque llegue tarde.

Y sólo una vez que llegan, el cliente puede comenzar a procesarlos y mostrárselos al usuario.

Por eso, en este caso, es mejor tener los componentes bloqueados y renderizados directamente en el servidor.

Y luego, el cliente puede obtener todos los widgets que su corazón electrónico desea, todos transmitidos en paralelo, lo que es una forma mucho más rápida y sencilla de realizar negocios.

Blog Posts

Las publicaciones de blog son algunos de los contenidos más estáticos que puedes encontrar. Después de todo, se trata principalmente de un montón de palabras, en orden, con alguna imagen, gif o meme ocasional aquí y allá.

Con los componentes del servidor, estás renderizando previamente el contenido en el servidor, que es el mejor de los casos en términos de SEO porque se entrega rápido y completo.

Este caso de uso anterior es lo que tiende a desequilibrar a los desarrolladores y confundirlos. Porque las publicaciones de blogs son lo primero en lo que también piensan cuando se trata de SSR. Entonces, si piensan en SSR y componentes de servidor cuando piensan en publicaciones de blog, es natural pensar que ambos son lo mismo o que pueden usarse indistintamente.

Lo cual es total y absolutamente incorrecto y es un pecado digno de arder en el infierno por la eternidad, según mi blog post anterior.

Pero al mismo tiempo tiene sentido desde el punto de vista de los resultados. Porque aunque sus enfoques son muy diferentes en la práctica, los resultados son bastante similares.

Server-Side Data Fetching

La obtención de datos del lado del servidor es una excelente manera de darle a su código un impulso de seguridad en caso de que, de lo contrario, revele lógica o claves API que se supone deben permanecer ocultas o si está paranoico con respecto a cada pieza de información que posee.

Puede utilizar este tipo de obtención de datos para acceder no sólo a su base de datos sino también a cualquier otra API que desee. Todo ello siendo astuto.

Sin embargo, hay casos en los que los componentes del servidor NO son ideales y, de hecho, deben evitarse.

Requisitos de alta interactividad

Esta es una redacción elegante para cualquier cosa a la que le haces algo y le devuelves algo. Algo así como gelatina, pero no tanto.

Algo potencialmente más familiar y más acorde con el desarrollo web en sí son elementos como formularios y botones.

Estos componentes a menudo tienen que reaccionar de alguna manera a sus acciones, pueden tener su propio estado y comunicarse con otros componentes en el lado del cliente, lo que los convierte en el eslabón más débil cuando se trata de componentes de servidor.

Stateful Components

Si lo tomas lo más literalmente posible y usas la definición que hemos estado usando hasta ahora, no hay manera de manejar el estado en un componente del servidor.

Pero si entrecierras los ojos, inclinas la cabeza un poco hacia un lado, desenfocas un poco y respiras profundamente, podrás ver que esto es sólo una verdad a medias.

En otro momento aprenderemos cuáles son los matices, pero por ahora digamos que los componentes del servidor NO tienen acceso al estado. Después de todo, no tienen acceso a hooks relacionados con el estado.

Conclusión

Los componentes del servidor son una herramienta poderosa para escenarios específicos en el desarrollo web. Utilícelos para mejorar el rendimiento y la seguridad de tareas con uso intensivo de datos. Pero recuerde, es posible que no se adapten a todas las situaciones, especialmente para elementos interactivos o con estado.

@khriztianmoreno

Hasta la próxima.

Server Components Vs. Server-side Rendering

Khriztian Moreno — Thu, 04 Jan 2024 14:02:56 +0000

¿Sabías que los componentes del servidor y el renderizado del lado del servidor son dos cosas completamente diferentes?

Y si bien van de la mano en muchos casos, hay igualmente muchos ejemplos en los que puedes y debes usar solo uno de ellos.

Ahora bien, para ser justos, dada la documentación en línea que la mayoría de los desarrolladores encuentran sobre los componentes del servidor y el renderizado del lado del servidor, el hecho de que asuman que estas dos cosas son iguales no es exactamente una sorpresa.

(Esto también les da la excusa perfecta para evitar los componentes del servidor por completo, en lugar de enfrentar el hecho de que esto es algo que ya deberían saber usar bastante bien y que eventualmente tendrán que aprender de todos modos)

Dicho esto, los componentes del servidor tienen muchas ventajas sobre el renderizado del lado del servidor, especialmente cuando se trata de crear aplicaciones más grandes y complejas.

Hablemos un poco más de las diferencias entre ambos.

Server-Side Rendering

La representación del lado del servidor representa la página en el servidor. Pero, obviamente, eso no es realmente útil, así que profundicemos un poco más.

La representación del lado del servidor representa la página en el servidor en el momento de la solicitud, lo que significa que cada vez que un cliente realiza una solicitud al servidor, como cuando un nuevo visitante llega a su página, el servidor vuelve a representar la misma página y la envía a el cliente.

Y si bien esto es excelente para SEO, ya que incluso las páginas más dinámicas aparecen como estáticas a los ojos de los robots que las indexan y las usan para búsquedas, la representación del lado del servidor tiene muchos pasos entre el cliente que realiza la solicitud al servidor y La página finalmente se carga frente a ti.

Primero, cuando la solicitud llega al servidor, el servidor representa estáticamente la página y la envía de regreso al cliente, donde el usuario obtiene una versión de su página que está desprovista de toda interactividad.

Pero eso no es lo único que el servidor envía al cliente. Junto con el HTML de la página estática, el servidor envía sus condolencias junto con un gran paquete de código React que el cliente deberá ejecutar para que la página vuelva a ser dinámica.

Pero ¿qué pasa cuando el 90% de nuestra página es estática?

Podrías pensar que la respuesta correcta es “prácticamente nada” y no estarías exactamente equivocado, pero al igual que en la clase de Cálculo, pierdes puntos porque esta no es la respuesta que estaba buscando.

En realidad, todavía se envía una gran cantidad de JavaScript al cliente y debe ejecutarse sin cambiar mucho en la página misma.

Esto es una pérdida de tiempo y datos y es una de las principales razones por las que se crearon los componentes del servidor.

(Lo que también significa que si está utilizando SSR como alternativa a los componentes del servidor, ha tenido un gran problema y es hora de cambiar su forma de actuar antes de que lo arrojen a una cárcel de "rendimiento lento").

Server Components

Los componentes del servidor, como SSR, se representan en el servidor, pero tienen la capacidad única de incluir lógica del lado del servidor sin enviar ningún JavaScript adicional al cliente, ya que los componentes del servidor se ejecutan en el servidor.

Esto significa que mientras en SSR el código JavaScript se ejecuta en el cliente, en Server Components, el código se ejecuta directamente en el servidor. Y el cliente solo recibe la salida del código a través de la carga útil del servidor, como un bebé al que le mastican la comida.

Entonces, en pocas palabras, la diferencia entre componentes de servidor y renderizado del lado del servidor tiene que ver con cuándo y cómo se ejecuta el código. En el caso de los componentes del servidor, no es necesario enviar ni manejar código adicional en el lado del cliente porque ya lo ejecutamos en el servidor.

El único código necesario es si está uniendo los componentes del servidor y del cliente y el cliente tiene que unir los dos.

El gran beneficio de los componentes de servidor es que ofrecen un mayor rendimiento porque necesitan menos JavaScript del lado del cliente y descargan todo el procesamiento y la recuperación de datos al servidor mientras el cliente puede relajarse y beber Aperol Spritz hasta que llegue el HTML renderizado.

En ese momento, el cliente simplemente se lo muestra al usuario final y se lleva todo el crédito por el arduo trabajo realizado por el servidor.

Y si bien esto puede parecer un poco complejo en este momento, todo se aclarará a medida que aprenda más sobre los componentes del servidor. Lo cual es algo que realmente no se puede evitar, ya que se están volviendo cada vez más populares en casos de uso como:

Tener muchos cálculos pesados que necesitan mucho procesamiento
Acceso API privado (para mantener el secreto… secret)
Cuando la mayor parte del lado del cliente ya es estático y sería un desperdicio enviar más JavaScript al cliente

Conclusión

Si bien los componentes de servidor pueden parecer desalentadores en este momento, en su mayoría son algo nuevo y extraño. Una vez que los conozcas mejor y aprendas algunos de los conceptos básicos, te darás cuenta de que no son tan complejos como parecen.

La curva de aprendizaje no es tan pronunciada como podría pensar y solo porque tengan "sever" en el nombre, no significa que tengan que ser algo extraño y críptico de lo que los desarrolladores frontend debamos mantenernos alejados. De hecho, son bastante similares a los componentes del cliente e incluso más livianos ya que carecen de elementos como enlaces de estado, etc.

@khriztianmoreno

Hasta la próxima.

Predicciones 🧞‍♀️💻 2024

Khriztian Moreno — Wed, 03 Jan 2024 15:28:21 +0000

Algunos puntos que deberías prestar atención para este año 2024 que seguro tendrán un alto impacto en el ecosistema tecnológico.

Bun logra su objetivo de convertirse en el runtime predeterminado para frontend: Todavía tienen algunos obstáculos que superar, pero si logran proporcionar un reemplazo directo para Node que mejore instantáneamente el rendimiento de su aplicación 10 veces, será una opción obvia para la mayoría de los desarrolladores. El lanzamiento v1.0 de septiembre pasado fue un paso importante hacia la compatibilidad y la estabilidad general de Windows, y la apuesta es a que Bun comience a convertirse en la opción predeterminada este año.
La IA reemplazará las herramientas no-code/low-code: Resulta que la IA es mucho mejor y más rápida a la hora de crear paneles de análisis de marketing. Herramientas como Basedash y 8base ya utilizan IA para crear un conjunto completo de requerimientos, herramientas internas personalizadas, y surgirán otras para reemplazar a los builders de arrastrar y soltar para crear sitios que no dependan en gran medida de la lógica empresarial.
Netlify es adquirida por GoDaddy: Con múltiples rondas de despidos, 2023 claramente no fue el mejor año para Netlify. Pero a veces la mejor manera de recuperarse es buscarse un nuevo ~~sugar daddy~~, GoDaddy. Después de retirar la marca Media Temple hace unos meses, parece que GoDaddy podría volver al mercado de adquisiciones para una plataforma como Netlify.

Alguna otra que se te ocurra? Ayudame actulizar este post!!

@khriztianmoreno

Hasta la próxima.

Clonar un objeto en JavaScript: 4 mejores formas [Ejemplos]

Khriztian Moreno — Mon, 23 Jan 2023 21:11:21 +0000

Clonar un objeto en JavaScript significa crear una copia idéntica de un objeto existente. Esto significa que el nuevo objeto tendrá los mismos valores para cada propiedad, pero será un objeto diferente.

¿Por qué es importante clonar un objeto en javascript?

Clonar un objeto en javascript es importante para preservar el estado original de un objeto y evitar la propagación de los cambios. Esto es especialmente útil cuando hay varias instancias de un objeto que se comparten entre varias partes de la aplicación. Clonar el objeto original garantiza que las otras instancias no se vean afectadas por los cambios realizados en el objeto original. Esto también permite a los desarrolladores usar una sola instancia del objeto y crear una copia única para cada parte de la aplicación. Esto evita tener que crear cada vez una nueva instancia del objeto, lo que ahorra tiempo y recursos.

¿Cómo clonar un objeto?

Para clonar un objeto JavaScript correctamente, tienes 4 opciones diferentes:

Usar la función structuredClone()
Usar el spread operator
Llamar la función Object.assign()
Usar JSON parsing.

const data = { name: "khriztianmoreno", age: 33 }
// 1
const copy4 = structuredClone(data)
// 2
const copy1 = { ...data }
// 3
const copy2 = Object.assign({}, data)
// 4
const copy3 = JSON.parse(JSON.stringify(data))

1. `structuredClone()`

Crea un clon profundo de un valor dado utilizando el algoritmo de clonación estructurada.

const original = {
  someProp: "with a string value",
  anotherProp: {
    withAnotherProp: 1,
    andAnotherProp: true
  }
};

const myDeepCopy = structuredClone(original);

2. spread operator

El operador de propagación (...) permite expandir un objeto o un arreglo en una lista de elementos individuales, y se utiliza para crear una copia de un objeto.

const original = { name: "khriztianmoreno", age: 33 };
const clone = {...original};

En el ejemplo anterior, se esta creando un nuevo objeto clone a partir de los valores del objeto original, es importante notar que esto solo hace una copia superficial, si el objeto original contiene objetos o arreglos dentro de el, estos no serán clonados sino que se asigna la referencia del objeto original.

También se puede utilizar para clonar arreglos de la siguiente manera:

const original = [1,2,3,4];
const clone = [...original];

3. `Object.assign`

La función Object.assign() es otra forma de clonar objetos en JavaScript. La función toma un objeto destino como primer argumento, y uno o más objetos fuente como argumentos adicionales. Copia las propiedades enumerables de los objetos fuente al objeto destino.

const original = { name: "khriztianmoreno", age: 33 };
const clone = Object.assign({}, original);

4. JSON parsing

El método JSON.parse() y JSON.stringify() es otra forma de clonar objetos en JavaScript. El método JSON.stringify() convierte un objeto en una cadena de texto en formato JSON, mientras que el método JSON.parse() convierte una cadena de texto en formato JSON en un objeto de JavaScript.

const original = { name: "khriztianmoreno", age: 33 };
const clone = JSON.parse(JSON.stringify(original));

Conclusiones

Ventajas de clonar un objeto en javascript

El clonado de objetos permite al desarrollador crear una copia de un objeto existente sin tener que redefinir todos los valores del objeto. Esto significa que el desarrollador puede ahorrar tiempo y esfuerzo al no tener que recrear un objeto desde cero.
El clonado de objetos también permite al desarrollador crear una versión modificada de un objeto existente. Por ejemplo, un desarrollador puede modificar los valores de un objeto existente para crear una versión personalizada. Esto es útil para ahorrar tiempo al no tener que reescribir el código para crear un objeto desde cero.
El clonado de objetos también permite al desarrollador crear una versión mejorada de un objeto existente. Por ejemplo, un desarrollador puede añadir nuevas propiedades a un objeto existente para mejorar su funcionalidad.
El clonado de objetos también ofrece una forma de hacer copias de seguridad de los objetos. Esto significa que si el objeto existente se ve afectado por una falla de software, el desarrollador puede recurrir a la copia de seguridad para recuperar los valores originales.

Desventajas de clonar un objeto en javascript

Clonar un objeto en Javascript puede ser una tarea útil, pero también hay algunos inconvenientes que deben tenerse en cuenta. El primero es el tiempo de ejecución. El clonado de objetos en Javascript puede ser un proceso lento, especialmente si el objeto es grande. Esto puede llevar a una mala experiencia de usuario si se está intentando clonar un objeto mientras se ejecuta una aplicación.

Otra desventaja del clonado de objetos en Javascript es que no se pueden clonar objetos complejos. Esto significa que los objetos que contienen referencias a otros objetos no se pueden clonar correctamente. Esto puede ser un problema si se está intentando clonar un objeto que contiene referencias a otros objetos importantes, ya que el clon no tendrá estas referencias.

Por último, el clonado de objetos en Javascript también puede llevar a problemas de seguridad si se clonan objetos que contienen información sensible. El clon puede contener la misma información que el objeto original, lo que puede ser un riesgo para la seguridad si se comparte el clon con otros usuarios.

¡Eso es todo amigxs! ¡Espero que este artículo lo ayude a comprender las diferentes opciones que tenemos a la hora de clonar un objecto/arraglo en javascript.

@khriztianmoreno

Hasta la próxima.

PD: Este articulo fue escrito completamente usando Inteligencia Aritifcial

Cómo usar los métodos Call, Apply y Bind en javascript

Khriztian Moreno — Wed, 28 Sep 2022 15:55:52 +0000

En este artículo, veremos qué son los métodos call, apply y bind en javascript y por qué existen.

Antes de saltar, necesitamos saber que es this en javascript, en este post puedes profundizar un poco más.

En Javascript, todas las funciones tendrán acceso a una palabra clave especial llamada this, el valor de this apuntará al objeto en el que se ejecuta esa función.

¿Qué son estos métodos `call`, `apply` y `bind`?

Para decirlo de una manera simple, todos estos métodos se usan para cambiar el valor de this dentro de una función.

Entendamos cada método en detalle.

call()

Usando el método call, podemos invocar una función, pasando un valor que será tratado como this dentro de ella.



const obj = {
  myName: "khriztianmoreno",
  printName: function () {
    console.log(this.myName);
  },
};

obj.printName(); // khriztianmoreno

const newObj = {
  myName: "mafeserna",
};

obj.printName.call(newObj); //mafeserna

en el ejemplo anterior, estamos invocando el método call en la función printName al pasar newObj como parámetro, por lo que ahora this dentro de printName apunta a newObj, por lo tanto, this.myName imprime mafeserna.

¿Cómo pasar argumentos a funciones?

El primer argumento del método call es el valor al que apunta this dentro de la función, para pasar argumentos adicionales a esa función, podemos comenzar a pasarlo desde el segundo argumento del método call.



function foo(param1, param2) {}
foo.call(thisObj, arg1, arg2);

dónde:

foo es la función que estamos invocando al pasar el nuevo valor this que es thisObj
arg1, arg2, son los argumentos adicionales que tomará la función foo ( param1= arg1 , param2 = arg2 )

apply()

La función apply es muy similar a la función call. La única diferencia entre call y apply es la diferencia en cómo se pasan los argumentos.

call — pasamos argumentos como valores individuales, comenzando desde el segundo argumento
apply — los argumentos adicionales se pasarán como un arreglo



function sayHello(greet, msg) {
  console.log(`${greet} ${this.name} ! ${msg}`);
}

const obj = {
  name: "khriztianmoreno",
};

// Call
sayHello.call(obj, "Hello", "Good Morning"); 
// Hello khriztianmoreno ! Good Morning

// Apply
sayHello.apply(obj, ["Hello", "Good Morning"]); 
// Hello khriztianmoreno ! Good Morning

en el ejemplo anterior, tanto el método call como apply en la función sayHello están haciendo lo mismo, la única diferencia es cómo estamos pasando argumentos adicionales.

bind()

A diferencia de los métodos call y apply, bind no invocará la función directamente, sino que cambiará el valor this dentro de la función y devolverá la instancia de la función modificada.

Podemos invocar la función devuelta más tarde.



function sayHello() {
  console.log(this.name);
}

const obj = { name: "khriztianmoreno" };

// it won't invoke, it just returns back the new function instance
const newFunc = sayHello.bind(obj); 

newFunc(); // khriztianmoreno

pasando argumentos adicionales:
pasar argumentos adicionales en bind funciona de manera similar al método call, podemos pasar argumentos adicionales como valores individuales a partir del segundo argumento del método bind.



function sayHello(greet) {
  console.log(`${greet} ${this.name}`);
}

const obj = { name: "khriztianmoreno" };

const newFunc = sayHello.bind(obj, "Hello");
newFunc(); // Hello khriztianmoreno

En el caso del método bind, podemos pasar argumentos adicionales de dos formas:

Al llamar al método bind en sí mismo, podemos pasar argumentos adicionales junto con el valor de this a esa función.
Otra forma es que podemos pasar argumentos adicionales mientras invocamos la función de retorno del método bind.

Podemos seguir cualquiera de las formas anteriores y funciona de manera similar sin ninguna diferencia en la funcionalidad.



function sayHello(greet) {
  console.log(`${greet} ${this.name}`);
}

const obj = { name: "khriztianmoreno" };
const newFunc1 = sayHello.bind(obj, "Hello");
newFunc1(); // Hello khriztianmoreno

const newFunc2 = sayHello.bind(obj);
newFunc2("Hello"); // Hello khriztianmoreno

NOTA: si no pasamos ningún valor o pasamosnull mientras llamamos a los métodos call, apply, bind, entonces esta función interna de llamada apuntará al objeto global.



function sayHello() {
  // executing in browser env
  console.log(this === window);
}

sayHello.call(null); // true
sayHello.apply(); // true
sayHello.bind()(); // true

No podemos usar los métodos call, apply y bind en las funciones flecha para cambiar el valor de this, porque las funciones de flecha no tienen su propio contexto this.

El this dentro de la función de flecha apuntará a la función externa/principal en la que está presente.

Por lo tanto, aplicar estos métodos en la función de flecha no tendrá ningún efecto.

¡Eso es todo amigxs! ¡Espero que este artículo lo ayude a comprender qué son los métodos call(), apply() y bind() en javascript.!

@khriztianmoreno

Hasta la próxima.

Hacks para un desarrollo Fullstack efectivo con React y Node

Khriztian Moreno — Thu, 01 Sep 2022 18:45:21 +0000

Hoy te mostraré un flujo de trabajo óptimo para un desarrollo efectivo con Node.js y React. Si alguna vez ha trabajado en un proyecto con varios archivos package.json, es posible que conozca el dolor de hacer malabarismos con varias pestañas de terminal, recordar qué comandos inician qué servidor o manejar los errores de CORS.

Afortunadamente, hay algunas herramientas disponibles que pueden aliviar algunos de estos dolores de cabeza.

Configuración de Monorepo para React y Node

Digamos que estamos trabajando en un monorepo con dos archivos package.json: uno está en un directorio client para un front-end de React impulsado por Create React App, y uno está en la raíz del repositorio para un back-end de Node que expone un API que utiliza nuestra aplicación React. Nuestra aplicación React se ejecuta en localhost:3000 y nuestra aplicación Node se ejecuta en localhost:8080. Ambas aplicaciones se inician con npm start

Dado que tenemos dos archivos package.json, esto significa que para que nuestro front-end y back-end estén en funcionamiento, debemos asegurarnos de haber ejecutado npm install y npm start tanto en el directorio raíz como en el directorio del cliente. Así es como simplificamos esto.

1. Ejecutar dos servidores al mismo tiempo

Una mejora que podemos hacer en nuestro flujo de trabajo de desarrollo es agregar una herramienta de compilación para ejecutar varios comandos npm al mismo tiempo para ahorrarnos la molestia de ejecutar npm start en varias pestañas de terminal. Para hacer esto, podemos agregar un paquete npm llamado concurrently a la raíz de nuestro proyecto.

En la raíz de nuestro proyecto, lo instalaremos como una dependencia de desarrollo.

npm install -D concurrently

Luego, en nuestras secuencias de comandos root package.json, actualizaremos nuestra secuencia de comandos start para usarlas simultáneamente.

{
  "name": "my-app",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "start": "concurrently --kill-others-on-fail npm run server npm run client",
    "server": "node index.js",
    "client": "cd client && npm start"
  },
  "dependencies": {
    "express": "^4.17.1"
  },
  "devDependencies": {
    "concurrently": "^6.0.1"
  }
}

Ahora, tenemos tres scripts npm:

npm run server inicia nuestra aplicación Node,
npm run client ejecuta npm start en el directorio del client para iniciar nuestra aplicación React,
npm start ejecuta npm run server y npm run client al mismo tiempo.

2. Instalar las dependencias de front-end y back-end con un solo comando

Otro aspecto de nuestro flujo de trabajo que podemos mejorar es la instalación de dependencias. Actualmente, necesitamos ejecutar manualmente npm install para cada archivo package.json que tenemos al configurar el proyecto. En lugar de pasar por esa molestia, podemos agregar un postinstall script a nuestro package.json raiz para ejecutar automáticamente npm install en el directorio del client después de que la instalación haya finalizado en el directorio raíz.

{
  "name": "my-app",
  "scripts": {
    ...,
    "postinstall": "cd client && npm install"
  },
}

Ahora, cuando instalamos nuestro monorepo, todo lo que tenemos que hacer para ponerlo en marcha es ejecutar npm install y luego npm start en la raíz del proyecto. No es necesario ingresar a ningún otro directorio para ejecutar otros comandos.

3. Solicitudes API proxy desde el back-end

Como mencione anteriormente, nuestro back-end de Node expone los endpoints del API que utilizara nuestra aplicación React. Digamos que nuestra aplicación Node tiene un endpoint /refresh_token.

Fuera de la caja, si intentáramos enviar una solicitud GET a http://localhost:8080/refresh_token desde nuestra aplicación React en http://localhost:3000, nos encontraríamos con problemas de CORS. CORS significa intercambio de recursos de origen cruzado.

Por lo general, cuando encuentra errores de CORS, es porque está tratando de acceder a los recursos de otro dominio (es decir, http://localhost:3000 y http://localhost:8080), y el dominio del que está solicitando recursos no está permitido.

Para decirle al servidor de desarrollo que envíe por proxy cualquier solicitud desconocida a nuestro servidor API en desarrollo, podemos configurar un proxy en el archivo package.json de nuestra aplicación React. En client/package.json, agregaremos un proxy para http://localhost:8080 (donde se ejecuta nuestra aplicación Node).

{
  "name": "client-app",
  "proxy": "http://localhost:8080",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  ...
}

Ahora, si reiniciamos el servidor y configuramos una solicitud al endPoint /refresh_token de nuestra aplicación Node (sin http://localhost:8080) usando fetch(), el error CORS debería resolverse.

fetch('/refresh_token')
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => console.error(err));

La próxima vez que trabaje en un proyecto monorepo como este, pruebe estos tres consejos para optimizar su flujo de trabajo de desarrollo.

¡Eso es todo amigxs! ¡Espero que esto te ayude a convertirte en un o una mejor dev!

@khriztianmoreno

Hasta la próxima.