4 Commits

Include renames

Author	SHA1	Message	Date
devops	83d448b282	feat(ecommerce): facetas reales de Meilisearch en el sidebar del catalogo ... Fase 3b (ultima) de ADR 0006 Etapa 2: los conteos de categoria/marca/edad del sidebar de /catalog dejan de ser un snapshot client-side fijo. Ahora se refetchean en vivo contra /api/search en cada cambio de filtro (query debounced 300ms), tres llamadas paralelas -- una por dimension, cada una omitiendo su propio filtro para preservar el patron Amazon de "cuantos resultados habria si eligiera este otro valor". - catalog-client.tsx: useMemo client-side originales pasan a ser fallback (mock/shopify sin searchWithFacets, o cuando la categoria activa es un grupo raiz sintetico que Meilisearch no puede filtrar). - ProductFilters gana `limit` opcional; /api/search y el provider medusa lo reenvian -- las llamadas de solo-conteo piden limit=0 para no rehidratar precios de productos que no se van a mostrar.	2026-08-26 22:53:49 -05:00
devops	902350b58b	Fase 3a ADR 0006 Etapa 2: buscador del navbar via Meilisearch ... PredictiveSearch pasa de filtrar en memoria el arreglo completo de productos (prop products, substring match) a un fetch debounced (250ms, con AbortController) contra la nueva ruta /api/search -- mismo componente visual, solo cambia de donde salen los datos, tal como pide el ADR 0006 seccion 5. /api/search (nueva, server-side) es el puente same-origin: el componente es cliente y no puede pegarle directo al provider server-side (MEDUSA_BACKEND_URL es DNS interno del cluster, no resuelve desde el navegador). CatalogProvider gana un metodo OPCIONAL searchWithFacets? (no cambia la firma de getProducts/searchProducts) -- mock.ts y shopify.ts compilan sin tocarlos, siguen sin implementarlo. medusa.ts lo implementa contra /store/search (Fase 2), reutilizando mapProduct() ya que la ruta devuelve el mismo shape de producto que /store/products. searchProducts tambien se repunta a /store/search, dejando de usar el ?q= + re-filtro client-side de fetchProducts/matchesFilters para busqueda (que sigue sirviendo para navegacion sin busqueda, sin cambios). Navbar deja de pasarle products a PredictiveSearch (ya no los necesita) pero los sigue recibiendo el mismo -- collections todavia se deriva de ahi. Limpieza: borrado patches/frontend-medusa-env.yaml, confirmado huerfano (ningun kustomization lo referencia; el patch que si esta vivo es frontend/patches/deployment.yaml). Validado: build completo de Docker (target builder) -- npm ci, next build con typecheck, /api/search aparece en la tabla de rutas generada. Cero errores nuevos (los warnings de ESLint son preexistentes en catalog-client.tsx, no tocado en esta fase).	2026-08-26 17:30:47 -05:00
devops	d1a4a84d24	feat(ecommerce): revalidar el storefront al instante tras editar precios ... Antes el precio actualizado en Medusa tardaba hasta ~60s (o más, con varias réplicas del frontend sin cache handler compartido) en verse en el front, por el revalidate:60 del fetch a /store/products. Ahora: - Nueva ruta app/api/revalidate en el storefront que llama a revalidateTag("medusa-products") al recibir un POST autenticado con el header x-revalidate-secret. - Nuevo subscriber en el backend Medusa (product.updated, product-variant.updated/created/deleted) que llama a esa ruta usando STOREFRONT_URL (ya existe en commerce-config) y un REVALIDATE_SECRET compartido entre ambos servicios. - secrets.template.yaml documenta la nueva clave REVALIDATE_SECRET en commerce-secrets y commerce-storefront (mismo valor en ambos). Requiere reaplicar commerce-secrets y commerce-storefront con el script actualizado en el repo scripts (fix/revalidate-secret-scripts) para que el REVALIDATE_SECRET exista en el cluster.	2026-08-13 16:02:49 -05:00
devops	f263a9cc55	feat(ecommerce): migrate Ari Shopping to Next.js 15 headless storefront v4	2026-07-19 19:37:41 -05:00