Provide context before rendering?

[sambonbonne]

Hello,

In my application, I set user authentication with cookies that are HTTP only. I use a RwSignal<Authentication> (with Authentication being an enum telling the user is authenticated or not), which I set with provide_context on my main App component.

My problem is that I use this signal in my ProtectedRoute's condition. Maybe you, the reader, see the problem coming: we can't render the router conditionnaly (as said in #1552) but I don't want to render my routes before checking the authentication (to prevent useless redirects).

To add some difficulties, I use hydratation of course.

So I don't want my server nor my client to run the router before the authentication is checked (by a server function as the cookie is HTTP only).

Does anyone have this use case and found a solution?

[sambonbonne]

Correct me if I'm wrong but it seems create_local_resource is the answer? I tried to avoid it because of the performance hit but it seems the best option here?

In use with a nested <Route path="/"> and <Outlet/> (like explained in #1552 (comment)) it seems to do what I need.

[gbj]

There's a distinction between "defining the routes" and "rendering the routes." You do want all your routes to be defined unconditionally, you don't want your routes to be rendered in response to a request unconditionally. If the authentication state is stored in a signal, then a Show or conditional around an Outlet should work. If the authentication state is stored in a resource, then Suspense around an Outlet.

I don't think there's any reason this needs to be a local resource but of course I could be wrong. If you use plain create_blocking_resource and read it in a Suspense that renders either the Outlet or a Redirect, you should be fine. Note that it needs to be a blocking resource for a server-side redirect to work — otherwise streaming kicks in and it's too late to set a redirect header because part of the response has already been sent.

[sambonbonne]

I tried this with a blocking resource but it seems I have a bug with the <Suspense>: it always render the view like if the resource was still None. Is their a known bug in 0.5.0 RC1 with <Suspense> or should I make a reproduction repository to see if I reproduce my problem with a fresh template?

[gbj]

Some kind of a reproduction would be great. It is not streaming in a new HTML fragment with the resolved version?

[sambonbonne]

It seems I got it working, my code was a mess after all the things I tried.

One thing I was doing which seemed to cause some problem was to manipulate context from resources function:

let loading_auth = create_resource(|| (), move |_| async move { 
    let auth = get_session_tree().await;

    if Ok(ref obtained_auth) = auth {
        provide_context(create_rw_signal(obtiande_auth.clone());
    }

    auth
});

It seems I removed some problems by manipulating the context directly on my view:

<Transition fallback=|| view! { <p>"Loading…"<p> }>
    {move || loading_auth().map(|auth| {
        match auth {
            Ok(auth) => {
                provide_context(create_rw_signal(auth));
                view! {
                    /*  children here */
                }.into_view()
            },
            Err(_) => view! { <p>"ERROR"</p> }.into_view()
        }
    })}
</Transition>

Now, I have some flickering with the <Transition> but I have to look at which one, because I have some "nested" <Transition> so I think it does not help?

Edit: the flickering happens only when navigating (by clicking a <A>, and the <Transition> does not display any ERROR or Loading… so it may not be linked to the <Transition>. More in the next episode!

[sambonbonne]

Update on the flickering (yeah it was quick): that's because of a "design pattern" I use, I can manage this!