[Question] How to use component functions when building a View object's control tree

[una0213]

Question

When I tried using a component function to build the control tree for a View object for screen transitions, I encountered the following runtime error. Is it not possible to use a component function in this situation?

Code sample

import flet as ft

@ft.component
def view_content():
    return ft.Text('some settings...')

@ft.control
class SettingsView( ft.View ):
    def __post_init__( self, *args, **kwargs ):
        super().__post_init__( *args, **kwargs )
        
        self.route = '/settings'
        self.controls = [ view_content() ]   # RuntimeError


@ft.component
def main():
    page = ft.context.page
    def route_change():
        page.views.clear()
        page.views.append( ft.View( route="/", controls = [ ft.Text('root view') ] ) )
        if page.route == "/settings":
            page.views.append( SettingsView() )
        page.update()

    page.on_route_change = route_change
    page.go('/settings')
    
ft.run( lambda page: page.render( main ) )

Error message

RuntimeError: No current renderer is set. Call via Renderer.render(...) or Renderer.with_context(...).

------------------------------------------------------

• I have searched for answers to my question both in the issues and in previous discussions.

[yhay81]

This happens because a @ft.component function is not a normal control factory. It must run while Flet's component renderer is reconciling a tree. SettingsView.__post_init__() is ordinary control construction, and in this example it is reached from the imperative route callback, so there is no current renderer; that is exactly what the exception is reporting.

For this particular example, the smallest fix is to make view_content a plain factory:

def view_content():
    return ft.Text("some settings...")

@ft.control
class SettingsView(ft.View):
    def __post_init__(self, *args, **kwargs):
        super().__post_init__(*args, **kwargs)
        self.route = "/settings"
        self.controls = [view_content()]

Use that version if view_content does not need hooks/state/context.

If it does need to be a real component, make the views part of the declaratively rendered tree instead of constructing them in page.on_route_change. In current Flet the intended entry point is page.render_views(...):

@ft.component
def ViewContent():
    return ft.Text("some settings...")

@ft.component
def App():
    route, set_route = ft.use_state(ft.context.page.route)
    ft.context.page.on_route_change = lambda e: set_route(e.route)

    return [
        ft.View(route="/", controls=[ft.Text("root view")]),
        *(
            [ft.View(route="/settings", controls=[ViewContent()])]
            if route == "/settings"
            else []
        ),
    ]

ft.run(lambda page: page.render_views(App))

The repository's current two-page declarative routing example uses this same pattern: the component returns the View list and is mounted with render_views, so nested component calls occur inside the renderer context:
https://github.com/flet-dev/flet/blob/main/sdk/python/examples/apps/declarative/routing_two_pages/main.py

So the short answer is: a component can build a View's controls, but only when that View is itself produced inside the component render tree. Removing @ft.component gives you an ordinary reusable control factory; switching to render_views gives you component hooks and reconciliation.

[una0213]

Thank you for your reply. When choosing a declarative UI style, it seems better to maintain consistency by using only function components rather than mixing in custom controls.
I understand .Thank you.