66 lines
2.8 KiB
Markdown
66 lines
2.8 KiB
Markdown
# FAQ
|
|
|
|
## Does this project still require npm/frontend TypeScript tooling?
|
|
|
|
No. The legacy TypeScript frontend pipeline was removed after the Blazor rewrite.
|
|
`scripts/ci-local.ps1` is now a .NET-only flow (restore, build, tests, coverage checks).
|
|
|
|
## 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 `fetch` calls with cookie auth
|
|
- SSE connection/reconnect handling
|
|
- per-tab session storage helpers used by the Blazor UI
|
|
|
|
There is no TypeScript runtime frontend in the current codebase.
|
|
|
|
## 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.
|
|
|
|
## Do I need to run manual DB migrations after updating the app?
|
|
|
|
Usually no. Startup now uses EF Core migration-based schema upgrades (`Database.Migrate`) and applies pending migrations automatically.
|
|
|
|
## How do I add a new EF migration in this repo?
|
|
|
|
Use the repo-local tool manifest:
|
|
|
|
```powershell
|
|
dotnet tool restore
|
|
dotnet dotnet-ef migrations add <MigrationName> --project RpgRoller/RpgRoller.csproj --startup-project RpgRoller/RpgRoller.csproj
|
|
```
|
|
|
|
## 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.
|
|
|
|
## How do d6 wild dice and fumbles work now?
|
|
|
|
d6 skills now store two explicit options:
|
|
|
|
- `wildDice`: number of wild dice for the skill
|
|
- `allowFumble`: whether wild dice rolling `1` can trigger fumble removal
|
|
|
|
Roll responses also include per-die state flags (`crit`, `fumble`, `wild`, `removed`, `added`) so the frontend can render the full die-by-die outcome, not just the final total.
|