React.Outlet-like feature

[edan-bainglass]

I'm digging into Solara's approach to routing. I was wondering if there exists a component similar to React's Outlet. The goal is to integrate routes into a parent component, rather than globally.

Use case: a main component with a permanent navbar (AppBar) and a routed body. Clicking on a navbar link renders the associated component in the body.

[iisakkirotko]

Hi @edan-bainglass! That's a good question.

Solara already supports routing (docs), both based on automatic file discovery, or manual management. You can use routing together with the special Layout component to wrap all the children (or all the children of some sub-route) with whatever structure you want.

I made a quick PyCafe example to illustrate the usage.

Let me know if you have any further questions!

[edan-bainglass]

Thanks @iisakkirotko. That works well for my case. I was wondering, is there a clean way to define my app's root path? Running solara run myapp.py serves it at localhost:<port>. How do I 1) get it to serve at localhost:<port>/<root-path>, and 2) get all other routes and/or links relative to the root route?

[edan-bainglass]

How would I use context across routes? My app has 4 routes. I want to provide context to one of the routes. How can I do this? The usage of the data argument of Route is not documented. Documentation for use_context is very limited. Could you please assist? I am finding it very difficult to persist my apps state in Solara.

[edan-bainglass]

@iisakkirotko could you please help with this? I don't see anywhere in the documentation or examples how one would do this. It is unclear to me how to maintain the state across my routes.

[iisakkirotko]

Hi @edan-bainglass! Sorry for the delayed response, I've been busy working on other things. I think the reason the use_context's (and other related functions') documentation is not very fleshed out is because they're direct re-exports from reacton. You can find reacton's documentation for use_context here.

However, unless you want to provide a completely different reactive variable to some child components, I don't think there is a difference between using use_context and just declaring a top-level reactive variable (using solara.reactive) and using that. Take a look at this PyCafe example that showcases both options

[edan-bainglass]

This is true. I got off the context idea in favor of simply defining the required reactive variable for that component in that component's module. This seems to work well for state management.

I'm now struggling with the amount of renders though. Opening the 5th step of an accordion component triggers a re-render of every other step. I suspect this is due to how I'm handling the "model" of the app. I have "wizard"-model that I pass to each step. The model is pydantic and holds the current step, the states array (init/configured/active/success per step), and data, which is itself a pydantic model schema that defines the eventual output of the "wizard" accordion component. Each step manages a portion of the model. However, I am passing a Reactive version of the whole "wizard" model to each step. Each step can modify the states trait via an on_state_change callback. Each step can also modify a part of the data schema via a Ref view to that part of the reactively-wrapper pydantic model.

Sorry for the lengthy description. Bottom line, I suspect that changes to the "wizard" model cause reactions throughout, as the model is a prop of all steps. Need to think how to decouple this.

Thanks for any advice up to now, and any future advice 🙂 We are considering Solara as an upgrade to our ipywidgets-based apps. In the testing/exploration phase...

[iisakkirotko]

Yeah, if you're passing the data / state to each model they will all rerender. There's probably a better way to structure your data, so that each component is only aware of the data it needs to be aware of to prevent unwanted rerenders. Maybe something like

@solara.component
def Wizard():
    current_step = solara.use_reactive(...)
    first_step_state = solara.use_reactive(...)
    second_step_state = solara.use_reactive(...)

    WizardFirstStep(expanded=current_step.value >= 0, state=first_step_state)
    WizardSecondStep(expanded=current_step.value >= 1, state=second_step_state, prev_state=first_step_state.value)
    ...

But I don't have the full context of your program so this might not be feasible.

[edan-bainglass]

Yeah, I have to play with this some more. This of course will work, but I guess not for my use case where the number of steps is not hard-coded, which is why I used a list of states. But I agree that a restructuring of the data may help. Looking into it.