Context provided in a view that is nested fn not available in whatever is rendered in <Outlet />

[dnaaun]

I'd like to do this to avoid duplicating expensive computation/queries.-

I tried doing provide_context() and use_context() and that didn't seem to work. But maybe I was holding it wrong? Even if I wasn't, it doesn't strike me as the most maintainable API to pass arguments to <Outlets /> ...

---

UPDATE: it turns out the issue is different from my initial framing. I've updated the title to reflect that. The below code panics at the use_context() line (here's a repo with the repro).

use leptos::prelude::*;
use leptos_router::components::{Outlet, ParentRoute, Route, Router, Routes};
use leptos_router::path;

#[derive(Clone)]
struct TheContext;

#[component]
pub fn Parent() -> impl IntoView {
    provide_context(TheContext);
    view! { <Outlet /> }
}

#[component]
pub fn Child() -> impl IntoView {
    use_context::<TheContext>().expect("TheContext not provided.");
}

#[component]
pub fn App() -> impl IntoView {
    view! {
        <Router>
            <Routes fallback=|| ()>
                <ParentRoute path=path!("/") view=|| Parent > // Doing `view=Parent` instead avoids the panic!
                    <Route path=path!("") view=Child />
                </ParentRoute>
            </Routes>
        </Router>
    }
}

I haven't articulated in this minimal repro why I want this sort of function nesting. I am trying to work around this issue by avoiding the need for the function nesting. But I thought it'd be good to update this issue with what actually was my issue to provide some closure (pun intended haha).

[gbj]

The answer is via context, and if context isn't working then more details are helpful.

[dnaaun]

Thanks so much for the quick reply! Although I could provide a reproduction, it won't be minimal at all, because trying to provide a minimal repro doesn't repro the issue. I'll get back in touch when I can do that.

[dnaaun]

I've come up with a minimal repro @gbj ! I've updated the OP with it.

[gbj]

This seems similar to #2953 to me, in which something that would work with view=Parent or view=|| view! { <Parent/> } fails with view=|| Parent. I don't think there's ever a reason to do view=|| Parent, so while I recognize this is a bug it's a fairly low priority to investigate and fix.