2.3 KiB
FAQ
Why does this starter use custom frontend lint/format scripts instead of heavy npm dependencies?
The kickoff scaffold is intentionally lightweight and keeps only strictly relevant tooling:
- API client generation from the OpenAPI contract
- TypeScript compilation for frontend source files
- basic frontend contract checks
- deterministic formatting checks used by
scripts/ci-local.ps1
This keeps the first commit small while preserving CI discipline. Additional tooling can be introduced when the frontend stack is finalized.
Is frontend JavaScript handwritten?
The runtime UI is now built with Blazor components (RpgRoller/Components/*).
There is still small handwritten JavaScript in RpgRoller/wwwroot/js/rpgroller-api.js for:
- browser
fetchcalls with cookie auth - SSE connection/reconnect handling
- per-tab session storage helpers used by the Blazor UI
The TypeScript frontend folders remain in the repo for tooling and generated API client contract checks used by CI.
Where is backend state stored locally?
Backend state is persisted via EF Core + SQLite.
- Development default:
RpgRoller/App_Data/rpgroller.development.db - Non-development default:
RpgRoller/App_Data/rpgroller.db
To start with a clean backend state, stop the app and remove the corresponding SQLite file.
Does the backend read SQLite on every API call?
No. The backend loads state from SQLite once during startup into in-memory state and serves requests from memory. Successful state mutations are then written back to SQLite.
Where is the frontend UX plan documented?
The canonical frontend UX design lives in UX.md at the repository root. It defines roles, flows, screen behavior, validation/error handling, responsive behavior, and real-time update expectations to guide implementation.
What does test coverage include?
Coverage now includes the entire backend project (RpgRoller), including API/hosting/bootstrap code and services. It is no longer restricted to RpgRoller.Services.*.
Why do backend services avoid API request DTO dependencies?
Service workflows accept explicit parameters (for example, CreateCampaign(sessionToken, name, rulesetId)) instead of API request DTOs. This keeps the service layer independent from HTTP transport contracts while avoiding extra service-only wrapper command types.