Skip to content

Conversation

@pathan-07
Copy link

This PR #115 introduces a new way to configure standard page navigation components (like AppBar, NavigationBar, Drawer, etc.) for FletXPage in a more declarative manner, reducing boilerplate code.

Problem:

Currently, navigation components need to be defined manually within each FletXPage class using methods like build_app_bar(). This can lead to repetition, especially for pages sharing common layouts.

Solution:

This implementation provides two ways to define navigation components declaratively:

@page_config Decorator: A new decorator (@page_config) allows defining default navigation components directly on the FletXPage class itself. These components can be instances, classes, or factory functions.

Python

@page_config(app_bar=ft.AppBar(title=ft.Text("My Page")))
class MyPage(FletXPage):
# ...
Route Definition Metadata: Navigation components can also be specified in the meta dictionary when defining a route using router_config.add_route. This allows route-specific overrides.

Python

router_config.add_route(
path="/settings",
component=SettingsPage,
meta={
"app_bar": ft.AppBar(title=ft.Text("Settings")),
"navigation_bar": AppNavBar()
}
)
Precedence: The system resolves the final component to use with the following priority:

Instance-level configuration (set via page.configure_navigation()).

Route-level configuration (from meta).

Class-level configuration (from @page_config or navigation_config).

Fallback to the traditional build_...() methods (e.g., build_app_bar()).

Key Changes:

Added new decorator @page_config in fletx/decorators/page.py.

Modified fletx/core/page.py (FletXPage) to include logic for collecting, resolving, and applying navigation configurations from different sources.

Updated fletx/core/routing/router.py (FletXRouter) to extract navigation config from route meta data and pass it to the page instance.

Added new tests in tests/test_fletxpage.py to verify the decorator and override logic.

Note: The tests for this feature have been written but were not executed in the contributor's local environment due to setup constraints. Automated CI tests should verify the implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant