john/prompts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

nicegui consolidation

Browse Source
This commit is contained in:
John Lancaster
2026-07-29 23:37:48 -05:00
parent bc0d6ede49
commit 8f26051a52
9 changed files with 242 additions and 435 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/skills/nicegui/SKILL.md
+83 -156
View File
@@ -1,206 +1,133 @@
---
name: nicegui
description: 'Design and scaffold a production-ready NiceGUI + FastAPI application architecture. Use for multi-page app planning, package boundaries, optional DB/LangGraph/docs integration, and implementation checklists.'
description: 'Reference hub for NiceGUI and FastAPI application structure, UI composition, styling, bindable state, interactions, troubleshooting, testing, and source documentation. Use when planning, implementing, reviewing, or debugging NiceGUI applications; load only the references relevant to the task.'
x-personal-mcp:
id: nicegui
version: 1.0.0
version: 2.0.0
tags:
- nicegui
- fastapi
- ui
- architecture
- scaffolding
- customization
- frontend
- testing
- source-docs
capabilities:
- resource://skills/nicegui/document
---
# NiceGUI
# NiceGUI Reference
Design a production-minded NiceGUI + FastAPI architecture with clear boundaries, optional extensions, and a concrete implementation checklist.
Use this skill as a progressive reference for NiceGUI applications built with FastAPI. Start with the routing map, load only the material needed for the current question, and reconcile it with the target project's NiceGUI version and established conventions.
## When to Use
- You need a reusable architecture plan before implementing a NiceGUI app.
- You want FastAPI app-factory structure and lifespan wiring.
- You need optional guidance for database, LangGraph workflows, or mounted static docs.
- You want output that is concise, structured, and implementation-ready.
- Planning or reviewing NiceGUI application structure and FastAPI composition.
- Building or refactoring pages, components, layouts, and static assets.
- Modeling UI state with bindings or bindable dataclasses.
- Implementing forms, uploads, refreshes, live updates, or background work.
- Diagnosing UI state, concurrency, navigation, or asset problems.
- Verifying framework behavior against primary documentation.
## Inputs to Collect
## How to Use This Skill
Collect these inputs up front. If not provided, make safe defaults and state assumptions.
1. Classify the request using the discovery map below.
2. Load the smallest relevant reference, or at most two references for a mixed concern.
3. Inspect the target repository before applying guidance; preserve its sound local patterns.
4. Check the pinned NiceGUI and integration versions before relying on version-specific APIs.
5. Validate the changed behavior with focused tests and, for UI work, relevant viewport checks.
- Product scope and primary user journeys.
- Required pages and route map.
- Whether persistent data is required.
- Whether AI orchestration (multi-step, streaming, approvals) is required.
- Whether generated docs should be mounted in-app.
- Runtime/deployment constraints (single service vs split services, environment requirements).
## Progressive Discovery Map
## Outcome
### Application Architecture
Produce:
Load [application architecture](./references/architecture.md) for:
- A concise architecture explanation.
- How core services, UI pages, and UI components fit together.
- Explicit decision on DB ownership or involvement.
- Explicit decision on AI workflow (or no AI).
- A checklist implementation plan organized by package and domain.
- FastAPI app factories and lifespan ownership
- package boundaries and dependency direction
- page registration and health routes
- optional persistence, LangGraph, or mounted documentation
- async responsiveness and baseline tests
## Procedure
### Components And Styling
1. Frame the baseline architecture.
2. Choose optional extensions (DB, AI, docs) using decision points below.
3. Map modules, dependencies, and key boundaries.
4. Define async behavior and UI responsiveness expectations.
5. Define key functions/classes and configuration surfaces.
6. Produce phased checklist with rollout or migration notes when relevant.
7. Run completion checks before returning.
Load [architecture and styling](./references/architecture-and-styling.md) for:
### 1) Baseline architecture
- page, component, and service boundaries
- component extraction decisions
- Tailwind and Quasar styling order
- responsive layout and static asset conventions
Use a src-layout with FastAPI as the ASGI app and NiceGUI registered via composition.
### Bindable State
- App factory pattern: `create_app()`.
- Lifespan for startup and shutdown resource management.
- `api/` for HTTP handlers, `services/` for business logic.
- `ui/pages/` for page modules, `ui/components/` for shared UI.
- Health endpoint on FastAPI side: `/healthz`.
Load [bindable dataclasses](./references/binding-dataclasses.md) for:
Recommended base shape:
- typed local UI state
- propagation and refresh behavior
- nested structures and strict bindings
- mutable defaults, performance, and version notes
```text
.
├─ pyproject.toml
├─ .env.example
├─ README.md
├─ src/
│ └─ app/
│ ├─ __init__.py
│ ├─ main.py
│ ├─ bootstrap.py
│ ├─ config.py
│ ├─ logging.py
│ ├─ api/
│ │ ├─ __init__.py
│ │ └─ health.py
│ ├─ services/
│ │ ├─ __init__.py
│ │ └─ example_service.py
│ └─ ui/
│ ├─ __init__.py
│ ├─ components/
│ │ ├─ __init__.py
│ │ └─ nav.py
│ └─ pages/
│ ├─ __init__.py
│ ├─ home.py
│ ├─ dashboard.py
│ └─ about.py
└─ tests/
├─ test_health.py
└─ test_pages_registration.py
```
### Interaction Patterns
### 2) Decision points
Load [interaction patterns](./references/interaction-patterns.md) for:
#### Database needed?
- uploads and form submission
- explicit refreshes
- server-sent events and WebSockets
- background work and duplicate-submission guards
- If no: keep `services/` pure and skip persistence layers.
- If yes: add `db/` package with engine/session/model/repository layering.
- Prefer one process-level engine and request-scoped sessions via `yield`.
- Prefer Alembic migrations for schema changes.
### Troubleshooting And Quality
#### AI workflow needed?
Load [troubleshooting and quality gates](./references/troubleshooting-and-quality-gates.md) for:
- If no: keep `services/` focused on app logic only.
- If yes: add `ai/` package (state, nodes, graph, runtime, contracts).
- Keep graph internals out of `ui/pages/` and API handlers.
- Use stable thread/session IDs for resumable flows.
- upload failures and UI race conditions
- stale assets and navigation drift
- responsiveness, accessibility, reliability, and maintainability checks
#### Mounted docs needed?
### Primary Sources
- If no: skip docs mounting.
- If yes: mount generated static site under configurable route (default `/docs`).
- Keep docs mounting in composition layer, not page modules.
Load [source documentation](./references/source-documentation.md) when:
### 3) Page and component registration
- behavior is version-sensitive or uncertain
- an integration recommendation needs verification
- upstream NiceGUI, FastAPI, Tailwind, Quasar, SQLAlchemy, Pydantic, or LangGraph documentation is required
- Require at minimum page modules for `/`, `/dashboard`, `/about`.
- Prefer explicit registration pattern:
- `ui/pages/__init__.py` exports `register_pages()`.
- Each page module exports `register_page()`.
- Shared shell components (header/nav/drawer) live in `ui/components/`.
## Common Discovery Paths
### 4) Dependency direction rules
### New Application Or Architecture Review
Prefer:
1. Load [application architecture](./references/architecture.md).
2. Add [architecture and styling](./references/architecture-and-styling.md) only when page and component design is in scope.
- `main/bootstrap` -> `config/logging` + `api` + `ui/pages` + `services`
- `api` -> `services`
- `ui/pages` -> `ui/components` + `services`
- `services` -> helpers/clients (and `db/` when enabled)
### Page Or Component Work
Avoid reverse imports from services into API or UI modules.
1. Load [architecture and styling](./references/architecture-and-styling.md).
2. Add [interaction patterns](./references/interaction-patterns.md) or [bindable dataclasses](./references/binding-dataclasses.md) according to the page behavior.
### 5) Async and UI responsiveness rules
### Debugging Or Production Review
- Prefer `async def` for page handlers, service methods, and integrations when the call path includes I/O.
- Use non-blocking clients/libraries where possible so long-running I/O does not freeze UI updates.
- Do not run blocking calls (`time.sleep`, blocking HTTP/database clients) in UI event handlers.
- For heavy CPU work, offload to worker/background execution and keep the UI loop free.
- Show progress states for long actions (disable action button, show spinner/progress text, re-enable on completion).
- Stream or chunk incremental results to the UI when workflows are multi-step or long-running.
- Keep cancellation and timeout behavior explicit for user-triggered long tasks.
- Ensure exceptions from async tasks are surfaced with user-friendly feedback and logged for diagnostics.
1. Start with [troubleshooting and quality gates](./references/troubleshooting-and-quality-gates.md).
2. Follow the symptom to one detailed reference.
3. Confirm uncertain behavior in [source documentation](./references/source-documentation.md).
### 6) Testing minimums
## General Defaults
- Test FastAPI health route behavior.
- Test page registration wiring.
- If DB enabled: session lifecycle and rollback behavior tests.
- If AI enabled: graph happy path and interrupt/resume coverage.
- If docs enabled: mounted docs route returns index page.
- For async flows: test long-running actions preserve UI responsiveness (loading state, completion state, and error state).
- Keep composition, transport, services, pages, and components directionally separated.
- Keep business logic out of UI components and event handlers.
- Avoid blocking I/O and CPU-heavy work in the UI event loop.
- Prefer event-driven updates and explicit refreshes over unrelated polling.
- Prefer Tailwind utilities, then Quasar props, then reusable component helpers; use minimal shared CSS when those are insufficient.
- Provide loading, success, and failure states for user-triggered work.
- Treat version-specific guidance as a prompt to verify the project's dependency version.
### 7) Styling architecture
## Reference Use Contract
- Keep structure and layout in Python modules using NiceGUI class composition.
- Keep visual polish in shared CSS files, loaded once at startup.
- Prefer semantic reusable classes over ad hoc per-page styling.
When applying this skill:
## Completion Checks
- Uses app factory and FastAPI lifespan.
- Pages are modularized (not single-file UI).
- Health endpoint exists on FastAPI side.
- Dependency direction is clean and one-way.
- Async-first guidance is applied where I/O exists, with explicit non-blocking UX states.
- Optional DB/AI/docs decisions are explicit and reflected in structure.
- Output includes architecture summary and package-organized checklist.
## Output Contract
Return:
- Concise high-level architecture.
- How core services, pages, and shared components fit.
- DB involvement and ownership stance.
- AI workflow stance and runtime flow.
- Checklist plan by package and domain:
- key functions/classes
- settings/config surfaces
- rollout/migration notes (when relevant)
## Guardrails
- Do not collapse all pages into one file.
- Do not use globals or implicit global side effects.
- Do not block UI event handlers with synchronous I/O or long CPU tasks.
- Always define loading/progress/error states for long user-triggered actions.
- Keep code minimal but production-minded.
- Prefer clarity and maintainability over clever abstractions.
## References
- Architecture and integration details: [NiceGUI architecture reference](./references/architecture.md)
- Dataclass binding deep dive: [Bindable dataclasses in NiceGUI](./references/binding-dataclasses.md)
- Source documentation links: [NiceGUI source documentation](./references/source-documentation.md)
- return only guidance relevant to the current task
- distinguish repository facts from reference recommendations
- cite the appropriate source reference for framework-level claims
- state assumptions when application requirements are missing
- report the focused checks used to validate implementation changes