<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Frontend on Patrones — Exeal</title><link>https://patterns.exeal.com/tags/frontend/</link><description>Recent content in Frontend on Patrones — Exeal</description><generator>Hugo</generator><language>es-ES</language><lastBuildDate>Thu, 24 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://patterns.exeal.com/tags/frontend/index.xml" rel="self" type="application/rss+xml"/><item><title>Arquitectura en capas para frontend React</title><link>https://patterns.exeal.com/patterns/arquitectura-en-capas-para-frontend-react/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/arquitectura-en-capas-para-frontend-react/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;En una SPA React sin fronteras internas, todo tiende a mezclarse dentro del componente que renderiza la pantalla: la llamada a la API, el estado de carga/error, la lógica de negocio (qué pedir, cómo combinar resultados, cuándo revalidar) y el JSX que lo pinta. El resultado es un componente que solo se puede testear montándolo entero — con mocks de &lt;code&gt;fetch&lt;/code&gt;, de router, de lo que haga falta — y donde no hay forma de reutilizar la lógica en otro sitio ni de darle una historia de Storybook sin resolver antes media aplicación.&lt;/p&gt;</description></item><item><title>One build, many deploys para imágenes de frontend</title><link>https://patterns.exeal.com/patterns/runtime-env-config/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/runtime-env-config/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;Un frontend construido con Vite lee sus variables de entorno (&lt;code&gt;VITE_*&lt;/code&gt;) en tiempo de build: Vite las sustituye literalmente en el bundle. Eso significa que la URL de la API, el authority OIDC o el DSN de Sentry quedan &amp;ldquo;planchados&amp;rdquo; dentro del JavaScript compilado. Si quieres desplegar la misma app en &lt;code&gt;staging&lt;/code&gt; y en &lt;code&gt;production&lt;/code&gt; con distinta configuración, te ves obligado a construir una imagen por entorno — un pipeline de CI que hace build, build y build otra vez, cada uno con sus &lt;code&gt;--build-arg&lt;/code&gt;, solo para cambiar cuatro strings.&lt;/p&gt;</description></item><item><title>Snapshot de contrato OpenAPI aceptado explícitamente</title><link>https://patterns.exeal.com/patterns/snapshot-contrato-openapi/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/snapshot-contrato-openapi/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;Cuando el contrato HTTP de una API se genera automáticamente a partir del código (controladores, DTOs, atributos), nadie lo &amp;ldquo;escribe&amp;rdquo; a mano — y por eso nadie lo revisa a propósito tampoco. Un refactor interno que renombra un campo, cambia su tipo, o hace opcional algo que antes era obligatorio, cambia el contrato público como efecto secundario silencioso: compila, los tests unitarios pasan, y el PR se fusiona sin que nadie haya mirado el swagger. El consumidor de esa API (un frontend, otro servicio, un cliente externo) se entera cuando algo se rompe en producción, no en la revisión del cambio.&lt;/p&gt;</description></item><item><title>Tests de aceptación de frontend sobre una imagen Docker ya construida</title><link>https://patterns.exeal.com/patterns/tests-aceptacion-frontend-sobre-imagen-construida/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/tests-aceptacion-frontend-sobre-imagen-construida/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;Un frontend construido con Vite y servido como estático (nginx) no se despliega como código fuente: se despliega como imagen Docker. Una suite de Playwright que arranca contra &lt;code&gt;vite dev&lt;/code&gt; o contra un build en el propio runner de CI no ejercita nada de lo que hay entre ese código y el artefacto real — el &lt;code&gt;Dockerfile&lt;/code&gt;, si nginx sirve las rutas de la SPA correctamente, si el entrypoint que inyecta la configuración en tiempo de arranque (ver el patrón de runtime env config) realmente deja la app apuntando a la API correcta. Todo eso puede pasar los tests unitarios y de componente y romperse solo en la imagen empaquetada.&lt;/p&gt;</description></item></channel></rss>