Frontend: experiencia de usuario y rutas

Idea principal

El frontend separa con claridad la experiencia publica y la privada.

Eso se refleja en:

rutas distintas
guards distintos
requisitos de acceso distintos

Rutas publicas

Ruta	Pantalla	Para que sirve
`/`	Landing	Entrada comercial del producto
`/auth`	AuthPage	Login y registro
`/book/:slug`	PublicBookingPage	Reserva publica del negocio
`/booking/:bookingId`	PublicManageBookingPage	Gestion publica del booking
`/booking/rate/:bookingId`	PublicRateBookingPage	Reseña posterior al servicio

Rutas privadas globales

Estas rutas requieren sesion, pero no dependen siempre de una membresia activa de negocio.

Ejemplos:

seleccion de membresia activa
administracion global de negocios
administracion global de planes

Rutas privadas con contexto activo de negocio

La mayor parte del panel vive aqui. Algunos ejemplos:

/admin/home
/admin/profile
/admin/users
/admin/appointments
/admin/booking
/admin/reviews
/admin/metrics
/admin/services
/admin/branches
/admin/roles
/admin/permissions
/admin/modules

Contexto activo del negocio

Despues de iniciar sesion, el frontend necesita saber con que negocio esta operando la persona.

Para eso usa:

store de usuario
store de membresia activa
cookie businessMembershipId
cache de permisos por rol

Sin ese contexto, muchas rutas privadas no pueden operar.

Guards principales

Guard	Responsabilidad
`PublicRoute`	Evita entrar a auth si ya existe sesion
`PrivateRoute`	Exige sesion y resuelve membresia/contexto
`PermissionRoute`	Exige permisos especificos
`AppointmentsAccessRoute`	Regula acceso completo o propio a agenda
`RootUserRoute`	Protege modulos globales

Como se siente eso para el usuario

Persona cliente

no necesita entrar al panel privado
usa links publicos por slug o bookingId
reserva, consulta o califica

Persona del negocio

entra por login
selecciona negocio si tiene varias membresias
ve solo lo que su rol permite

Root user

entra a secciones globales de negocio y planes
no depende del mismo recorrido operativo de un negocio normal

Caso especial: agenda de appointments

La agenda tiene una regla especial:

quien posee permisos globales puede ver todo
quien solo tiene permisos propios y ademas es empleado puede ver su agenda

Esto evita abrir el calendario completo a cualquier perfil.

Alias y rutas heredadas

El router aun mantiene alias hacia bookings, por ejemplo:

/bookings
/bookings/crear
/agendamientos
/agendamientos/crear

Se conservan por compatibilidad de navegacion.

Que pasa si algo falla en acceso

El frontend traduce errores como:

token vencido
sesion invalida
membresia inactiva
negocio con suscripcion no valida

En esos casos puede:

cerrar sesion
limpiar contexto activo
redirigir a seleccion de negocio

Idea principal​

Rutas publicas​

Rutas privadas globales​

Rutas privadas con contexto activo de negocio​

Flujo de login​

Contexto activo del negocio​

Guards principales​

Como se siente eso para el usuario​

Persona cliente​

Persona del negocio​

Root user​

Caso especial: agenda de appointments​

Alias y rutas heredadas​

Que pasa si algo falla en acceso​

Documentos relacionados​