Blog

Estado de servidor y estado de cliente en React

Estado de servidor y estado de cliente: por qué las apps de React necesitan dos librerías

El estado de servidor y el estado de cliente tienen requisitos distintos. Por qué los stacks modernos de React reparten el trabajo entre dos librerías en lugar de un solo store.

Apps construidas por separado instalando paquetes versionados (un contrato tipado y una pantalla compartida) desde un mismo registro

El paquete de contratos: una frontera versionada entre remotes federados en React Native

Ninguna app ve lo que publican las demás. Dos paquetes instalados por versión (un contrato tipado y la pantalla de detalle compartida) dan a cada lado una sola definición y dejan que semver gobierne la deriva.

Una app host de React Native con una tab bar inferior, cada pestaña cargando un remote distinto en runtime

El shell del host: remotes federados como pestañas en React Native

El host pasa de una pantalla a shell de la app: lleva la tab bar y la navegación, y cada pestaña es un remote construido, desplegado y cargado aparte.

Un host y un remote de React Native compartiendo una sola copia de una librería a través de un único share scope

El contrato de singletons compartidos en React Native Module Federation

Comparte react, react-native y una librería nativa entre un host y su remote de la forma correcta; hacerlo mal rompe la app al arrancar, no en silencio.

Una app host de React Native cargando una pantalla desde una app remote separada en runtime

Tu primer remote federado en React Native

Dos apps de React Native, una carga la pantalla de la otra en runtime con Module Federation 2.0 y Re.Pack. Cada paso se copia y pega, hasta una app en marcha.

Module Federation en React Native

Por qué Module Federation en React Native

Qué aportan a una app de React Native las micro-apps en runtime, qué cuestan y cuándo compensa. Intro de una serie que construye un setup federado desde cero.

Estructura de proyecto feature-first en React Native

Por qué uso una estructura de proyecto feature-first en React Native

Un argumento para organizar proyectos React Native por feature, no por tipo. La prueba de eliminar, los límites de import y dónde vive el código compartido.

Detox y Cucumber BDD para testing E2E en React Native

Detox + Cucumber BDD para testing E2E en React Native

Detox + Cucumber para tests E2E en React Native. Definiciones de pasos, formatter personalizado, ejecución en paralelo y tests de regresión de accesibilidad.

Tres escalones descendentes con un cubo cerrado con candado, una caja fuerte y una bandeja abierta, con una flecha clasificadora

Tokens en React Native: AsyncStorage frente a SecureStore

Los tokens no van en AsyncStorage. Cómo SecureStore, un almacén cifrado y AsyncStorage se reparten el trabajo en React Native, y qué guarda cada uno.

Una malla atravesada en una tubería que intercepta las flechas entrantes y las clasifica en una bandeja de éxito y otra de fallo

Cómo configurar MSW v2 en React Native

Configurar Mock Service Worker v2 en React Native, de la instalación a un conjunto completo de handlers: éxito, errores, timeouts y offline.

Interview Kit ejecutándose en un portátil durante una entrevista técnica

Construí una app que el comité de contratación nunca va a abrir

De Notion a markdown a una app de React para entrevistas técnicas estructuradas: el camino hasta un formato que funciona en directo y genera buenos informes.

Diseño de una prueba técnica para casa para ingenieros de software

Cómo escribir una prueba técnica para casa que los candidatos realmente quieran hacer

La mayoría de las pruebas técnicas fallan por fricción en el setup, briefs vagos o no respetar el tiempo del candidato. Así diseñé una que agradecen.

Cargar más artículos