Skip to content

NiceGUI Component Extraction

Extract one user-selected component from the output of the JSFiddle Page Layout prompt and implement it as a reusable NiceGUI component in the target repository.

Supplied Inputs

  • component: {{component}}
  • source_layout: {{source_layout}}
  • target_location: {{target_location}}
  • behavior_requirements: {{behavior_requirements}}

Inputs

  1. component: required visible label, semantic role, or selector identifying the component to extract
  2. source_layout: optional HTML and CSS; when omitted, use the latest applicable JSFiddle page layout output in the conversation
  3. target_location: optional target page, module, or package; infer it from the repository when omitted
  4. behavior_requirements: optional interactions, state, callbacks, or content variations

If the selected component or source layout cannot be identified unambiguously, ask one concise clarification question before editing.

Required References

Apply these references before implementation:

  1. Package boundaries, dependency direction, and page or component ownership: NiceGUI Application Architecture
  2. Responsive layout, Quasar props, Tailwind utilities, and shared CSS: NiceGUI Styling and Customization
  3. Typed UI state, propagation, mutable defaults, binding strictness, and version checks: Binding Dataclasses Deep Dive

Workflow

  1. Locate the selected region in the source HTML and CSS, including its responsive rules, states, and dependencies on surrounding layout.
  2. Inspect the target repository's NiceGUI version, package structure, component conventions, shared CSS loading, and nearest page call site.
  3. Define the smallest reusable API for the component:
  4. name the public function render_<component_name> using snake_case
  5. accept content, typed state, and event callbacks as explicit parameters
  6. keep business rules, persistence, and service access outside the component
  7. preserve an established return-value convention; otherwise return the component's root NiceGUI element
  8. Translate semantic HTML into native NiceGUI and Quasar elements. Do not embed the original page wholesale with ui.html when standard components express the structure.
  9. Recreate only the CSS needed by the extracted component:
  10. use Quasar props for component appearance and behavior
  11. use NiceGUI classes and Tailwind utilities for spacing, sizing, alignment, and responsive layout
  12. use scoped shared CSS only where props and utilities are insufficient
  13. do not override Quasar field internals or duplicate globally loaded styles
  14. Model editable or shared component state with a typed @binding.bindable_dataclass only when binding improves the interaction:
  15. use field(default_factory=...) for mutable defaults
  16. scope state to the appropriate page, client, or user
  17. keep binding transforms pure and inexpensive
  18. assign updated collections back to bound fields instead of relying on in-place mutation
  19. Integrate the render function at the nearest target page or call site without moving unrelated page composition or domain logic into the component.
  20. Preserve accessibility, focus behavior, text wrapping, stable dimensions, and the source layout's visual hierarchy.
  21. Run the narrowest available tests, lint, and type checks for the changed files. For visual components, verify representative mobile, landscape desktop, and portrait desktop viewports when browser tooling is available.

Output Contract

Complete the implementation in the target repository, then report:

  1. Files created or updated.
  2. The render_* function signature and its state or callback contract.
  3. Any deliberate visual or interaction differences from the JSFiddle source.
  4. Validation commands and outcomes, including viewport checks when performed.

Quality Rules

  1. Extract exactly the requested component and its necessary local dependencies.
  2. Prefer the target repository's established patterns over introducing a new abstraction style.
  3. Keep the component presentation-focused and reusable across pages with compatible data.
  4. Do not add a bindable dataclass for static content or event-local state that is clearer as ordinary parameters.
  5. Do not create a second component tree for mobile; use responsive classes and stable layout constraints.
  6. Keep custom CSS tokenized, scoped to the component, and loaded once by the application's composition layer.