Skip to main content

Documentation Index

Fetch the complete documentation index at: https://wiki.vivla.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Autenticacion

La app implementa un sistema de autenticacion custom basado en JWT, sin depender de servicios externos como Clerk, Auth0 o Supabase. Toda la logica se concentra en el modulo src/modules/auth/ y el cliente API en src/shared/services/api/.

​
Flujo de Autenticacion

  1. El usuario ingresa email y contrasena 2. Se llama a authApi.login(email, password) 3. La API devuelve: token, refreshToken, tokenExpiresIn, datos de usuario 4. Se calcula tokenExpiry = Date.now() + tokenExpiresIn * 1000 5. Se almacenan tokens en SecureStore y datos de usuario en SecureStore 6. Se limpia el cache de tokens del API client (clearTokenCache) 7. Se actualiza el authStore con isAuthenticated: true 8. Se identifica al usuario en PostHog analytics 9. Se inicializa la conexion a Stream Chat (no bloqueante) 10. Se invalidan todas las queries de React Query

​
Gestion de Tokens

​
Token Refresh Automatico

Cuando el access token expira, el sistema gestiona la renovacion automaticamente: 
Request fallido (UNAUTHENTICATED)
        │
        ▼
┌─ Es el primer reintento? ─┐
│                            │
│ SI                    NO ──┼──► Encolar request en requestQueue
│                            │    (espera a que termine el refresh)
▼                            │
isRefreshing = true          │
        │                    │
        ▼                    │
refreshToken()               │
        │                    │
   ┌────┴────┐               │
   │         │               │
Exito     Fallo              │
   │         │               │
   ▼         ▼               │
Reintentar  Limpiar auth     │
request +   + logout         │
procesar    forzado          │
cola                         │
Las requests que llegan durante el proceso de refresh se encolan en requestQueue. Una vez completado el refresh exitosamente, todas las requests encoladas se reintentan con el nuevo token.

​
Token Caching

El API client implementa un cache de token en memoria para evitar lecturas frecuentes a SecureStore:
ParametroValor
Duracion del cache5 segundos
Reintentos de lectura de SecureStore3 intentos
Delay entre reintentos500ms (incremental: 500ms, 1000ms, 1500ms)

​
API Client

El cliente HTTP (src/shared/services/api/client.ts) esta construido sobre Axios con la siguiente configuracion:
ConfiguracionValor
Timeout30 segundos
Content-Typeapplication/json
Reintentos de SecureStore3 intentos, 500ms delay
Token cache5 segundos

​
Interceptors

Request Interceptor

  • Agrega parametro lang a la URL segun idioma actual
  • Cambia baseURL a chat backend si useChatBackend: true
  • Obtiene token de auth y agrega header Authorization: Bearer <token>
  • Respeta requiresAuth: false en headers para requests publicos

Response Interceptor

  • Verifica el campo code en la respuesta de la API
  • Si code !== SUCCESS, lanza ApiError
  • Si code === UNAUTHENTICATED, inicia flujo de token refresh
  • Para errores de red (sin response), clasifica el tipo de fallo

​
Manejo de Errores

El error handler (src/shared/services/api/errorHandler.ts) clasifica los errores de red en categorias:
Tipo de FalloDeteccionEjemplo
timeoutECONNABORTED o mensaje contiene “timeout”Request excede 30s
dns_or_connectivityMensaje contiene “network error”, “failed to connect”, “dns”Sin conexion a internet
tls_or_certificateMensaje contiene “ssl”, “tls”, “certificate”, “handshake”Certificado invalido
cancelledERR_CANCELED o mensaje contiene “canceled”Request cancelado por el usuario
unknownNinguno de los anterioresError no clasificado
Todos los errores se reportan a Sentry con contexto adicional (endpoint, metodo, plataforma, diagnosticos de red).

​
Codigos de API

El sistema maneja los siguientes codigos de respuesta:
CodigoMensaje por defecto
SUCCESSProcessed successfully
VALIDATION_ERRORInvalid request data
UNAUTHENTICATEDAuthentication required
FORBIDDENInsufficient permissions
NOT_FOUNDResource not found
SERVER_ERRORInternal server error

​
Almacenamiento Seguro

Datos cifrados en el dispositivo:
  • Access token
  • Refresh token
  • Token expiry
  • Datos de usuario (id, email, displayName, phone)
Se accede a traves del wrapper secureStorage en src/shared/services/storage/secureStorage.ts.
Nunca almacenar tokens reales, URLs de API, ni credenciales en el codigo fuente ni en archivos de configuracion que se commiteen al repositorio. Los valores sensibles se gestionan mediante variables de entorno.

​
Pantallas de Auth

Las pantallas de autenticacion se encuentran en el grupo (auth):
RutaDescripcion
/loginInicio de sesion con email y contrasena
/reset-passwordSolicitud de restablecimiento de contrasena
/resend-passwordReenvio de contrasena

​
Inicializacion de Auth

Al iniciar la app, authStore.initializeAuth() ejecuta el siguiente flujo:
  1. Espera a que el store se hidrate desde almacenamiento persistido
  2. Verifica si hay tokens en el estado hidratado
  3. Si hay tokens pero estan expirados, intenta refresh automatico
  4. Si no hay tokens en estado, busca directamente en SecureStore (fallback)
  5. Si encuentra tokens validos, marca isAuthenticated: true e identifica al usuario en analytics
  6. Si no encuentra tokens, establece estado no autenticado
La inicializacion tiene un timeout de 15 segundos. Si se excede, se fuerza el estado a no autenticado para evitar que la app quede bloqueada.

​
Logout

El proceso de logout realiza las siguientes operaciones:
  1. Llama a authApi.logout() para invalidar tokens en el servidor
  2. Limpia la cola de requests pendientes (clearRequestQueue)
  3. Reset de analytics (analytics.reset())
  4. Limpia el estado del store
  5. Cancela y limpia todas las queries de React Query
  6. Desconecta y resetea el chat de Stream
  7. Limpia todos los datos de auth en SecureStore