con un clic
imperative-to-declarative-flet
// Convert an imperative Flet Python app in which controls are mutated and then page.update is called to declarative style using flet.component, flet.observable and state hooks.
// Convert an imperative Flet Python app in which controls are mutated and then page.update is called to declarative style using flet.component, flet.observable and state hooks.
Use when adding or changing deprecations for Python controls/APIs in sdk/python/packages/, including V.deprecated fields, deprecated decorators, version lifecycle, and docs admonitions/labels.
Use when asked to prepare new Flet release by bumping versions and author release notes.
Use when testing or debugging Flet apps in maintainer/contributor development mode with local Python package sources and the local Flutter client, including web, desktop, browser, and computer-use verification workflows.
Use when writing or reviewing Flet documentation, including Python docstrings (Google style, reST roles, admonitions), Markdown docs (cross-references, images, code examples), and sidebar navigation.
Use when asked to add, revise, or review a changelog or release-notes entry in this repo. Inspect the existing changelog section style and the relevant PR, issue, and commit context first, then write a focused entry in the correct release section without overstating docs, tests, or chores unless they are the primary user-facing change.
Use whenever editing validation for Python controls in sdk/python/packages/: adding/changing constrained properties, `Raises: ValueError` docstrings, `before_update()` checks, `raise ValueError`, Annotated/V rules, or __validation_rules__.
| name | imperative-to-declarative-flet |
| description | Convert an imperative Flet Python app in which controls are mutated and then page.update is called to declarative style using flet.component, flet.observable and state hooks. |
| metadata | {"short-description":"Port Flet app to declarative"} |
Port an existing imperative Flet app to “components mode” with @ft.component, hooks, and (optionally) @ft.observable models.
page.render(App) (components mode).page.update() for normal UI updates.@ft.observable for nested app data you mutate in place (boards/lists/cards, drag+drop reorder).ft.use_state for local ephemeral UI state (hover flags, input text, dialog selection).Control/component objects in state; store ids/enums and create controls during render.trolli → trolli-declarative-*).assets/ with the new folder.@ft.component def App(): ....ft.run(lambda page: page.render(App), assets_dir=...)main(page) function before page.render(App), orft.on_mounted(...) (works, but ordering can be less obvious).Appapp.route: str as source of truth.route_change(e) to normalize/redirect/validate routes and set app.routematch app.route (or a derived active_screen) to pick contentroute_change mutates route state; App() render chooses UI based on that state.src/components/*.py.page.update() usageIf a dialog mutates existing controls and calls page.update(), convert it to:
@ft.component dialog content with ft.use_state for error, selected_color, etc.page.show_dialog(ft.AlertDialog(content=DialogContent(...)))assets_dir derived from __file__.flet run, be aware it can set FLET_ASSETS_DIR and override assets_dir=.page.fonts = {"Pacifico": "Pacifico-Regular.ttf"}font_family="Pacifico".Event[Sub] ≠ Event[Base]):
on_click is declared on Button, annotate e as ft.Event[ft.Button] (or use def handler(): ...).TemplateRoute params are dynamic:
raw = getattr(troute, "id", None) then isinstance(raw, str) before int(raw).controls=[*[...], ...] can confuse type checkers with components: