Enhance FletXPage with automatic AppBar/NavBar integration based on Route

[pathan-07]

Currently, FletXPage requires manually defining build_app_bar, build_navigation_bar, etc., within each page class. While flexible, this can lead to boilerplate code, especially when multiple pages share common navigation elements (like a main app bar or bottom navigation). There isn't a straightforward way to associate specific navigation elements (AppBar, NavigationBar) directly with a route definition or have them automatically managed by the router/page lifecycle based on the current route.

Describe the solution you'd like
I propose enhancing the FletXPage and potentially the FletXRouter or RouteDefinition to allow defining standard navigation components (AppBar, NavigationBar, Drawer, etc.) at the route level or within the FletXPage in a more declarative way.

• Option 1 (Route Definition): Extend RouteDefinition to accept optional app_bar, navigation_bar, etc., arguments which could be ft.Control instances or factories. The router would then automatically apply these to the page view when navigating.

  router_config.add_route(
      path="/home",
      component=HomePage,
      meta={
          "app_bar": ft.AppBar(title=ft.Text("Home")),
          "navigation_bar": AppNavigationBar() # A custom ft.NavigationBar
      }
  )

• Option 2 (FletXPage Decorator/Class Attrs): Introduce class attributes or a decorator on FletXPage to define these elements.

  @page_config(
      app_bar=ft.AppBar(title=ft.Text("Settings"))
  )
  class SettingsPage(FletXPage):
      def build(self):
          # ... page content ...

• The FletXPage base class or the router would handle integrating these defined elements automatically during the page lifecycle, potentially overriding or supplementing the existing build_app_bar, etc., methods.

This would streamline the creation of consistent navigation across sections of an app.

Describe alternatives you've considered

1. Layout Components: Creating wrapper/layout components that include the AppBar/NavBar and render the specific page content within them. This works but adds another layer of component nesting and might complicate routing or state management.
2. Base Page Classes: Creating custom base page classes (e.g., MainAppPage with a standard AppBar). This is feasible but requires more manual inheritance management.
3. Manual Handling in build_app_bar: Adding conditional logic within build_app_bar based on self.route_info. This can become complex quickly.

Additional context
This feature aims to reduce boilerplate for common navigation patterns, making the definition of UI structure more declarative and tied to the routing configuration. It aligns with the goal of separating concerns by potentially moving layout structure definitions (like AppBars) closer to the route definitions. This seems like an intermediate-level task as it involves modifying core components like FletXPage and potentially FletXRouter and RouteDefinition, requiring understanding of the routing and page lifecycle. It respects the project's code of conduct by proposing an enhancement respectfully.

[pathan-07]

Can I start working on it?

[Einswilli]

Hi @pathan-07, thanks for your patience.

Thanks a lot for this well-structured proposal, it’s a very good point and definitely worth discussing.

There’s a clear benefit in reducing boilerplate and making navigation layouts more declarative, especially for apps where multiple pages share the same AppBar, NavigationBar, or Drawer. Your suggestion could greatly improve developer experience in those scenarios.

That said, integrating layout elements directly into the route system also introduces a few challenges we need to consider carefully:

• Page isolation: FletXPage was designed so each page fully controls its own UI lifecycle. Injecting AppBars/NavBars from the router may reduce flexibility (e.g., dynamic layouts or state-driven UI changes inside the page).
• Lifecycle complexity: Automatically attaching navigation UI at routing time affects page mounting/unmounting and could introduce subtle bugs if not handled carefully.
• Override priority: We’d need a clear rule: does the route configuration override the page’s own build_app_bar? Or the opposite?

Overall, the idea is solid, but it might fit better as an optional layer (e.g., a “layout-aware” router extension) rather than modifying the behavior of FletXPage’s core lifecycle directly.

We are very open to exploring this with the community, if others have thoughts, real-world use cases, or alternative designs, feel free to jump in. This could shape a powerful addition to FletX if we align on the right approach.