Lukas
1c673d600c
This commit standardizes how API responses are wrapped, solving issue #24. Problem: - Inconsistent response envelopes (jails vs items vs bans vs no wrapper) - Frontend required multiple field name variants - Integration bugs from branching logic - No clear pattern for different response types Solution: - Created response.py with base classes: PaginatedListResponse, CollectionResponse, CommandResponse - Standardized all list/collection responses to use 'items' field - Domain-specific field names for detail and aggregation responses - Updated all backends routers and mappers - Updated frontend types and hooks to match Changes: Backend: - backend/app/models/response.py (new): Base response models - backend/app/models/ban.py: Updated responses to inherit from bases - backend/app/models/jail.py: Updated JailListResponse, JailCommandResponse - backend/app/models/config.py: Updated collection responses - backend/app/services/jail_service.py: Updated return statements - backend/app/mappers/ban_mappers.py: Updated 'bans' to 'items' - backend/tests/test_mappers/test_ban_mappers.py: Updated tests Frontend: - frontend/src/types/jail.ts: Updated response interfaces - frontend/src/types/config.ts: Updated response interfaces - frontend/src/hooks/useActiveBans.ts: Updated selector - frontend/src/hooks/useJailList.ts: Updated selector - frontend/src/hooks/useJailConfigs.ts: Updated selector - frontend/src/hooks/useConfigActiveStatus.ts: Updated field access - frontend/src/hooks/useJailAdmin.ts: Updated field access Documentation: - Docs/Backend-Development.md: Added § 4.1 API Response Envelope Policy The policy defines: 1. Paginated lists use PaginatedListResponse (items, total, page, page_size) 2. Non-paginated collections use CollectionResponse (items, total) 3. Detail responses use entity-specific field names (jail, status, settings) 4. Command responses use CommandResponse (message, success, optional target) 5. Aggregations use domain-specific fields (jails, countries, buckets, bans) All responses now follow one of these patterns, reducing frontend complexity. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
React Hook Fetch Cancellation
This folder follows a shared convention for network fetch cancellation in React hooks.
Patterns
1. Hooks with manual refresh
Hooks that expose a refresh() callback must use a long-lived AbortController stored in a ref:
- `const abortRef = useRef<AbortController | null>(null);
- Call
abortRef.current?.abort()before starting a new request. - Create a fresh controller before every
refresh()invocation. - Pass
controller.signalto the API function. - In the cleanup effect, abort the controller when the hook unmounts.
- After each
await, checksignal.abortedbefore updating state.
This prevents stale responses from overwriting newer results and avoids React state updates after unmount.
2. One-shot mount-only requests
Hooks that only fetch once inside useEffect and do not expose a manual refresh may use a local controller:
- Create
const controller = new AbortController();inside the effect. - Pass
controller.signalto the request. - Abort it in the effect cleanup.
- This is the simplest correct pattern for single-fetch hooks.
3. Do not use boolean cancelled flags for network requests
A boolean cancelled flag is not sufficient because it does not stop the underlying fetch. Abort signals are the correct cancellation mechanism for fetch-based hooks.