jhonnierdlc/proyectobiblioteca-frontend

Purpose and Runtime

This is a Create React App single-page frontend for library operations: authentication, books, users, loans, and fines. It runs in the browser via React; production builds are static assets, with containerization indicated by Dockerfile. No backend, database, or API host is documented, though domain service modules form the external API boundary.

Application Entry and Shell

src/index.js mounts the React application and global styling from src/index.css. src/App.js is the top-level composition/root control point. The principal authenticated application shell appears to be src/components/Main/index.jsx, while src/components/Inicio/index.jsx supplies the landing/home view.

Authentication and Access Boundary

Authentication-facing UI is separated from operational modules:

• Login: src/components/Login/index.jsx

• Sign-up: src/components/Singup/index.jsx

• Main application shell: src/components/Main/index.jsx

This division suggests the app transitions from public credential screens into the main library-management workspace. The tree does not expose a dedicated auth service, routing layer, token store, or authorization middleware, so those responsibilities likely reside in component state or are absent from this frontend.

Book Catalog Management

The books domain supports the standard record lifecycle:

• Create: src/components/Libros/RegistroLibros/RegistroLibros.jsx

• Query/list: src/components/Libros/ConsultaLibros/ConsultaLibro.jsx

• Edit: src/components/Libros/EditarLibros/ModalEditarLibros.jsx

• API boundary: src/services/libroServices.js

Book screens gather and display catalog data, then delegate remote operations to the book service. Editing is explicitly modal-oriented, creating a reusable interaction boundary rather than a standalone page.

User Management

Patron/user records are similarly managed through create, consult, and edit surfaces:

• Registration: src/components/Usuarios/RegistroUsuarios/RegistroUsuarios.jsx

• Consultation: src/components/Usuarios/ConsultarUsuarios/ConsultarUsuarios.jsx

• Editing: src/components/Usuarios/EditarUsuario/index.jsx

• API boundary: src/services/clienteServices.js

Loan and fine workflows depend conceptually on these user identities, but no centralized domain state/model layer is visible.

Loan Workflow

Loans are implemented as a staged workflow:

• Selection/start: src/components/Prestamo/SelecionPrestamo/index.jsx

• Registration: src/components/Prestamo/RegistrarPrestamo/index.jsx

• Consultation: src/components/Prestamo/ConsultarPrestamos/ConsultarPrestamos.jsx

• Modification: src/components/Prestamo/EditarPrestamo/index.jsx

• API boundary: src/services/prestamoServices.js

The selection stage likely establishes the book/user context before registration. Consult and edit screens handle the existing-loan lifecycle. This is the main business boundary connecting catalog availability with borrower records.

Fine Workflow

Fines have their own selection, registration, query, history, and edit stages:

• Selection: src/components/Multa/SeleccionMulta/index.jsx

• Registration: src/components/Multa/RegistroMulta/index.jsx

• Consultation/history: src/components/Multa/ConsultarMulta/index.jsx, src/components/Multa/Historial/index.jsx

• API boundary: src/services/multaService.js

This separation indicates fines are persisted domain records, potentially associated with loans or users, with history treated as a distinct read model.

Shared UI and Delivery

src/components/UI/ModalEliminar.jsx is the shared destructive-action boundary, likely reused by record-management screens. Static browser assets live in public/, especially public/index.html; CRA supplies the client build pipeline. Dockerfile is the deployment/runtime packaging boundary. The external services behind the four modules in src/services/ are architecturally required but unspecified in the repository inputs.